> ## Documentation Index > Fetch the complete documentation index at: https://docs.ainomos.ch/llms.txt > Use this file to discover all available pages before exploring further. # Identity & SSO > Connect your company's identity provider so people sign in with their company accounts, and map its groups to roles in Ainomos. 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**. | Option | What Ainomos asks for | | - | - | | **Microsoft Entra ID** | **Directory (tenant) ID** and **Application (client) ID**. Above roughly 200 groups Entra stops sending groups, so use app roles in large directories. | | **Okta** | **Org domain**, **Authorization server** (usually default) and **Client ID**. Roles and groups both come from Okta's groups claim. | | **Keycloak** | **Keycloak base URL**, **Realm** and **Client ID**, for a provider you run yourself. Client authentication must stay off. | | **Auth0** | **Tenant domain**, **Client ID** and **Claim namespace**. Roles and groups arrive only if an Auth0 Action writes them under that namespace. | | **Google Workspace** | **Client ID** only. Google sends no roles or groups, so you grant roles under **Users**. | | **Other OIDC provider** | A **Discovery URL or issuer**. **Apply values** reads the rest from it. Then enter the **Web client ID**. | **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**. > [!TIP] > > 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: | Field | What it does | | - | - | | **Scopes** | What Ainomos asks for at sign-in. The default is openid, profile and email. The openid scope is required. | | **Extra sign-in parameters** | Up to ten name=value lines added to the sign-in address, for example prompt=select\_account or domain\_hint=acme.com. | | **Subject (user\_ref)** | The claim that identifies a person. It decides who keeps which rooms, see below. | | **Email**, **Roles**, **Groups** | The claims that carry each value. Without a groups claim, no group mapping works. | | **MCP audience** | What Ainomos expects in the tokens of apps and agents that connect through MCP, the open standard AI apps use to connect to Ainomos. | ## 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**. | Field | What it does | | - | - | | **Identity provider** | The provider the value comes from. A value from another provider never matches. | | **Exact claim value** | The group or role value, exactly as your provider sends it. Case matters. | | **Target type** | **Room role**: **Member** of one room. **Platform role**: **Platform admin**, **Auditor** or **Maintainer**. **Functional cross-room role**: **Architecture**, **Security** or **Business**, each reading one decision type in every room. **Responsibility**: **Owner**, **Decider** for one **Decision type**, or **Curator** of the **Whole room** or one **Memory**. | | **Room** | The room, for room roles and responsibilities. | | **Authoritative reconciliation** | On: a person who no longer has the value at their next sign-in loses the role. Off, shown as **additive**: the last confirmed grant stays. | 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](https://docs.ainomos.ch/get-started/signing-in.md). ## 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. ## Related * [Signing in](https://docs.ainomos.ch/get-started/signing-in.md) * [Users](https://docs.ainomos.ch/admin/users.md) * [Roles and responsibilities](https://docs.ainomos.ch/admin/roles.md) * [Audit log](https://docs.ainomos.ch/privacy/audit-log.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.