Configurable token lifetimes for Azure Active Directory (AAD) have been available for while now, although the feature is still in public preview. This article provides details of how to create an access token lifetime policy and how to apply it to an application federated with AAD using SAML 2.0.
Before we get started with this, we need to ensure you have the correct (i.e. Preview) version of the AAD Powershell Module. The current link for this is:
https://www.powershellgallery.com/packages/AzureADPreview/2.0.0.17
Note that the module is subject to change, so search for the latest version.
The default Access Token Lifetime Policy that applies to SAML2 tokens is one hour as described in this article.
Ok, let’s go ahead and create a new Token Lifetime Policy. To do this we are going to use the New-AzureADPolicy cmdlet, as shown in the example below.
New-AzureADPolicy-Definition @(‘{“TokenLifetimePolicy”:{“Version”:1,”AccessTokenLifetime”:”12:00:00″}}’) -DisplayName“12HourTLP”-IsOrganizationDefault$false-Type“TokenLifetimePolicy”
In this example, I have set the token lifetime to 12 hours. Now this is just an example, you will need to consider the security implications of whatever policy you create. Here’s the output.
We will need to make a note of the Id (GUID value) of the new policy as we will need this later.
The next step if to identify the service principal associated with your SAML-enabled application. This uses the Get-AzureADServicePrincipal cmdlet, as follows:
Get-AzureADServicePrincipal-SearchString“My”
We can run the cmdlet without the searchstring parameter, but that tends to return a lot of results for us to pick our way through. Here’s what the output looks like. Again, we should make a note of the ObjectID value as we will need this later.
Now you check which policies currently apply to your service principal. We use the Get-AzureADServicePrincipalPolicy cmdlet to do this using the ObjectID of the service principal for our application.
Get-AzureADServicePrincipalPolicy-Id1911f64f-9d76-4ebf-9fcb-b3814e2e5e21
In this example, the output shows that a TokenIssuancePolicy is applied, but no TokenLifeTimePolicy – so we can assume that the default TokenLifeTimePolicy of 1 hour is in play.
Now we can go ahead and apply our newly created TokenLifeTimePolicy to the service principal representing our application. This uses the Add-AzureADServicePrincipalPolicy cmdlet. The “Id” parameter needs to the ObjectID of our service principal, while the “RefObjectId” parameter needs the GUID of the Token Lifetime Policy we created earlier. And, yes, it can be confusing!
Add-AzureADServicePrincipalPolicy-Id1911f64f-9d76-4ebf-9fcb-b3814e2e5e21-RefObjectId74f4296d-fcdb-4c72-b434-b1628adef47b
Note that, if successful, this cmdlet returns no output.
We can now re-run the cmdlet to check which policies have been applied to our service principal.
As you can see, our 12HourTLP policy is now applied.
This is all very well, but how can we determine whether the policy is actually in effect or not? One option is to sign-in to the application and wait for 12 hours to roll over. If you have luxury of time for this then you clearly aren’t as busy as I am! A better option is to examine the SAML Response XML using a SAML inspection tool such as the SAML Chrome Panel extension for the Chrome browser. Once you have the Response XML, look at the Conditions node and confirm that the NotBefore and NotOnOrAfter values show a 12 hour difference – see example below.
That’s it really. In this article you have hopefully learned how to create a new Access Token Lifetime Policy as well as how to apply it to an existing SAML 2.0 application that is leveraging AAD as the Identity Provider (IdP).
Until next time!
Tony
Being able to extend the token lifetime will help reduce administration, but possibly at the cost of security.
Many thanks for your guide! 🙂