Title: Message
Hi
just another clarification on this topic:
first
of all looking at the Core spec I have the following
question:
under
the SINGLE LOGOUT protocol section 3.7.3.1 (in case a request is received at the
Session Participants) says:
starting a 2591:
If the sender is the authority that provided an assertion
containing an
authentication statement linked to the principal's current
session, the session participant MUST invalidate
the principal's session(s) referred to by the <saml:BaseID>,
<saml:NameID>, or
<saml:EncryptedID> element,
and any <SessionIndex>
elements supplied in the message. If
no
<SessionIndex> elements are
supplied, then all sessions associated with the principal MUST be
invalidated.
in the
section 3.7.3.2 (in case request received at the Session authority) it
says:
starting at 2628:
Terminate the principal's current session as specified by the
<saml:BaseID>, <saml:NameID>,
or <saml:EncryptedID> element, and
any <SessionIndex> elements present in the logout
request message.
It
doesn't say : If no
<SessionIndex> elements are supplied,
then all sessions associated with the principal MUST be
invalidated.
I'm
assuming it would be the same case as 3.7.3.1.
Now
Let's say I'm Principal: PRINC and logged as USERA on SPA using my Laptop and
(SessionIndexA),
USERB_C (but still same principal) logged on
SPB(sessionindexB)/SPC(sessionindexC) using my PDA
Now if
USERB_C logs out from SPB (then a Logout request is sent to the IDP) there are 2
options:
1)
it could send a logout request with SessionIndexB.
2) it
could send a logout request without SessionIndexes.
In
case 1 SessionInextB session for the principal PRINC is
killed.
In
case 2 from what the spec says (core all sessions associated with the principal MUST be
invalidated.)
Does
it mean killing the sessions on SPA too ?
Thanks.
Giuseppe.
-----Original Message-----
From: Philpott, Robert
[mailto:]
Sent: 27 October 2005
18:20
To: Sarno, Giuseppe [MOP:GM15:EXCH]; Conor P.
Cahill
Cc:
Subject: RE:
[saml-dev] Logout from a single SP.
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.
Thanks.
Giuseppe.
-----Original
Message-----
From: Conor P.
Cahill [mailto:]
Sent: 27 October 2005 17:11
To: Sarno, Giuseppe
[MOP:GM15:EXCH]
Cc:
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??)
Absolutely.
And in this case
the Logout request could contain just the SessionIndex the SP wants to
remove.
Correct.
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.
Example:
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).
Conor
