Enhancing Security with AWS Verified Access and Microsoft Entra ID Integration

Introduction

Unlike traditional VPN-based approaches, AWS Verified Access evaluates multiple dimensions of access, including user identity, device posture, and application-specific policies. This means organizations can ensure that only fully authenticated and authorized users can access sensitive resources, regardless of their physical network location. The result is a more flexible, secure, and manageable approach to enterprise access control.

With this latest enhancement, AWS Verified Access now allows organizations to use claims directly in the ID token, in addition to retrieving claims from the identity provider’s Userinfo endpoint. Some identity providers like Microsoft Entra ID emit user claims directly in the ID token, while others emit user claims from the Userinfo endpoint. AWS Verified Access now supports both approaches. Refer to Figure 1 for a visual reference of the OpenID Connect flow and where the ID token and Userinfo endpoint fit in the flow.

In this blog post, you’ll discover how to create access policies that inspect ID token claims from identity providers like Microsoft Entra ID.

Figure 1: OpenID Connect authorization code flow (Click image to open larger version in new tab)

Understanding ID Token Claims

ID tokens are a core component of OpenID Connect, typically issued by identity providers during the OpenID Connect authentication flow. These tokens can contain rich metadata about the authenticated user, including custom claims that extend beyond standard profile information.

Code snippet 1 displays an ID token that was issued by Microsoft Entra ID. The token was requested using the openid scope and customized to include the user’s group memberships. In the ID token, the groups key contains a list of the user’s groups. Objects like groups and users are commonly referenced with globally unique identifiers to prevent unintended access.

{
   "aud": "79f1b917-ee9b-420b-87e1-3e92b06e4aef",
   "iss": "https://login.microsoftonline.com/b58516...",
   "iat": 1737664278,
   "nbf": 1737664278,
   "exp": 1737668178,
   "aio": "AWQAm/8ZAAAAIB2lmM5JT1AzZ6DDeq...",
   "cc": "CgEAEhdhdmFibG9nLm9ubWljcm9zb2Z0L...",
   "groups": [
      "221157e3-07c3-4eb0-b62f-bae3b0c3a19b"
   ],
   "nonce": "g4dsg5y4afi",
   "rh": "1.AWEBDhaFtXtFXEiiOMvStzAJJhe5...",
   "sub": "lUtmuMnHja-sWBffM-eFr17Ef4d4hvZQyldaGM1lHZU",
   "tid": "b585160e-457b-485c-a238-cbd2b7300926",
   "uti": "U8bFnkweQUauh5s-D6EVAA",
   "ver": "2.0"
}

Code snippet 1: Example ID token issued by Microsoft Entra ID that includes the user’s group memberships

Group-Based Access Control

A prime use case of this new capability is implementing access control based on the groups claim from the ID token. Many organizations manage user access through group memberships in their identity provider. With the new AWS Verified Access enhancement, you can now:

• Emit a user’s group memberships directly in the ID token.
• Control access to AWS Verified Access endpoints based on user group membership.

Consider a typical enterprise setup. Engineering team members in eng-group get access to development resources. Finance team members in fin-group get access to finance applications. Different AWS Verified Access endpoints can be configured to permit access based on these groups.

Policy Evaluation with ID Token Claims

AWS Verified Access uses a powerful policy language called Cedar that allows administrators to create fine-grained access controls based on an authorization context. Here’s an example of how this works in practice.

When a user attempts to access a protected resource, AWS Verified Access evaluates an authorization context that includes detailed information about the user from the Userinfo endpoint and the ID token.

When you create an identity trust provider, you provide a policy reference name to reference the claims received from that trust provider. For our example, we use my_policy_reference.

• Claims emitted through the Userinfo endpoint are stored directly within my_policy_reference.
• Claims emitted through the ID token are stored in a nested key called additional_user_context.

Both are shown as an example in code snippet 2.

{
   "my_policy_reference": {
     "additional_user_context": {
       "aio": "AWQAm/8ZAAAAIB2lmM5JT1AzZ6DDeq...",
       "aud": "79f1b917-ee9b-420b-87e1-3e92b06e4aef",
       "exp": 1737593337,
       "groups": [
         "221157e3-07c3-4eb0-b62f-bae3b0c3a19b"
       ],
       "iat": 1737589437,
       "iss": "https://login.microsoftonline.com/b5851...",
       "nbf": 1737589437,
       "rh": "1.AWEBDhaFtXtFXEiiOMvStzAJJhe5...",
       "sub": "lUtmuMnHja-sWBffM-eFr17Ef4d4hvZQyldaGM1lHZU",
       "tid": "b585160e-457b-485c-a238-cbd2b7300926",
       "uti": "Ui4NdOgNWU6XTX_UsU8IAA",
       "ver": "2.0"
     },
     "family_name": "Kitts",
     "given_name": "Ken",
     "name": "Ken Kitts",
     "picture": "https://graph.microsoft.com/v1.0/me/photo/xxx",
     "sub": "lUtmuMnHja-sWBffM-eFr17Ef4d4hvZQyldaGM1lHZU"
   }
 }

Code snippet 2: Example authorization context that includes the ID token

The authorization decision is made using a Cedar policy that inspects claims about a user from a user-identity trust provider, such as Microsoft Entra ID, as well as signals received from device-based trust providers. The example authorization policy in code snippet 3 demonstrates the use of ID token claims. The policy permits users who belong to a specific security group.

permit (principal, action, resource)
when
{
    // Inspect groups claim from ID token
    context.my_policy_reference
        .additional_user_context
        .groups
        .contains
        (
            // eng-group
            "221157e3-07c3-4eb0-b62f-bae3b0c3a19b"
        )
};

Code snippet 3: Example Cedar policy that inspects an ID token claim

By offering such granular policy definitions, AWS Verified Access provides organizations with powerful tools to implement sophisticated access management strategies.

Conclusion

AWS Verified Access now supports inspection of ID token claims during the authorization process. This improves interoperability with identity providers like Microsoft Entra ID that emit user claims directly in the ID token. Administrators can now leverage these claims to create precise, context-aware access policies across both HTTP and non-HTTP resources. To get started with these enhanced authorization capabilities, visit the AWS Verified Access tutorial.

About the authors