Introduced just over 10 years ago by Forrester, Zero Trust is a security philosophy that starts from the premise that the cyber threat is omnipresent, both outside and inside the IS, and consequently proposes an access management strategy based on the three basic principles: explicit verification, minimising privileges, and constant monitoring.

 

Figure 1 : The three fundamental principles of the Zero Trust model

 

Despise these principles being well-known now, their practical implementation still represents a challenge for many organisations.

Currently, there is not and will not be a specific product that can be used to implement a Zero Trust model, instead, there are many distinctive implementation architectures. For user access, Zero Trust can be applied using two main architectural models (which are not in conflict and can be complementary):

• A model using a cut-off infrastructure element, e.g., a Secure Access Service Edge (SASE) approach. It dynamically controls network access to IS resources (where the user’s identity and posture are being used to make the decision).
• An approach where only identity is used to make the cut: access to IS resources is conditional, requiring proof of authentication and authorisation. In this approach, access control is carried out by an identity provider (identity manager or IdP) and by the targeted resources themselves.

The second type of architecture will be the topic of this article. We will focus on the implementation process which uses Azure Active Directory (AAD) as the Identity Provider.

Before understanding how the Identity Provider can be used to implement Zero Trust, here is a small description of the theory on the token-based access management mechanism.

 

AAD-based access management: a token story

 

AAD-based access management follows the principles of the access scheme involving an Identity Provider, i.e. a service to which the target resource delegates the management of the life cycle of user identities and their authentication.

In this scheme, a user’s access to a resource requires the presentation of a valid pass, issued by the Identity Provider after the user’s authentication process and (potentially) verification of his entitlement to access the target resource. These passes are called tokens and are cryptographically signed to protect against the use of fake tokens.

What is a token? A token is a string of characters containing various information called clauses, transmitted, for example, by HTTP (HyperText Transfer Protocol) requests.

AAD, as an identity provider, can issue three types of tokens, known as Security Tokens:

 

ID Token: Evidence of user authentication. It contains information about the user’s identity and the authentication context. It is not associated with any specific resource nor involved in access control.

Access Token: A pass authorising access to a particular resource. It may contain attributes or claims that allows the targeted resource to refine access control, such as the permissions delegated to the client application (scopes) on the resource. However, in case of Azure AD (a self-supporting token (*) (JWT)): it cannot be revoked after it has been issued. Its lifetime has an average of one hour. In other words, an Access Token remains valid until its lifetime ends.
^(*)Another implementation of OAuth could have been with opaque tokens which requires querying the Authorization server in order to find the details. This type of implementation would allow for easier revocation. This is not the choice made by Microsoft.

Refresh Token: is provided at the same time as the Access Token; it allows obtaining a new Access Token/Refresh Token pair after the expiration of the previous Access Token, without explicit user re-authentication. It also allows to retrieve Access Tokens for other resources without explicit user authentication. In the context of Azure AD, its lifetime is 90 days or 24 hours for Single Page Applications, and unlike Access Token, it can be revoked before its expiration.

 

It should be noted that Microsoft has defined a fourth type of token, the Primary Refresh Token, which allows single sign-in between applications on a given device. This token will not be mentioned in the rest of the document for the sake of simplicity.

Now we need to understand how these different tokens circulate from actor to actor!

 

Initial access to the target resource

 

At the time of the initial access, we assume that there are no valid tokens: no Access Tokens for the target resource nor Refresh Tokens. When the user wants to access the target resource, he will be redirected to AAD to be authenticated (and eventually authorised).

 

Figure 2: Dynamic process of obtaining an Access Token/Refresh Token pair during the initial access to the resource

 

The resulting Access Token will be included in each request to the target resource. The target resource will process them as long as the access token has not expired.

 

Renewal of access rights to the resource

 

After the expiration of the initial Access Token, the Refresh Token will be used to silently retrieve, without user intervention, a new Access Token/Refresh Token pair.

 

Figure 3: Access session dynamic maintenance via the renewal of the Access Token/Refresh Token pair

 

In an access management model, which involves an Identity Provider such as AAD, it can be noticed that the tokens are the keys to the castle and the Identity Provider is the gatekeeper. Let’s now look at how well this access management model implements the principles of Zero Trust for applications that rely on AAD to manage their login sessions.

 

Tokens: vulnerable vehicles of implicit trust

 

