Sessions Solution Proposal(s) outline

[John Kemp <onezero@bcn.net>]

As promised on last week's call, an outline proposal for session 
management in SAML 2.0 follows below. Comments and/or questions 
regarding this are appreciated.

Cheers,

- JohnK

-------------------------------------
Sessions Solution Proposal(s) outline

Introduction

The idea of session can be quite complex, particularly in a multi-site 
SSO environment. There are usually three parties to what we currently 
consider a session - the SAML authority (authority), a service provider 
(SP), and a service user. The idea of a session can really only be 
applied to sets of two of these parties (user at authority, user at SP, 
and SP at authority). Session state may be maintained by the SP or the 
authority for interactions between these parties.

This document (email) proposes potential solutions that would satisfy 
the currently accepted requirements involving the notion of session in 
SAML 2.x.

Notes:

i) Impact of SSO changes on session support - it is not clear what 
changes will result from SSO changes being proposed, so currently I am 
assuming changes would be made to existing SAML protocols.

Local vs. Global

A service provider (or authority) may wish to maintain a session state 
with regard to a local user. This session relates only to that user's 
actions with regard to the service provided at that site. Such a 
session state may be maintained (in http-based systems) using a cookie, 
or via a URL appended token (for example). This session artifact may 
provide no benefit to the user at any other site (ie. it cannot be used 
to gain access to a service provided by some other SP).

A global session will exist if an artifact of session state maintained 
by an authority is provided to one or more SPs by the authority. This 
session state is maintained by the authority, and an index or some 
other session artifact is passed between participating SPs and the 
authority in protocol message flows. Individual SPs may or may not use 
this artifact to link to the session that they maintain directly with 
the user.

Basic Requirements Summary

R1) Single logout by user - user should be able to logout from a 
session either at authority or a service provider.
R2) Single logout by administrator - an administrator should be able to 
logout an individual from the authority.
R3) Single logout by system - the authority should be able to logout a 
user if it determines that the user's credentials may have been 
compromised.
R4) Timeout - user should be logged out automatically after some period 
of time, specified by agreement between SP and authority, regardless of 
their activity (or lack thereof).
R5) Idle timeout - User should be logged out automatically after some 
period of time due to inactivity.
R6) Multiple sessions - it should be possible for a user to maintain 
multiple sessions with an SP (for example, one on their phone browser, 
one from their PC) - in the case of single logout or timeout, it should 
be possible for the authority to locate an individual assertion, and 
related session for termination.
R7) Multiple assertions per session - the length of a session may be 
greater than a span of an individual assertion supplied as part of the 
session.

Relationship to Authentication and SSO

It is generally assumed that a session relates to an authentication 
event, or SSO. However, the degree of coupling between session and 
authentication can be either tight or loose. It is possible both to 
imagine a separate session authority that may determine itself whether 
the user is adequately authenticated (perhaps by contacting an 
authentication authority) and hence supply a session, or that an 
authentication authority itself will just supply some artifact of a 
session that it creates upon authenticating the user.

PROPOSAL:

P1) We allow a SAML authentication authority itself to create and 
maintain a session. We do not define a separate session authority. 
Defining a separate SAML session authority would imply that we also 
have to determine (and possibly specify!) the relationship between such 
an authority and an authentication authority. We can accomplish most 
(if not all) of the requirements without establishing a separate 
authority.

Note: If we *were* to define a separate session authority, I would 
recommend creating new Query and Statement elements to carry the 
session data. This could then be logically separate from 
authentication, and we would then have to further define any 
relationship between a session authority and an authentication 
authority.

PROPOSAL:

P2) We provide a mechanism for allowing the authentication authority to 
maintain state with an SP regarding the authentication status of a 
named Principal. This may be accomplished by the authority providing an 
artifact of session state in the original authentication statement, 
which is then passed back and forth between the SP and the authority on 
subsequent requests, and used when attempting single logout (see P4). I 
would suggest this be accomplished by adding a SessionIndex attribute 
(as an xsd:string) to the saml:AuthenticationStatement. This would be 
an optional attribute. Use of a session identifier must not break any 
pseudonymous NameIdentifier(s) established for the Principal between 
the SP and the authority.

Single Logout

PROPOSAL:

P3) We create a request/response protocol, based on the 
samlp:Request/Response, for single logout, and create appropriate 
bindings for the protocol.

SP1 -> LogoutRequest -> Authority -> SP2, SP3, SPn
SP1 <- LogoutResponse <- Authority
Authority -> LogoutRequest -> SP1, SP2, SPn
Authority <- LogoutResponse <- SP1, SP2, SPn

Note: This would meet all of the logout requirements as noted above for 
global sessions. It would also possibly meet the non-idle timeout 
requirements. It would NOT (on its own) meet the idle timeout 
requirements.

Idle Timeout Protocol

In order to determine whether a user has been idle across a network of 
sites, it is necessary either for individual services to inform the 
authority of user (in)activity or the authority to poll the 
participating services for information regarding user activity at each 
site. It would be possible to construct a (somewhat complex) protocol 
set whereby the authority polls each individual participant in the 
network, requesting activity information on a named Principal. The 
participating service providers would then inform the authority as to 
whether the named Principal had been active within the idle timeout 
period. If the authority determined that the Principal had been 
inactive at ALL participant services for the length of the idle timeout 
period, they would then initiate the single logout protocol (see P3) 
with each participant, instructing them to invalidate the related 
session(s).

P4) We create a polling protocol, based on the samlp:Request/Response 
for determining user idleness at service providers, and appropriate 
bindings for the protocol.

Authority -> ActivityRequest -> SP1, SP2, SPn
Authority <- ActivityResponse <- SP1, SP2, SPn

( Authority -> LogoutRequest -> SP1, SP2, SPn
Authority <- LogoutResponse <- SP1, SP2, SPn )

Note:

I believe that such a two-stage protocol may have a lot of dependence 
on things that we cannot control, such as network delays, which might 
in practice limit the effectiveness of the protocol.

Timeout Notifications

It may be useful to have the authority notify a participating SP of 
timeout periods related to a session.

P5) We provide for a SessionTimeout and a SessionIdleTimeout value to 
be present in authentication statements, related to the session state 
artifact mentioned in P3. The authentication authority would be 
indicating that at such times it would either attempt a single logout, 
or poll for idleness before executing a single logout.

- JohnK