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: SSO validity period



Currently SAML's SSO profile uses SAML's "generic" validity period
condition (NotOnOrAfter, specifically) to help address the essential
vulnerability of a bearer assertion, that if it falls into the wrong hands
it can be used for fraudulent authentication.  From saml-bindings-1.1,
lines 623-626:

  Values for NotBefore and NotOnOrAfter attributes of SSO assertions
  SHOULD
  have the shortest possible validity period consistent with successful
  communication of the assertion from source to destination site. This
  is typically on the order of a few minutes. This ensures that a stolen
  artifact can only be used successfully within a small time window.

This works well enough, and is consistent with a simple strict
interpretation of the use of the validity period conditions: if the moment
at which the assertion is being checked by the SP, as part of its
execution of some app/profile, is in the assertion's validity period, then
the assertion is valid (with respect to those conditions), otherwise not.

However, we have use cases for extending the SSO profile to do things with
the SSO assertion beyond its current use for signon at the SP.  These have
not been turned into specification text yet, but our interest in
supporting these cases is already affecting design, in particular the
interest in signing the assertion so it can be handed on to other parties
(and hence not also signing the Response).  So I think we also have an
interest in making sure that time constraints expressed in assertions are
consistent with this multi-tier use, even if the complete details of that
use aren't specified as part of 2.0.  It may be that to make really sure
of this we'll have to fully specify at least a simple multi-tier case.

So, is there a problem?  If the validity period conditions are to have
their straightforward function as an overall limit on the life of the
assertion as a processable thing, then yes, setting this time short to
deal with SSO threats pretty much eliminates its use for multi-tier
cases.  You can make an argument, and I guess Liberty does this, that a
profile is free to say:  well, in my profile we ignore the validity period
and process the assertion anyway (eg, in the case where an issuer is
processing its own assertion).  This seems to be, uh, questionable design
practice at best.  And in any case this limits multi-tier scenarios to
ones where original issuers are reprocessing out-of-date assertions.

I think it would be far better to look at the needs of SSO as being a case
of an app/profile needing an app-specific validity period distinct from
the general-purpose validity period.  Scott suggested this in his
BindingCondition proposal.  I don't know if I buy that construct, but I
think if we don't separate SSO-validity from overall assertion validity
(and from session lifetime) thta multi-tier will be much harder than it
should be.

 - RL "Bob"



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