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 

mailto: 

 

 

-----Original Message-----

From: Scott Cantor [mailto:] 

Sent: Wednesday, November 13, 2002 11:11 AM

To: ; 'John Herendeen'; 'Adam Theo'; 'Mark Wilcox'

Cc: 

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

assertion.

 

> 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>