Session Management and Logout in SAML 2.0
Working Draft 00, 07 September 2003
Document identifier:
draft-sstc-sessions-00
Location:
http://www.oasis-open.org/committees/security/docs
Editors:
John Kemp, individual <john.kemp@earthlink.net>
Contributors:
Abstract:
This document proposes candidate requirements for session management in SAML 2.0. Subsequent versions will be augmented with use case and mechanism proposals.
Status:
Interim draft. Send comments to the editors.
Committee members should send comments on this specification to the security-services@lists.oasis-open.org list. Others should subscribe to and send comments to the security-services-comment@lists.oasis-open.org list. To subscribe, send an email message to security-services-comment-request@lists.oasis-open.org with the word "subscribe" as the body of the message.
For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Security Services TC web page (http://www.oasis-open.org/committees/security/).
Table of Contents
1Introduction 3
1.1Notation 3
2Candidate Session Requirements for SAML 2.0 4
2.1System Entity Logout 4
2.2Propogation of Logout 4
2.3Session timeout 4
3Use Cases 5
4Candidate Mechanisms 6
5Security Considerations 7
6References 8
1Introduction
This document proposes candidate requirements for session management and logout in SAML 2.0. Subsequent versions will be augmented with use case and mechanism proposals.
1.1Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in IETF RFC 2119. [RFC2119]
Listings of productions or other normative code appear like this.
Example code listings appear like this.
Note: Non-normative notes and explanations appear like this.
Conventional XML namespace prefixes are used throughout this specification to stand for their respective namespaces as follows, whether or not a namespace declaration is present in the example:
The prefix saml: stands for the SAML assertion namespace [SAMLCore].
The prefix samlp: stands for the SAML request-response protocol namespace [SAMLCore].
The prefix ds: stands for the W3C XML Signature namespace, http://www.w3.org/2000/09/xmldsig# [XMLSig].
The prefix SOAP-ENV: stands for the SOAP 1.1 namespace, http://schemas.xmlsoap.org/soap/envelope [SOAP1.1].
The prefix wsse: stands for the WS-Security 1.0 namespace
http://schemas.xmlsoap.org/ws/2002/04/secext [WS-Sec].
2Candidate Session Requirements for SAML 2.0
This section proposes candidate session management requirements for SAML 2.0, including session indexing, logout, and timeout. Some of these requirements have been addressed within the Liberty Alliance Identity Federation Framework (ID-FF) [LibBP] [LibPS], using approaches that may also be suitable for integration within SAML.
ISSUE: SAML currently speaks in terms of authentication authorities and relying parties, but Liberty speaks of identity providers nd service providers. How should these terms be aligned?
2.1Definitions
Session::
A continuous period of time for which a Principal is considered to be authenticated for the purposes of all requests that the Principal makes to service providers who are relying parties for assertions from the authentication authority who provided the initial authentication.
Session Logout:
When a Principal takes a specific action, such as clicking a 'Logout' button, which results in any authentication assertions that they had used to gain access to services, either at the service provider whose logout mechanism they had invoked, or other service providers holding authentication assertions received during this session, to be invalid. After a Principal-initiated logout, any authentication request for that Principal must result in the generation of a new session by the authentication authority.
Session Timeout:
After some specified period of time (the timeout period), during which the Principal has taken no action, either at the authentication authority, or any replying parties for authentication assertions generated during this session, the Principal's session is considered to be timed-out.
2.2System Entity Logout
SAML 2.0 shall support the ability for a Principal to logout at either an authentication authority, or any relying party which maintains a session based on an assertion from an authentication authority.
2.3Propogation of Logout
SAML 2.0 shall provide a facility for an authentication authority receiving a logout request from a Principal to propogate that logout request to all relying parties.
Additionally, SAML 2.0 shall provide a facility for a relying party receiving a logout request from a Principal to notify the authentication authority which provided the assertion associated with that session of that Principal's global logout request.
2.4Session timeout
SAML 2.0 shall provide a mechanism for an authentication authority to mark a session as being time-limited.This mechanism should allow for the potential for a session length to span the provision of multiple time-limited assertions to relying parties (ie. There may be a timeout restriction on individual assertions, but this can be a different value than that provided for a session, which might result in multiple assertions being held during a single session without the user being re-authenticated during the session).
3Use Cases
3.1Single Signon session establishment
The Principal navigates to the provider of an arbitrary service. She is authenticated via an authentication authority related to the service provider. At this point, both the authentication authority, and the service provider establish a session for that Principal.
Actors
Principal, Service Provider, Authentication Authority
Primary path
Principal attempts to access a service. The service provider sends an authentication request to an authentication authority for the Principal. The authentication authority authenticates the user, and creates a session.
3.2Single Logout
The Principal clicks a 'logout' button at either the authentication authority or some arbitrary service provider. His authenticated browsing session is terminated, both at the site where he explicitly logged out, at the authentication authority who provided assertions for that Principal during that session, and any other relying parties for assertions provided by that authentication authority for that Principal during the session.
Actors
Principal, Service Provider, Authentication Authority
Primary Path
3.3Global Timeout
The authentication authority specifies a session timeout value. If the authentication authority has received no other SAML requests specifying that Principal's session, then it must re-authenticate the Principal.
Actors
Principal, Service Provider, Authentication Authority
Primary Path
Principal authenticates, beginning a new session (see 3.1). Principal does nothing at either this service provider or any other which has received authentication assertions linked to this session, for some period of time longer than the timeout value supplied in the last response supplied linked to this session. When the authentication authority next receives an authentication request specifying this session for this Principal, they must re-authenticate the Principal.
4Candidate Mechanisms
(NOTES ONLY – not to be considered a proposal!)
Protocol for single logout – LogoutRequest and LogoutResponse (see [LibertyPS], [LibertyBP] Single Logout protocol)
Session Index returned with the authentication assertion from authentication authority. If index is provided to relying parties, they MUST use it in subsequent authentication requests for that Principal, UNLESS session is logged out (see LibertyPS], [LibertyBP] Single Signon protocol).
For global timeout, session timeout value can be advertised by authentication authority. Complexity comes in because AA could issue same timeout value to another relying party, which SHOULD extend the session length for the first (and any other) relying party asserted prior to this event. But if all this is managed by authentication authority, it all works. If they get an authentication (or other) request and that session is done, they should re-auth the Principal. OR, should they pro-actively send LogoutRequest messages to all relying parties when the session times out? What is the difference between a validity period being set on an authentication assertion, and a separate session validity period?
What exactly is a session? IMO, a session begins when a Principal is authenticated at an authentication authority. The service provider receives an assertion which states this. To indicate a timeout value, the authentication authority could supply a <Condition> element with a NotOnorAfter timestamp, at which point, the assertion should be considered invalid, and thus the session is ended.
If an SP has an assertion where the NotOnorAfter timestamp has been exceeded, they MUST send a new authentication request to the AA. BUT, the AA can say (based on the SessionIndex) that the Principal was active somewhere else, and thus issue a new assertion with a new NotOnorAfter value based on the time of the last samlp:Request received by them with that SessionIndex.
5Security Considerations
TBS.
6References
[LibBP] Liberty Alliance Project, Liberty ID-FF Bindings and Profiles Specification, August 2003.
[LibPS] Liberty Alliance Project, Liberty ID-FF Protocols and Schema Specification, August 2003.
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.
[SAMLBind] E. Maler, et al., Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML), available from http://www.oasis-open.org/committees/security, OASIS, May 2003.
[SAMLCore] E. Maler, et al., Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML), available from http://www.oasis-open.org/committees/security, OASIS, May 2003.
[SAMLSecure] E. Maler, et al., Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML), OASIS, July 2003.
[SOAP1.1] D. Box et al., Simple Object Access Protocol (SOAP) 1.1, http://www.w3.org/TR/SOAP, World Wide Web Consortium Note, May 2000.
[WS-Sec] Web Services Security (WS-Security) specifications, OASIS.
[XMLSig] D. Eastlake et al., XML-Signature Syntax and Processing, http://www.w3.org/TR/xmldsig-core/, World Wide Web Consortium.
Revision History
|
Rev |
Date |
By Whom |
What |
|
wd-00 |
2003-09-05 |
John Kemp |
Initial candidate requirements. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Notices
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.
OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.
Copyright © OASIS Open 2003. All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
draft-sstc-sessions-00 25 August 2003
Copyright
© OASIS Open 2003. All Rights Reserved. Page