Skip to main content
By default, people sign in to Ainomos with Ainomos accounts that an administrator invites. Under Identity & SSO you connect your own identity provider instead, such as Microsoft Entra ID, Okta or any other OpenID Connect provider. People then sign in with their company accounts, your directory decides who gets in, and its groups can grant roles in Ainomos. Who can do this: platform admins. A mapping that grants a responsibility in a room also needs you to be an owner of that room. Open Settings, then Identity & SSO. Active identity provider shows what people sign in with now: your provider marked active, or default (platform realm), which means Ainomos accounts.

Before you start

The person who runs your identity provider registers Ainomos there as a public client: authorisation-code sign-in with PKCE and no client secret. If you want to map groups to roles, the provider must also send group or role membership in the sign-in token. Ainomos shows the addresses to register. Everything you enter stays a draft until the last step, so nothing changes for anyone before then.

Connect your provider

1

Choose provider

Pick your provider under Which identity provider?. If it is not listed, choose Other OIDC provider.
2

Its values

Fill in the values. Where to click in your provider lists the steps in its console. Below the fields, Ainomos shows the issuer and claims it derived from your answers.The box This platform shows the Redirect URI (for your IdP client) and the Test-login redirect URI. Register both as allowed callbacks in your provider. Then choose Save draft and test.
3

Test

  • Test connection checks that Ainomos can read your provider’s published configuration and signing keys.
  • Test-login against the draft opens your provider in a pop-up. Sign in there for real. The result shows who you would be and whether you would be a platform admin.
Activation needs both to pass. Any change to the draft resets the test.
4

Permission mappings

Optional. Map your directory’s groups or roles to roles in Ainomos, as described below, or grant roles by hand under Users.
5

Activate

Read what activation does, tick I understand that platform sign-in accounts of admins are disabled., and choose Activate. The page confirms Identity provider activated.
If the test sign-in says you would not be a platform admin, give your account the role the message names in your provider, or map one of your groups to Platform admin in step 4. Then run the test sign-in again. If no roles arrive at all, your provider may send them only in the access token, and its administrator has to add them to the ID token.

Advanced settings

Under Advanced: scopes, MCP audience, claim paths in step 2:

Map groups to roles

Who can do this: platform admins. For a Responsibility mapping, you must also be an owner of that room. In step 4, choose Add mapping, fill in the form and choose Create mapping. A new mapping takes effect at each person’s next sign-in. Changing or deleting one removes the access it granted at once; deleting asks you to confirm with Delete and revoke. Roles granted by hand always win. The Grants column counts who holds access through each mapping, and in a room these memberships show as via SSO claim. Every change is recorded as evidence.

What activation changes

  • The sign-in page sends everyone to your provider. Anyone signed in through an earlier provider must sign in again.
  • The Ainomos accounts of your platform admins are disabled.
  • New people are added in your directory, not invited. They appear under Users after their first sign-in, and you give them rooms there.

Who keeps their rooms

Ainomos recognises a person by the Subject (user_ref) claim. When that claim is the email address, and your directory uses the same addresses as the Ainomos accounts, people keep their rooms. With another claim, such as the user ID Entra ID sends, a warning says how many room owners would lose their rooms. Plan for that before you activate. Your own rooms move with you. If your test sign-in proves a different identity from the one you are signed in with, step 5 shows Your rooms move to your new sign-in with your rooms and roles. Tick Move my rooms and roles to your new account, then activate. Only the person who did the test sign-in can activate. Afterwards, choose Sign in again with your company account. Past records keep the name they were made under.

Second factors

Identity & SSO has no second-factor setting. With your provider active, its own second-factor rules apply to everyone who signs in through it. People with Ainomos accounts manage their authenticator app under Sign-in security. See Signing in.

If your provider fails

A broken provider cannot lock you out. On your own infrastructure, the installation’s emergency administrator account needs no identity provider and keeps working. On Ainomos cloud, the Ainomos operator can switch your provider off, which turns your administrators’ Ainomos accounts back on.