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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

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


Subject: WS-Trust question re: token validity periods


Hi folks,

This question stems from an energetic debate I'm having with a colleague
about dealing with token validity periods, particularly when SAML tokens
are involved.  They have only been supporting SAML tokens to date and
have been strictly relying on the assertion validity period as defined
by the NotBefore/NotOnOrAfter conditions for validity period semantics
of the WSS SAML token.  They have not been including <wst:Lifetime>
elements in the RSTR.
	
I recently pointed out that they really should be using the
<wst:Lifetime> elements in RST/RSTR's to define the expiration semantics
of the tokens since:
a)	WS-Trust defines support for token expiration/renewal, etc, so
it should thus be processed at the WS-Trust layer, not a token-specific
layer
b)	The spec states that tokens should be treated as opaque... i.e.
an implementation should not have to parse down inside the token to do
it's WS-Trust processing
c)	When they support other token types in the future, those token
types may have no internal mechanism for expressing validity period
semantics.  

This then led to a point of disagreement.  

My colleague contends that since the <wst:Lifetime> element is optional
and not really a part of the actual token, it is more advisory in nature
and is just a convenience for WS-Trust processing. He maintained that if
it is present and the token is a SAML token, then the lifetime element
should ALWAYS represent the same validity period as expressed by the
embedded SAML assertion conditions.  

I argued that was absolutely NOT the case and that such relationships
are completely within the realm of some application profile of use.
Yes, a service provider that's handed a SAML token may also need to also
ensure that the SAML assertion is itself "valid", but I argue that this
is a separate issue from dealing with "token expiration" at the WS-Trust
level.

I also pointed out that while a particular application-specific profile
of WS-Trust/SAML MAY include some constraints that tie the two together,
neither the WS-Trust spec nor the SAML Token Profile specs do that.   I
argued that it is perfectly valid for an STS to have its own policies
regarding token lifetimes during issuance/renewal that can be completely
independent from the assertion lifetime policies of a SAML authority
from which the STS might obtain assertions to use in its SAML tokens.  

For example, I see no reason that a SAML authority couldn't generate
assertions with longer validity periods but an STS that uses that SAML
authority only gives out short-lived WSS tokens using that assertion.
If necessary, an STS client can use the WS-Trust renewal binding to
obtain a new token when the current one expires (where expiry is defined
by the <wst:Lifetime>). The renewed token returned in the RSTR can even
use the same long-lived assertion. The RSTR simply includes updated
expiration semantics defined by the <wst:Lifetime> element.  I tried to
argue that this is analogous to issuing short-lived tokens using an X509
certificate binary token.  My certificate can be very long-lived but I
probably don't want any WSS tokens issued with that cert to have an
expiration period matching the cert. 

My colleague isn't convinced and believes that the SAML assertion
expiration should always reflect the WSS security token lifetime. I
contend that he is allowed to define that in his application-specific
profile, but that is not the intent of either the WS-Trust or SAML Token
Profile spec.
	
I offered to query the TC for other opinions, so here it is :-).

Thanks,

Rob Philpott 
RSA, the Security Division of EMC
Senior Technologist | e-Mail: robert.philpott@rsa.com
<rphilpott@rsa.com>  | Office: (781) 515-7115 | Mobile: (617) 510-0893




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