Use Case and Requirements Working Group Issue: User Sessions

["Pilz, Gilbert" <gpilz@jamcracker.com>]

This is the third in a series of issues referred to the TC by the Use Case
and Requirements Working Group. By now you should have all received the
messages concerning "Pass-thru Authentication" from Hal Lockhart and "AuthZ
Decisions" by Darren Platt. To quote Darren, "The purpose of these writeups
is to level-set everyone on the current state of the debate so that we don't
have to recap during the concall, but rather move forward.  A goal for the
writeup is to structure the issues such that some decisions can be made that
we can build upon."

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

The following is a synopsis of the current state of the debate on the issue
of "User Sessions".

The glossary
(http://www.oasis-open.org/committees/security/docs/draft-sstc-glossary-00.h
tml) defines User Sessions as "A 'container' for the authentication and
attribute assertions that apply to a given system entity through the
principals incarnated by that entity. The purpose is to maintain the
relationship of the assertions to the initiating entity."

The February voting on Issue Group 3 (Sessions) saw approval for the
inclusion of the concepts of "user sessions" and "local logouts" but no
approval for the inclusion of the concepts of "session timeouts" or "session
logouts". The March F2F re-confirmed a general consensus on the need for
"User Sessions" (including the successful motion to place "User Sessions"
into its own use case) but little in the way of specific requirements. The
overall question is; what is the nature and purpose of SAML User Sessions ?

One of the motivating ideas behind the original notion of User Sessions is
to provide a user that is working with multiple, cross-domain, distributed
applications the experience of a single, coherent system. Once authenticated
with an authentication authority the user should be able to launch an
arbitrary number of applications without the need to re-authenticate (with
the understanding that each of these applications has been configured to
trust the assertions of the authentication authority). It should be possible
to configure each of these applications such that none of these applications
will "time out" (i.e. terminate the users application-level session due to a
pre-defined period of inactivity) as long as the user is "currently active"
in any one of the other applications. Furthermore it should be possible for
the user to easily logout from the entire distributed system by directing
the "Session Authority" to terminate each of the application-level sessions.

These notions of "distributed time out" and "distributed log out" are
referenced in the Phillip Hallam-Baker's Strawman Architecture document
(http://www.oasis-open.org/committees/security/docs/draft-sstc-core-vmodel-0
1.pdf), the AuthXML specification
(http://www.oasis-open.org/committees/security/docs/draft-authxml-v2.pdf),
and the ITML Session Management specification
(http://www.oasis-open.org/committees/security/docs/draft-orchard-itml-sessi
on-00.pdf).

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

The following is a list of assertions and questions; assertions are things
we feel pretty sure about and questions are areas in which we need input.

Question 1: Does the SSTC view the proposed functionality ("ability to
provide a coherent view of multiple, cross-domain, distributed
applications") as within the scope of the SAML specification ?

Some possible answers are:

a.) Yes, this functionality is within the scope of SAML.
b.) No, this functionality is not within the scope of SAML.

Question 2: Most existing applications have some notion of a "session" that
contains the state shared between the user and the application. Applications
that employ authentication and authorization usually bind the authentication
and attribute assertions of the initiating user to this session. In the case
where SAML is used by applications that maintain sessions, what is the
relationship between SAML User Sessions and these application-level
sessions?

Some possible answers are:

a.) SAML User Sessions should be able to act as higher-level,
"uber-sessions" over the individual application-level sessions.
b.) Application-level sessions can be (re)implemented using SAML User
Sessions.
c.) SAML User Sessions are orthogonal to application-level sessions.

Answer (a) is consistent with the original notion of User Sessions as
introduced by the AuthXML and ITML Session Management specifications

Answer (b) seems somewhat impractical. In the same way that SAML avoids
defining new authentication mechanisms or crypto protocols, it shouldn't
define new mechanisms for re-implementing existing session management
solutions.

Answer (c) begs the question "what is the nature and purpose of SAML User 
Sessions"?

If you selected answers 1a and 2a then this leads to . . 

Assertion 1: The concept of User Sessions requires the existence of a
"Session Authority" who's job it is to create and maintain the relationship
of the authentication and attribute assertions to their initiating entity.
Examples of the software entities that might serve this function are:

     Web Server/Application Server hosted on Web Services integration server
     Enterprise Intranet sign-on web/app server
     Enterprise Integration Portal web/app server

Question 3: If you accept answer (a) to question 2 the next issue is "to
what extent should it be possible to control the behavior of an
application-level session based on the state of the SAML User Session?"

This breaks down into three sub-questions:

Question 3.1: Should application-level sessions be able to defer their
normal timeout behavior based on the fact that the SAML User Session is
still active (i.e. one or more of the other application-level sessions that
make up the SAML User Sessions is still active)?

What we are really talking about here is SAMLs ability to support a certain
type of application behavior. One could argue that it is irrelevant whether
User Sessions support deferred timeouts since, as long as the applications
in question support single sign-on, it is easy enough to transparently
re-authenticate the user with an application that has timed out. The
question is whether the application will be able to preserve the state of
the users interaction across the timeout and re-authentication operations?
Most applications do not provide this capability. Therefore, in order to
support the desired functionality ("ability to provide a coherent view of
multiple, cross-domain, distributed applications"), it is necessary to defer
the applications timeout behavior to ensure that the users state will not be
lost.

Question 3.2: Should SAML User Sessions be capable of terminating their
component application-level sessions based on a "logout request" from the
session initiator ?

Support for this position seems to be implied by section 5.4 Phillip
Hallam-Baker's Strawman Architecture document, the AuthXML and ITML Session
Management specifications.

Question 3.3: Should SAML User sessions support a "time-in" type of status
request that allows an application-level session to tell the Session
Authority that the user is still interacting within the context of that
application-level session?

This is proposed by Prateek Mishra and appears to be the type of message
intended in section 3.2.8 of the AuthXML specification.

--
 <<Gilbert Pilz.vcf>>

Gilbert Pilz.vcf