Azure Active Directory, SAML Application, and persistent timeouts.

Leave a reply

For the last several days I’ve been working with a customer that had a third party SAML application published in Azure Active Directory. They were engaging us to look at what appeared to be an odd behavior in the sign on / authentication experience of the user.

In this particular scenario the application was browser based and being accessed through the third party site. The third party site was configured for SAML based authentication to Azure. During the session the user would utilize the applications sign out functionality. The expectation at this time was that the user would be able to reopen the connection to the third party application and not be redirected for authentication. In testing this appeared to be true – a user was not prompted for credentials again in the first day. If the user came back after 72 hours they were re-prompted for credentials.

Our original working assumption was that the reason for the authentication was how the token lifetime was being interpreted. Using fiddler we observed the following scenario:

  • User accesses an internal company portal and selects the application.
  • The user is redirected to the third party applications website and selects to sign on.
  • The sign on request is redirected to Azure via login.microsoftonline.com.
  • The request does not come with an existing authentication cookie. The request is redirected to the federation endpoint on-premises.
  • The user authenticates to the forms based authentication endpoint in the federated on-premises solution.
  • The token is returned to login.microsoftonline.com.
  • The authentication session is returned to the third party.

 

We can see in the federation return that the persistent authentication cookies were set. Here is a sample cookie from fiddler.

 

Set-Cookie: ESTSAUTHPERSISTENT=0.ASkARErL9Yw2dU2I89hHRJ_-smKmQ_mBm_pHo39NBcMffS8pABo.AgABAAQAAAD–DLA3VO7QrddgJg7WevrAgDs_wQA9P_SAKceI10neWuC-T3WHd5fGMRQVB9AyIBljUtpDvE14VkEpbtaaiI0m3HGAtAyeBD9aMwnK6QPi3ZVWoKrQQyuxbxxi4bJLAgaXlvn5PXZmtkE349poyoDJww5kkRVlHRvzcj57or9hSCo5XRafA8kSRZGKjR9sK4qzOCattU2WVUEsFfR836mQtE6ngGog_FFtVh6lv2q-7mCo0EvRINEAL5bjgLHVNYwLAoQEhV25DuYLC8pUdt3CbjUkPpoEqSVwYp-a43hR0ka_B68pNy82eDLVcqbguaPOsSDX9lGHbgO2HlEi0alDiULSQ68N–zuVEKzTlI4wGyPdS-YQR1DwTgmrNRlshyGcG5uNVnibvxscLAQA9qwNOcOXBHLFNV3EUeIQqBLj0CThVIKEJ4-Kc2waT1rRV3f3Z_OxalNM4A7RAx_XZc0no7hTqReWbdBmSGLXXa2m7d3c9wrd_7toV3Iv0uOtU0n86zkqw; domain=.login.microsoftonline.com; expires=Sun, 22-Aug-2021 14:14:07 GMT; path=/; secure; HttpOnly; SameSite=None

 

The date highlighted in red was 90 days from the date of the request. This leads us to reasonably believe that the federated solution is returning a token for the full expected validity period.

 

The next step was looking at any legacy token issuance policies. In this case the Azure tenant had no custom token issuance policies so there would be no intentional override of the token lifetimes.

 

Following the review of token issuance policies we dug deeper into the sign on logs. A review of the individual sign on showed nothing out of the ordinary. There were no conditional access policies that would have impacted token lifetime.

 

At this point it remained a mystery as to why the users were re-prompted for authentication. Remember – the symptoms we were investigation were users were only re-prompted for authentication after 72 hours.

 

Collecting further information our engineering teams were engaged to review the sign on logs. This is when the scenario unfolded further. Our engineering team returned with an answer this was by design. The azure session associated with the authentication expired after 24 hours of inactivity. I thought the timeout only occurred at 72 hours? With further work we discovered that after the initial logon the second test of access was being performed within 24 hours. In this case the tenant was configured to not display the keep me signed in dialog on sign on. The keep me signed in dialog is a decision offered to the user that sets a persistence value for the session (not the authentication token). When persistence is disabled – the session is configured with a rolling 24 hour expiration. In this case the test was performed within the 24 hours – which reset the last session access time and added 24 more hours. Testing was discontinued and we returned greater than 24 hours after the test at which time the user was re-prompted for authentication. To review the scenario:

 

  • User accesses an internal company portal and selects the application.
  • The user is redirected to the third party applications website and selects to sign on.
  • The sign on request is redirected to Azure via login.microsoftonline.com.
  • The request does not come with an existing authentication cookie. The request is redirected to the federation endpoint on-premises.
  • The user authenticates to the forms based authentication endpoint in the federated on-premises solution.
  • The token is returned to login.microsoftonline.com.
  • The authentication session is returned to the third party.
  • Within 24 hours the user repeats the test.
  • User accesses an internal company portal and selects the application.
  • The user is redirected to the third party applications website and selects to sign on.
  • The sign on request is redirected to Azure via login.microsoftonline.com.
  • A valid authentication token exists and the session is valid.
  • The user is not re-prompted for credentials.
  • User access an internal company portal and selects the application two days later.
  • The user is redirected to the third party applications website and selects to sign on.
  • The sign on request is redirected to Azure via login.microsoftonline.com.
  • The request comes with an existing authentication token – the associated session in Azure is now invalid. The request is redirected to the federation endpoint on-premises.
  • The user authenticates to the forms based authentication endpoint in the federated on-premises solution.
  • The token is returned to login.microsoftonline.com.
  • The authentication session is returned to the third party.

 

In the end the desire is that the user not be re-prompted and to understand the authentication flow in play here. If you desired to control this – how would this be controlled.

 

The first step would be to create a conditional access policy that applies to this application and includes any scoping filters desired. In this policy you can override the persistence flag and set the connection to be persisted. This eliminates the 24 hour session timeout and places the session on a rolling 90 day expiration. This coincides with the default token time issued – and would result in the user being prompted after 90 days. If you wanted to control this even further – you would also add sign on frequency and specify a number of days or hours. The sign on frequency would override the 90 day rolling session – by invaliding authentication at the designated time. This would force the user to re-authenticate. The authentication experience would differ in overall experience depending on the single sign on state of the federation configuration.

 

For more information see:

Leave a comment