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] IDP Service


I have following queries, ay be corollary of the last query

1. All profiles I have seen are talking about single IDP and SP. Consider the case where there are one IDP and more than one SPs.  Suppose the User access the SP1, complete the authrequest and response cycle and get the assertion. While the user wants to access the SP2 does it required to do all from beginning or does it make use of already federated Identity information.

Can anybody tell how will the flow go here? 

The flow between the SP through the principal's browser to the IdP will have the same options for each SP that the user visits (e.g. the SP can choose whether or not they want to use the Post profile, artifact profile, etc.) and the SP can initiate the SSO or the IdP can "push" the SSO response to the SP.


In the SSO world, the main difference from SP1 interactions and SP2 interactions is that the first time SSO is initiated the user will typically be prompted to authenticate with the IdP.  On subsequent interactions in the same "session" the user will typically *NOT* be prompted (although there are many cases that may require additional credentials such as  policy requirements for reauthentication on a timely basis, or the SP requiring a different strength of authentication, etc.).

2. Where and how the federated Identity information will be kept. Will it be in SP, IDP or user-agent? 

Each SP keeps track of the federated Identity of the user at their service and the IdP keeps track of the federated identities for the user at each SP.  In general, the user-agent is simply a commuinications path that allows the IdP to associate the SSO sessions at different SPs to a single authentication session with the user (typically via some form of state stored in the user agent)..


There are some cases where the principal may have multiple active identities that are managed by the ECP user agent (so that I could be logged in as cpc and as ConorP at the same or different IdP and the ecp is smart enough to help me choose which of those identities is used at which SP).  This is done by the ECP being aware of the authentication sessions and choosing which state is sent to the IdP during the authentication process (there are no specific saml protocols necessary to support this model).



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