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] Logout from a single SP.

Title: Message

So even if I was same user same browser /same window (just clicking a link resourced on a different SP) and going from SPA to SPB

Is then up to the IDP to decide when the Auth Request comes from SPB whether to actually use the Same Index or Assertion back to the SPB.

[RSP] IDP’s must always generate a new assertion for each SSO exchange to different SP’s. In SAML’s web SSO profile, the assertion generated by the IDP for an SSO exchange with SP-A MUST include a SubjectConfirmationData element with a “Recipient” attribute set to SP-A’s Assertion Consumer Service  URL.  SP-A is supposed to check this attribute to ensure that the assertion was intended for its ACS endpoint. If the same assertion was sent to SP-B, it is supposed to be rejected by SP-B.


I guess though the Assertion (in case of SPB) could be different depending if the requirements/data in the request (or policy etc.) requires the generation of a different Assertion.


I guess in this case it would be nice to distinguish the case of UserB using same browser etc. from the case of UserB using a different mean or equipment in order to distinguish the sessions but I guess this is more down to info passed from the client and implementation specific.

[RSP] To correctly implement the desired semantics, implementations will usually have to track (via some implementation-specific manner), which browser/device is in which session. For browsers, this might imply a special implementation-specific “session” cookie, for example.





-----Original Message-----
From: Conor P. Cahill [mailto:concahill@aol.com]
Sent: 27 October 2005 17:11
To: Sarno, Giuseppe [MOP:GM15:EXCH]
Cc: saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] Logout from a single SP.

Giuseppe Sarno wrote on 10/27/2005, 12:01 PM:

It seem indicating that the Principal can have multiple SessionIndexes and as such different AuthAssertions associated with him (Is this right??)


And in this case the Logout request could contain just the SessionIndex the SP wants to remove.


How can this happen ?

The same user is logged in from 2 or more different "locations"... Note that locations include different browsers, sometimes different instances of the same browser, different devices, different computers, etc, etc.  There are even reasonable situations where the IDP could in a single browser context support multiple sessions for the user.


If the user access SPA and the IDP creates AssertionA with SessionIndexA and then he goes to SPB would he get AssertionB/SessionIndexB?

or still AssertionA/SessionIndexA ? or even AssertionB/SessionIndexA ?

There is no requirement as to the session index value across different providers.  The key issue is that internally at the IdP, the IdP is able to figure out which authentication "session" the SP is referring to when the SP sends a message to the IdP (and vice-versa as the user could also be visiting the same SP from two different IdP authenticaiton sessions) (e.g. I could be shopping at Amazon from my phone and from my computer at the same time).

I have seen implementations that use the assertionID for the sessionIndex value (so that each Assertion would have a different value in the session index value, but the IdP maintains a table to correlate which SessionIndex corresponds to which session).  I have also seen implementations that use small sets of small integers (e.g. 0, 1, 2, 3, etc) to represent the session index and the same value is used for assertions associated with the same authentication session across multiple SPs (the fact that it is a small set of small integers means that across different principals the same IDs are heavily reused and so the Session index can't be used to correlate actions of the same principal across different SPs).


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