Enterprise SSO in AAA Sentinel: a practical guide with Auth0 (and what changes with Microsoft Entra ID or Okta)

AAA Sentinel sees sensitive data: your cloud bills, the connected accounts, AI model spend and your security posture. As the team grows, managing access with standalone passwords stops scaling: someone leaves the company and their access lives on, someone else needs admin rights for a week and nobody remembers to remove them. Enterprise SSO solves this by connecting AAA Sentinel to the directory your company already uses.

Why use enterprise SSO

With SSO enabled, your identity provider (IdP) becomes the only way in:

• Offboarding in one place: disable the person in your directory and they can no longer sign in to AAA Sentinel, without touching the platform.
• Synced roles: each IdP group maps to a role (Administrator, Approver, Finance or Viewer) and the role is recalculated on every sign-in.
• Your company policies apply here too: MFA, conditional access and session length are decided by your IdP.
• Verified domain: only people with an email on a domain you have proven you control through a DNS record can sign in with SSO.
• Fewer passwords and less support: nobody has to remember another password or ask for a reset.

How to set it up in AAA Sentinel

SSO is available on the Business plan and is configured by the organization owner under Management → Settings, in the "Enterprise SSO" card. There are five steps:

• Choose the protocol, SAML or OIDC. It is locked once saved; to change it you have to delete the configuration.
• Copy into your IdP the values shown in the panel: for SAML, the reply URL (ACS), the entity ID and the logout URL; for OIDC, the redirect URL.
• Fill in the IdP details (the metadata URL for SAML; issuer, client ID and secret for OIDC), the email claim, the groups claim and the group → role table.
• Verify your domain by publishing the TXT record the panel gives you. It has to match exactly.
• Click "Test connection": it opens your IdP login in another tab and confirms everything responds, without changing your session. Once everything is green, enable SSO.

SAML or OIDC: which to choose

Both protocols work. The difference is in the details:

• SAML: sign-out is complete (leaving AAA Sentinel also ends the IdP session) and groups travel as a multi-valued attribute. It is the recommended option if you want to sync roles with Microsoft Entra ID or Okta.
• OIDC: it takes fewer values to configure (issuer, client ID and secret). AAA Sentinel also ends the IdP session as long as the IdP publishes an end_session_endpoint and accepts the client ID to end it.
• Either way, turning SSO off suspends the people who sign in through it, because they have no password, and they stop counting as a seat. They come back when you turn it on again, as long as they still fit in the plan.

Use case: Auth0 as the identity provider

We tested the full integration with a free Auth0 tenant, first with SAML and then with OIDC. What both have in common is done once: an Action that publishes each person's roles (Actions → Library → Build Custom, with the Login / Post Login trigger) and the application settings. The same Action works for both protocols:

// Actions → Library → Build Custom → Login / Post Login
exports.onExecutePostLogin = async (event, api) => {
  const roles = event.authorization?.roles ?? []
  const joined = roles.join(',')

  // OIDC: namespaced claim in both the ID token and the access token (AAA Sentinel reads it from userinfo)
  api.idToken.setCustomClaim('https://aaa-sentinel.com/groups', joined)
  api.accessToken.setCustomClaim('https://aaa-sentinel.com/groups', joined)

  // SAML: multi-valued "groups" attribute
  if (api.samlResponse) api.samlResponse.setAttribute('groups', roles)
}

• Use Auth0 Roles (User Management → Roles) as groups: create one for each role you want to map and assign it to each person. The Role name is exactly what you will type later in the panel mapping.
• Allowed Callback URLs and Allowed Logout URLs accept several comma-separated URLs: with the ones in the table you are covered for both SAML and OIDC. Click Save Changes at the bottom of the page.

Auth0 with SAML

In the application's Addons tab, enable SAML2 Web App. In its Settings tab, Application Callback URL is the panel's reply URL and the Settings field takes this JSON, including the logout block for single logout:

{
  "audience": "<entity ID shown in the panel>",
  "recipient": "https://auth.aaa-sentinel.com/saml2/idpresponse",
  "destination": "https://auth.aaa-sentinel.com/saml2/idpresponse",
  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
  "nameIdentifierProbes": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
  ],
  "logout": {
    "callback": "https://auth.aaa-sentinel.com/saml2/logout",
    "slo_enabled": true
  }
}

• The metadata URL is in the addon's Usage tab, under Identity Provider Metadata: copy it with right-click → "copy link address". A normal click downloads the XML, and the panel needs the URL.

Auth0 with OIDC

With OIDC no addon is needed: the application and the Action above are enough. These are the values for the AAA Sentinel panel:

• The issuer keeps the trailing slash: it is exactly the value Auth0 publishes as its issuer.
• The secret cannot be read back: type it again every time you save the configuration.
• AAA Sentinel reads groups from the userinfo endpoint, not only from the ID token. That is why the Action publishes a namespaced claim, also in the access token, with the roles joined by commas.
• Signing out of AAA Sentinel also ends the Auth0 session through its end_session_endpoint. For that, https://app.aaa-sentinel.com/login must be in Allowed Logout URLs, as in the application table.

The mistakes that cost us the most time

None of them is a platform bug, but from the outside they all look alike: "I get in, but not with the right role". This is the list to check:

• Group names that do not match: mapping is case- and plural-sensitive. A role called finops-admin does not match finops-admins, and the person gets the default role.
• The Action deployed but outside the flow: Auth0 sends no groups and everyone gets the default role.
• An email outside the verified domain: SSO is not offered for it. Test users need an email on the domain, even without a mailbox.
• IdP sessions that stay open: if switching users signs you straight in without asking for a password, check that the logout URL is allowed in the IdP.

What about Microsoft Entra ID or Okta?

The steps in AAA Sentinel are the same with any provider; what changes is the configuration on the IdP side. What we did in Auth0 (the Action and the namespaced claim) is specific to Auth0. These are the points to watch with the other two:

• Microsoft Entra ID: by default it sends groups as Object IDs (a GUID), not names, so the group → role mapping is filled in with those identifiers unless you configure the claim to send names. Users without a mailbox have an empty email: map the email to the UPN. The .onmicrosoft.com domain cannot be verified; you need your own domain. And Entra does not return groups in userinfo, so use SAML to sync roles.
• Okta: the groups claim is defined on the authorization server and must be included for any scope, because AAA Sentinel only requests openid and email. Its OIDC logout requires a token the platform does not keep, so with OIDC the Okta session stays open after signing out; with SAML sign-out is complete.
• With any provider: use "Test connection" before enabling it and sign in with one user from each group to validate the roles.

Checklist before enabling

With all of this in place, the day someone leaves the company you only need to disable them in the directory so they can no longer sign in. If you also want to end a session they have open, remove them from Users.

• Business plan and access as the organization owner.
• Your own domain and access to its DNS to publish the TXT record.
• The IdP groups created, with the exact names you are going to map.
• The reply URL and the logout URL registered in the IdP.
• The connection test green and three test users validated.