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


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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

Subject: Re: [saml-dev] Authentication on IDP.

Giuseppe Sarno wrote on 10/31/2005, 11:22 AM:

I'm trying to understand how the IDP knows what credential to apply in case of authentication challenge in a SSO scenario.

Pricipal seen as USER_A on SPA and USER_B on SPB and USER_IDP on IDP

SPA initiated:
SPA redirect (for example) authrequest to IDP indicating that the AuthContext_A AuthContext should be applied to the user.

Question 1: 
in case Context_A = userId/password, what user Id should be used ?
The one known at the IDP (USER_IDP) (which means we can only use the user identifier at the IDP for that circle of trust)

        or (in case the ID has the knowledge) could actually use the USER_A as known at SPA.

The IdP *always* authenticates the user using it's own credentials (so USER_IDP in your example).  It is possible (totally out of scope for SAML) for the IDP to have arrangements with other providers (such that if USER_IDP was xyz@mycompany.com,  the IdP would "delegate" the authentication via some backchannel to mycompany.com's authentication service), but the user is still logging in with an identity that is valid at the IdP, regardless of where the IdP obtained the credentials.

In a world without Federation, the USER_A, USER_B and USER_IDP would all be the same value so that the IdP could send USER_IDP in the assertion to SPA and SPA would be able to provide service.

In a typical world with Federation, the IDP sends a relationship specific identifier for the user (which, could also be a transient identifier,  but that usually means transient sessions at the SP).  So the IDP validates USER_IDP and then sends nameID 123 to SPA (assuming that at some point in the past USER_IDP was federated to that SP and the id 123 was assigned to that relationship).

SPB Initiated

Quetion 2:
in case of Context_B = again where the IDP gets the certificate from ?

Authentication contexts on an authnRequest are statemetns from the SP to the IdP asking the IdP to perform a particular action.   The action itself (i.e. how the IdP accomplishes the necessary steps to achive that context) is totally between the user and the IdP (although typically, when a Circle of Trust is setup the IDPs and SPs will agree on the set of contexts supported -- another thing out of scope for SAML).

So whatever the IdP uses to establish a context is between the IdP and the user.  If the user needs a certificate, then the user must have gotten that from the IdP at some point in the past.

I'm not sure what you're asking here.  The IdP always distinguishes the user at *its* system by the credentials provided by the user (and this sequence is out-of-scope for SAML).
SAML allows the user to request a list of contexts, a class, a class with a comparison (e.g. "stronger" than username/password).  I don't believe more than one can be in effect for a particular assertion (although you can define classes that are built by combinations of other classes -- classes are fully extensible -- for example, one could define a class that is username/password *plus* one-time-password).
Out of scope for SAML.  an IdP could have different certificates for every *request* if it wanted to and if it was able to get those certificates defined to the point that they would be trusted by the SP -- not that I am saying that this is reasonable or likely, just that it's possible.

I think that in many cases the IdP will use a single certificate across SPs, but that is an implementation decision for the IDP, not a specification in SAML.


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