The problem here is that the Lifetime expiry returned by the STS does not
match the NotOnOrAfter Condition in the Assertion. So the Lifetime expiry
is "18:13:11" but the NotOnOrAfter expiry is "18:11:11". In my opinion the
fault lies with the STS, as the Lifetime of the token should match the
NotOnOrAfter Condition. In your case, as least make sure that the Lifetime
expiry is less than NotOnOrAfter.

The issue about using NotOnOrAfter instead of the Lifetime (if the latter
is not provided) does not arise here, as the Lifetime is provided. In any
case, the IssuedTokenInterceptorProvider in CXF is token-agnostic, and so I
don't want to introduce token-specific parsing here.

Colm.


On Thu, Apr 24, 2014 at 7:29 PM, jeffc <jeff_carbe...@bcbsil.com> wrote:

> Sorry looks like I posted the ws-trust request before and not the response.
>
> Here is the response.  I also unchecked that box on our STS and set its
> lifetime on the SAML token it returns to 7 minutes to match the
> NotOnOrAfter
> and it now has a lifetime element, but I am still getting the same error of
> token expired when I tried another request at 1:12pm.  Perhaps the lifetime
> is too close and should be less, so I am trying 4 minutes now.   But I am
> confused as I thought the expiry of a SAML token was directly related to
> the
> SAML condition of NotOnOrAfter.  I am no expert in the ws-trust and SAML
> spec, but if lifetime is not provided then shouldn't CXF isExpired method
> also check the NotOnOrAfter as well?
>
> RSTR:
>
> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope";>
> <soap:Body>
> <wst:RequestSecurityTokenResponse
> xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512";
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> ">
> <wst:RequestedSecurityToken>
> <saml2:Assertion ID="SamlAssertion-4b473c86a1e09239721027a1f3b3e07c"
> IssueInstant="2014-04-24T18:06:11.661Z" Version="2.0"
> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
> <saml2:Issuer>http://sts.dev.mycompany.com:8080/sts_ut</saml2:Issuer>
> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>
> <ds:SignedInfo>
> <ds:CanonicalizationMethod
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1
> "/>
> <ds:Reference URI="#SamlAssertion-4b473c86a1e09239721027a1f3b3e07c">
> <ds:Transforms>
> <ds:Transform
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
> </ds:Transforms>
> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
> <ds:DigestValue>eJCXNdhnR...</ds:DigestValue>
> </ds:Reference>
> </ds:SignedInfo>
> <ds:SignatureValue>MVTJysD4BbDjX...</ds:SignatureValue>
> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#";>
> <X509Data>
> <X509SubjectName>EMAILADDRESS=ecsld...@mycompany.com,CN=mystsserver.com
> ,OU=ITG,O=Some
> Company,L=Chicago,ST=Illinois,C=US</X509SubjectName>
> <X509Certificate>MIIHmDCCBoCg...</X509Certificate>
> </X509Data>
> </KeyInfo>
> </ds:Signature>
> <saml2:Subject>
> <saml2:NameID
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
> NameQualifier="">EAA0001</saml2:NameID>
> <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/>
> </saml2:Subject>
> <saml2:Conditions NotBefore="2014-04-24T18:04:11.661Z"
> NotOnOrAfter="2014-04-24T18:11:11.662Z"/>
> <saml2:AttributeStatement>
> <saml2:Attribute Name="cn"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
>
> <saml2:AttributeValue>cn=RFT,ou=SomeCompany,ou=Authorities,ou=SomeCompany,ou=SERVICES,o=INTLDAP</saml2:AttributeValue>
> </saml2:AttributeStatement>
> <saml2:AuthnStatement AuthnInstant="2014-04-24T18:06:11.661Z">
> <saml2:SubjectLocality Address="10.99.99.99"/>
> <saml2:AuthnContext>
>
> <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml2:AuthnContextClassRef>
> </saml2:AuthnContext>
> </saml2:AuthnStatement>
> </saml2:Assertion>
> </wst:RequestedSecurityToken>
> <wst:Lifetime>
> <wsu:Created>2014-04-24T18:06:11.702Z</wsu:Created>
> <wsu:Expires>2014-04-24T18:13:11.702Z</wsu:Expires>
> </wst:Lifetime>
> </wst:RequestSecurityTokenResponse>
> </soap:Body>
> </soap:Envelope>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Clarification-of-CXF-client-handling-of-expired-cached-tokens-tp5743216p5743262.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Reply via email to