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