Dynamic Sessions Proposal (long)

[John Kemp <john.kemp@nokia.com>]

Hi,

Based on earlier proposals from myself, Hal (and to some extent Scott), 
I have taken the liberty of expressing a more concrete proposal to meet 
the stated requirements. I am proposing two basic things:

1) We use assertions to represent sessions in the SAML protocol, thus 
the AssertionID will be equivalent to the Session ID, and the assertion 
validity period will indicate the session validity period.
2) We implement a "Single Logout" protocol as described in some detail 
below.

I believe that these two things alone meet all requirements currently 
accepted for sessions, apart from idle timeouts. I also suggest below 
that we can possibly meet the idle timeout requirement by modifying the 
Single Logout protocol to poll for user activity at session 
participants.

I look forward to discussing this at the meeting, but comments are also 
welcome in response to this email.

Regards,

- JohnK

------------------------------------------

0. Introduction

The proposals outlined below will take care of the requirements 
currently expressed for:

i) Ability for SAML entities to maintain a session
ii) Local (single SP) and global (all SPs) logout
iii) Non-idle local and global timeout

I have not fully addressed the stated requirements for idle timeout 
with a complete proposal, but I have suggested an idea that we could 
possibly use to meet this requirement.

AA = authentication authority
SP = service provider/session participant
SA = session authority

1. That we use the SSO assertion ID and validity period to represent 
respectively the SessionID at the AA and indicated lifetime of the 
session at the AA.

No schema/text changes would be necessary above and beyond those being 
made for proposed SSO changes regarding the validity period of 
assertions.
This would allow a simplification of the idea of session, and directly 
link the session to the SSO assertion, giving a concrete protocol 
artifact to point at during logout/timeout cases.
It implies that every AA may also essentially be an SA for relying 
parties of their assertions.
In order to deal with multiple authentications being linked to a 
session, we need to consider how AAs would communicate about the 
Principal. One option is to use the "SSO proxy" concept. This would 
allow one AA to not have to "know" the Principal. The other possibility 
is for there to be a relationship between two AAs (one acting as the 
SA) such that they can talk about the Principal, and allow one AA to 
get relevant assertions for that subject from the other AA.

2. Logout

2.1 Processing Rules

2.1.1 General

The Single Logout Protocol provides a message exchange protocol by 
which all sessions provided by a particular session authority are 
near-simultaneously terminated. The Single Logout Protocol is used 
either when a Principal logs out at a service provider or when the 
Principal logs out at a
session authority.

The Principal may have established authenticated sessions both with the 
session authority, and individual service providers, based on 
authentication assertions supplied by the session authority.

When the Principal invokes the single logout process at a service 
provider, the service provider MUST send a <LogoutRequest> message to 
the session authority that provided the authentication service related 
to that session at the service provider.

When either the Principal invokes a logout at the session authority or 
a service provider sends a logout request to the session authority 
specifying that Principal, the session authority MUST send a 
<LogoutRequest> message to each service provider to which it provided 
authentication assertions under its current session with the Principal, 
with the exception of the service provider that sent the 
<LogoutRequest> message to the session authority.

Recipients MUST validate any signature present on the messages 
specified in this protocol. To be considered valid, the signature 
provided must be the signature of the <Issuer> contained in the 
message.

2.1.2 Service Provider Rules

When the service provider receives the <LogoutRequest> message, the 
service provider MUST validate the session authority's signature 
contained in the <ds:Signature> element. If the signature is that of 
the authority that provided the authentication for the Principal's 
current session, the service provider MUST invalidate the Principal's 
session(s) referred to by the <saml:NameIdentifier> element, and any 
<SessionIndex> elements supplied in the message.

The service provider MUST apply the logout request message to any 
assertion that meets the following conditions, even if the
assertion arrives after the logout request:

   - The <SessionIndex> of the assertion matches one specified in the 
logout request.
   - The assertion would otherwise be valid
   - The logout request has not yet expired (determined by examining the 
NotOnOrAfter attribute on the message).

2.1.3 Session Authority Rules

When a session authority receives the <LogoutRequest> message, the 
session authority MUST validate that any signature present on the 
message is the signature of a service provider to which the session 
authority provided an authentication assertion for the current session. 
If that holds, the session authority SHOULD do the following:

   - Send a <LogoutRequest> message to each service provider for which 
