OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [security-services] Re: ForceAuthn (was Use Cases)



Just a clarifying note... We have been talking back and forth about
caching of credentials and prompting of the user that I thought I would
walk through the authentication process discussing what an IdP might do
and when..

User has an estabilshed session at the IdP (started via an 
authentication event at the IdP) and browses to an SP.  The SP submits 
an AuthnRequest to the IdP to initiate SSO on behalf of the user. At 
this point the IdP may:

      a) use the established session information to enable
    SSO with the SP.
      b) authenticate the user using the appropriate means required
    for the authentication context requested by the SP.
      c)    return failure for any of a number of reasons.

The IdP chooses which of these it will perform based upon a number of 
factors including the parameters of the request from the SP, the general 
policies at the IdP and, potentially, the user preferences about SSO at 
the IdP.  For example, the IdP would likely perform (b) if the 
ForceAuthn flag is set on the request or if the Authn that initiated the 
session is old enough that IdP policies require a reauthentication.

Note that (a) is not permitted, IMHO, if ForceAuthn is set since (a) 
does NOT involve an invocation of the authentication process, but rather 
the IdP re-reading some of its session information and that, IMHO, is 
not a re-authentication..  However, (b) may involve authantication 
interactions with the user's client that are invisible to the user.

Conor








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]