Taking roles and permissions for AI from your identity management

Why should the AI not have its own accounts?

Every application that maintains its own accounts is one more place where leavers get forgotten. For an AI platform with access to documents, emails and specialist systems, that would be a risk. In the IT-Grundschutz module ORP.4, the BSI (Germany’s Federal Office for Information Security) requires identities and permissions to be granted, changed and withdrawn in a controlled way. This works best if the AI is not a separate source of identities but uses your existing identity management.

Which standards are there for connecting it?

Standard	What for	Typical with
LDAP	querying a directory: people, groups, attributes	Active Directory, OpenLDAP
OpenID Connect (OIDC)	signing in through a central identity provider, based on OAuth 2.0	Entra ID, Keycloak, many cloud services
SAML 2.0	signing in through a central identity provider, XML-based	older identity providers, public administration portals
SCIM	creating and removing accounts and groups automatically	cloud directories

With OIDC and SAML, the application never sees the password: it redirects to the identity provider for sign-in and receives a signed confirmation in return, often with the person’s groups. A second factor can be enforced centrally there.

How do groups become permissions in the AI?

Identity management says who someone is and which groups they belong to. What a group may do in the AI is set by the AI platform. Proven practice:

• Few roles: people who use the AI, and administrators who set it up. Every additional role has to be maintained and reviewed.
• Sharing with groups: apps, knowledge collections and models are shared with groups, not with individual names. If someone changes department, their shares change with them.
• Permissions in specialist systems stay there: what someone may see in SharePoint, in the ticket system or in the ERP is still decided by that system. The AI reads with the person’s own access. Permissions for AI with documents →
• No new profiles: the AI does not build its own attributes about people beyond what is in the directory. This also makes discussions with the works council or staff council easier.

What applies when people join, move and leave?

1. Joining: with the account in the directory, the person can sign in; shares follow from their groups.
2. Moving: new department, new groups, new shares, without manual work in the AI.
3. Leaving: lock the account in the directory, and the next sign-in to the AI fails. Check how long sessions run and whether personal keys for interfaces are revoked.
4. Regular review: who is an administrator of the AI? Which groups have which shares? Once a quarter is a good measure.

For Austria: how ID Austria and the Portalverbund (the Austrian public administration portal network) can be connected is explained in ID Austria and AI.

How does this work with basebox?

Sign-in to basebox runs through Keycloak with OpenID Connect; basebox itself never sees a password. Any identity management that speaks LDAP, OIDC or SAML can be connected, for example Active Directory, Entra ID or WSO2. Everyone signs in with the account they already have; groups and roles come from your identity management, and if something changes there, it applies in basebox too. A second factor can be switched on per organisation, with an authenticator app or optionally by text message through a gateway that you connect. Password rules, session duration and lockout after failed attempts are set by your administrator in Keycloak.

basebox deliberately has few roles: people and administrators. Your administrator enables what is available; whoever builds an app shares it with groups or individual people, to use or to edit. Models, too, can be shared with specific groups only. Roles come from your identity management; no new profiles are created. In the cloud, each organisation has its own identity management (Keycloak). Changes to permissions are recorded in the audit log.