the session authority provided authentication assertions in the current 
session, other than the originator of the <LogoutRequest>.
   - Send a <LogoutRequest> message to any session authority on behalf 
of whom the session authority proxied the user's authentication, unless 
the second authority is the originator of the <LogoutRequest>.
   - Terminate the Principal's current session as specified by the 
<saml:NameIdentifier> element, and any <SessionIndex> elements present 
in the logout request message.

When constructing a logout request message, the session authority MUST 
set the value of the NotOnOrAfter attribute of the message to a time 
value, indicating an expiration time for the message.

If an error occurs during this further processing of the logout (for 
example, relying service providers may not all implement the Single 
Logout profile used by the requesting service provider), then the 
session authority MUST respond to the original requester with a 
<LogoutResponse> message, indicating the status of the logout request. 
The value "XXX" is provided for a second-level <samlp:StatusCode>, 
indicating that a service provider should retry the <LogoutRequest> 
using a different profile.

2.2 Logout message

   <element name="LogoutRequest" type="samlp:LogoutRequestType"/>
   <complexType name="LogoutRequestType">
       <complexContent>
           <extension base="samlp:RequestAbstractType">
               <sequence>
                   <element ref="saml:NameIdentifier"/>
                   <element name="SessionIndex" type="string" 
minOccurs="0" maxOccurs="unbounded"/>
               </sequence>
               <attribute name="reason" type=”string” minOccurs=”0”/>
               <attribute name="NotOnOrAfter" type="dateTime" 
minOccurs="0"/>
           </extension>
       </complexContent>
   </complexType>

Values for the ‘reason’ attribute (which is informative only):
urn:oasis:names:tc:SAML:2.0:logout:user
urn:oasis:names:tc:SAML:2.0:logout:admin

Notes:

i)   Can target more than one session by including multiple 
SessionIndex elements
ii)  If sent by SP to SA, SA deletes session, and relays message to 
other relying parties
iii) Local sessions can just be deleted by the SP at their leisure, so 
they’re not addressed here.
iv)  NotOnOrAfter prevents any issue where the targeted assertion 
arrives after the logout message.
v)   Mostly follows same rules as [LibPS]
vi)  Could also add a 'type' attribute to indicate a timeout vs. logout?
vii) We need both HTTP and SOAP/HTTP bindings for this protocol.

2.3 LogoutResponse

Succeed/Fail

<element name="LogoutResponse" type="samlp:StatusResponseType"/>

3. Notes

i) The simple case is where a single authentication authority which is 
also a session authority provides SSO assertions and logout/non-idle 
timeout messages to session participants.

ii) There is a case where multiple authentication authorities may be 
supplying assertions to session participants. In this case, I think 
that either a) one authentication authority could use "SSO proxying" 
(W6) to get an authentication assertion regarding an unknown subject 
(maybe I don't know you, but I think this guy over there does) or b) 
the authentication authority and the session authority (also an AA) 
have a relationship such that they are able to talk about the subject, 
and the second AA can request assertions regarding that subject from 
the first AA, using those to create their own assertion for the 
subject. Each AA might specify different validity periods for their 
assertions (ie. their "sessions") but either way, I think this would 
just work.

iii) Activity reporting. Hal suggested that SPs would periodically 
report activity to the SA. I think this should be the other way round 
to minimize the amount of traffic - that the SA should poll for 
activity when it wishes to send a timeout. I also think that it might 
be possible by sending a "simulated" LogoutRequest message (and 
indicating on the message that it is an "activity-polling" 
LogoutRequest). Each SP would then respond, indicating the latest 
activity by that subject at the SP. If there had been no activity, the 
SA would follow up with a LogoutRequest to each SP, instructing them to 
log the user out.

iv) Assertion as session artifact.

v) Different local timeout values. The SP may wish to have a 20 minute 
timeout, when the assertion they received is valid for 60 minutes (for 
example). In this case, they may choose to delete the local session 
with the user, and then request 'ForceAuthn' on the next SSO request 
for that user, forcing a re-authentication of the subject.

4. References

[LibPS]			Cantor S., Kemp J., Liberty ID-FF Protocols & Schema 
Specification v1.2, Liberty Alliance Project