OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Dynamic Session Proposal


This proposal is intended to cover all the requirements identified for
dynamic sessions in  SAML. In addition it permits each Service Provider to
specify a distinct global timeout value  at which it alone will be notified.
This value must be less (or equal) to the common global  timeout value.

Note: nothing in this proposal prevents an SP from implementing a local
timeout or forced  reauthentication based purely on information available to
it locally. This proposal is only  concerned with informaiton shared
globally.

Definition: Touch time - the most recent time activitey has been observed on
a session.

Actors:

End User

Session Participant - a Service Provider that participates in a global
session by requesting  session ids, reporting touch times and implementing
logouts. (conveniently SP stands for both)

Session Authority - Central service that creates and tracks sessions,
associates  Authentication Assertions with sessions, tracks touch times,
determines when timeouts have  occured and reliably requests logouts upon
timeout, user or admin request

Various values must be agreed upon by the SA and SPs. This can be done on
line or via out of  band agreement. This mechanism is not discussed.

Values include:
1) Common Global Timeout Interval
2) SP-specific Global Timeout Interval (if any)
3) Touch time reporting interval
4) Maximum Session Lifetime

The issue of who is allowed to force an administrative logout is not
addressed by this  proposal.

In addition, there is the issue of the relationship between Authentication
Acts and Sessions.  If a session can be associated with more than one
Authentication Act (i.e. Authentication  Statement) then there must be some
rule as to how the SA knows whether two AuthN Stmnts should  be associated
with the same session. I propose this be left as an implementation option.
However, this may require defining additional messages to this proposal to
allow an SP to  discover additional AuthN Stmnts that happened after it
first learned about the session.

Message Exchanges:



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]