18

We are using ADFS as an IDP and our application acts as SP. Below is a sample Auth response

<?xml version="1.0" encoding="UTF-8"?>
<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" ID="_82062d3d-897f-473e-90ad-0bb351d63b22" IssueInstant="2015-04-29T20:39:17.240Z" Version="2.0">
   <Issuer>http://adfs/services/trust</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="#_82062d3d-897f-473e-90ad-0bb351d63b22">
            <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 />
         </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue />
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
         <ds:X509Data>
            <ds:X509Certificate>certificate..... </ds:X509Certificate>
         </ds:X509Data>
      </KeyInfo>
   </ds:Signature>
   <Subject>
      <NameID>username</NameID>
      <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
         <SubjectConfirmationData InResponseTo="923ki0eg8h7g7y2243fi9jbdd1977j9" NotOnOrAfter="2015-04-29T20:44:17.240Z" Recipient="https://localhost/saml/SSO" />
      </SubjectConfirmation>
   </Subject>
   <Conditions NotBefore="2015-04-29T20:39:17.240Z" NotOnOrAfter="2015-04-29T21:39:17.240Z">
      <AudienceRestriction>
         <Audience>https://localhost/saml/metadata</Audience>
      </AudienceRestriction>
   </Conditions>
   <AuthnStatement AuthnInstant="2015-04-29T20:39:17.162Z" SessionIndex="_92062g3d-897f-473e-90ad-0aa351d63b22">
      <AuthnContext>
         <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>
      </AuthnContext>
   </AuthnStatement>
</Assertion>

The problem I face can be categorized into two scenarios:

  1. After 1 hour of Idle time, I logout the user locally. The server session expiry is a default value of 30min. I have my code to send heartbeat pings every 10min, if the user is actively working on something. Now, the problem is that when the user tries to login after the session expiry of 1 hour, I get the below exception

    Caused by: org.springframework.security.authentication.CredentialsExpiredException: Authentication statement is too old to be used with value 2015-05-28T17:41:52.648Z
        at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAuthenticationStatement(WebSSOProfileConsumerImpl.java:538)
        at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAssertion(WebSSOProfileConsumerImpl.java:306)
        at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.processAuthenticationResponse(WebSSOProfileConsumerImpl.java:214)
        ... 77 more
    

The question here is.. Why would our application try to validate the instance of when the token was issued? It could be granted anytime..

  1. I keep getting SAMLException with message "Local entity is not the intended audience of the assertion in at least one AudienceRestriction". The trace is as below

    Caused by: org.opensaml.common.SAMLException: Local entity is not the intended audience of the assertion in at least one AudienceRestriction
        at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAudience(WebSSOProfileConsumerImpl.java:506)
        at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAssertionConditions(WebSSOProfileConsumerImpl.java:458)
        at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.verifyAssertion(WebSSOProfileConsumerImpl.java:303)
        at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.processAuthenticationResponse(WebSSOProfileConsumerImpl.java:214)
        ... 77 more
    

I dont understand why this exception occurs.

Please help me to understand the concept.

Thanks!

rogue lad
  • 2,060
  • 2
  • 26
  • 32
rakpan
  • 2,453
  • 3
  • 20
  • 34

2 Answers2

35

Your IDP is re-using information that user has authenticated earlier (at time identified by Authentication Instant) and Spring SAML is by default configured to not let user login if she's been authenticated more than 7200 seconds ago.

It's a security measure - if it's a long time ago since the computer has authenticated the user, it's hard to guarantee that it's still the same person operating the computer. Spring SAML provides you some means to configure what level of security will be acceptable - for example by making this configurable.

You can increase this value by setting property maxAuthenticationAge on the WebSSOProfileConsumerImpl bean.

The audience error should happen only when the assertion contains Audience elements and none of them matches the entity ID of your application. I don't think the Response in your question is the one triggering this error?

Vladimír Schäfer
  • 14,559
  • 2
  • 45
  • 65
  • Thank you for the reply.. I think I got the concept now.. Regarding the audience error, they key as per your explanation seems to be "Entity Id".. I would investigate more.. and yes, the response posted above didnt trigger an audience error.. sorry if that was confusin.. – rakpan May 31 '15 at 03:05
  • Just for clarification. Is there any way to force the IdP to reissue the token - as in require the user to login again and reset this?. As far as I can tell there is no way to disable this check. Only increase it to something very high and hope the IdP will decide it is time for a re-login before we reach this problem. – Kristoffer Feb 18 '16 at 12:36
  • 10
    Yes, you can set forceAuthN flag to true in WebSSOProfileOptions. – Vladimír Schäfer Feb 18 '16 at 13:03
  • Ah yes. I actually just found that one myself too. So now I just need a way to retry with this flag so we don't force users to do it each time. – Kristoffer Feb 18 '16 at 13:22
  • 1
    As I understand it the answer is either: 1)to align, the maxAuthenticationAge to the lifetime of the ADFS or 2) set forceAuthN to true, right? – revau.lt Jul 11 '16 at 14:46
  • actually i tried this option earlier and it worked perfectly but now it doesn't work. User is now forced to login everytime when i set forceAuthN=true. i am just wondering what could go wrong all of a sudden. any help? – shirjai May 16 '17 at 09:53
2

Just an FYI on this topic, Google has confirmed that currently do not honour the forceAuthN flag for SAML redirects. Seeing issues with authentication timeout on SAML token as a result. Documented here: Google Apps SSO as IdP into Spring SAML2 - Authentication token timeout

Community
  • 1
  • 1
Ed Newman
  • 21
  • 3