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


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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

Subject: RE: [saml-dev] Introduction & Question about the "heaviness" of S AML

Neil (and others) - I wouldn't focus too much on the assertion validity period when talking about web sso.  Just to be clear, I hope no one is confusing an assertion validity period with when a user's login session at the authority will expire.  Login expiration periods are strictly a local security domain policy issue. The authority will have its own login session timeout policy for the user session and the sso-created login at the relying party site will have its own login session timeout policy.


The assertion validity period is simply a way for the SAML authority to define how long it is willing to permit an assertion that it creates to be considered valid.  SAML just mandates that a relying party must not use the information in an assertion before the NotBefore time and not after the NotOnOrAfter time.  Every vendor, I assume, will want to allow the "window" for assertion validity to be configurable.


The reason I say that the validity period isn't so important to web sso is that, typically, the authority is just asserting that an event (an authentication) occurred at a specific time in the past. Here I am assuming a web sso assertion that just contains an AuthenticationStatement. The AuthnStatement declares that a particular Subject authenticated with a particular method (the AuthenticationMethod) at a specific time (the AuthenticationInstant).  It says nothing about when that user's authentication at the authority will expire.  When the assertion expires, it doesn't change the fact that the authentication took place as described.  It simply means that the authority doesn't want you to use the assertion after the assertion expires.


Now, assertion validity periods are much more important when talking about attribute statements and authorization decision statements where the authority may want to limit how long a relying party should rely on the assertion data (e.g. attribute values may change frequently, authorization settings may need to be re-evaluated, etc).


Rob Philpott

RSA Security Inc.

The Most Trusted Name in e-Security

Tel: 781-515-7115

Mobile: 617-510-0893

Fax: 781-515-7020




-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu]
Wednesday, November 13, 2002 11:11 AM
To: ngehani@us.checkpoint.com; 'John Herendeen'; 'Adam Theo'; 'Mark Wilcox'
Cc: saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] Introduction & Question about the "heaviness" of S AML


> So we are relying on the application to set the limit for

> each assertion sent?


If it's an application that's managing the SSO process, then yes.

Otherwise it's probably a SSO module of some sort at the target that

manages SSO on behalf of multiple applications.


There is only one SSO assertion to get a session established, it's not a

constant process. The point is, protection against clock skew is

balanced against the desire for the SSO assertion to be short-lived, and

the profile doesn't say what you have to decide. An hour is clearly

wrong, but five minutes might be considered too short by some.


> When you say "relying site" which one do you mean? Sender or receiver?


The receiver of a SSO assertion (the target) is the one relying on the



> Is there a default timeout that can be configured?


I'm sure most implementations do (mine is currently not even

configurable in its beta form), but that's not part of the spec.


-- Scott




To subscribe or unsubscribe from this elist use the subscription

manager: <http://lists.oasis-open.org/ob/adm.pl>

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

Powered by eList eXpress LLC