Looking at how Azure AD-based access management works, we see that:

• Access to any resource delegating access management requires proof of authentication and authorisation, through the presentation of a valid Access Token, regardless of the network origin of the access.
• An Access Token only gives access to one resource. Access to a different resource requires a dedicated Access Token from the Identity Provide.
• The Refresh Token allows to obtain Access Tokens for all resources to which the user is authorised

The application of Zero Trust principles is partial and perfectible at this stage:

• By default, the delivery of the Access Token is done against a basic authentication (login and password)
• The validity of the Access Token is decorrelated from the context. It can be used during its validity period, independent of the potential compromised signals that could have been detected
• The Access Token can be renewed without verification, if the authentication context did not changed

 

Conditional Access (CA) reinforces the conditions for issuing tokens and securing of the sessions

Conditional Access (CA) is an AAD function requiring an AAD Premium P1 or M365 Business Premium licence that allows context to be considered in access management.

Thanks to CA, it is possible to integrate a set of signals related to the user’s identity, the terminal used, the target resource, the access context and/or the risk level into the access authorisation decision.

The CA also allows non-binary authorisation decisions to be applied. Thus, an access carried out in a certain context can be authorised under specific conditions, which aim to compensate and reduce the level of risk associated with the access context. 

 

Figure 4: The principal of Conditional Access

 

The distribution of an Access Token can be conditioned by implementing a two-factor authentication, which helps to protect against unauthorised access (as a result of stolen credentials).

In addition, the CA offers other mechanisms for conditioning the use of tokens. Here we will focus on two mechanisms in particular: Sign-In Frequency (SIF) and Continuous Access Evaluation (CAE).

 

The Sign-In Frequency: influences the frequency of explicit user authentication

The Sign-In Frequency is used to define a maximum duration during which the user must re-authenticate after having been initially authorised access to the target resource.

Beyond the given timeframe, the Refresh Token cannot be anymore used to implicitly renew the Access Token/Refresh Token pair.

The SIF is thus a means of limiting the implicit trust given to Refresh Tokens over time.

The operation of the mechanism is illustrated below, for a SIF set at 90 minutes.

 

 

Figure 5: Illustration of the operation of the Sign-in Frequency

 

Note that the SIF has no effect on the validity of Access Tokens already issued. An Access Token that has not yet expired can still be used to access the associated resource, even after the maximum duration defined by the SIF has expired. The SIF only intervenes to prevent an implicit renewal of Access Tokens already issued or the implicit obtaining of new Access Tokens. In order to act on the Access Tokens already issued, it is necessary to turn to the Continuous Access Evaluation (CAE).

 

Continuous Access Evaluation (CAE) represents the way of linking the validity of Access Tokens to the context

CAE is a CA feature, available since January 2022, that allows context to be considered throughout the access session and not only at the time of the initial authorisation, so that it can force a renewal of the Access Token already issued in response to certain signals, including signals that suggests a compromise.

 

Figure 6: Types of signals that can force the renewal of the Access Token

 

CAE requires a communication link between AAD and the target resource to notify the latter of signals requiring re-authentication and to retrieve the conditional access policies defined for it. When the target resource receives an access request, it checks if it has not previously received a notification about the concerned user and whether the access context is different from the one allowed by the conditional access policies or not. If so, it rejects the access request and sends the user back to AAD with a request (challenge) for explicit re-authentication and a re-evaluation of the applicable access policies.

It should be noted that CAE is not a transparent mechanism for the target resources and its implementation requires changes in their operating logic. The implementation of CAE requires a CAE-capable client application capable of interpreting the request (challenge) returned by the target resource while redirecting the user to AAD. Microsoft has started to implement AAD for its M365 collaboration suite applications.

 

Summary

Nowadays, it is possible to implement a Zero Trust access philosophy based on identity, however, to avoid falling into the shortcomings of historical security models, the conditions for issuing and using these tokens must be tightened up, otherwise they will become carriers of implicit and excessive trust.

The use of mechanisms allows us to integrate signals that authorises the evaluation of context and allows a continuous control on the issued tokens when necessary.

However, it must be kept in mind that, in the face of a token theft scenario, these mechanisms play a reactive role depending on detection capabilities, and not a preventive role capable of preventing the use of stolen tokens. We will have the opportunity return with more details in a future article, discussing the problems of a token theft and the various existing and emerging solutions for dealing with them.