Identity and access model
OSIE sits in front of one or more OpenStack clouds. It manages identity and access — who a user is, which organization they work for, and what they are allowed to do — while OpenStack holds the resources they create. Neither system replaces the other, and OSIE keeps the two in step.
This page follows one user from signing in to running a server, and shows what exists on each side at every step. It assumes no prior knowledge of OSIE. Each section covers the model, and links to the page in the Administrator's manual that configures it. For what each role may do, see Roles and permissions.
It starts with a realm
Everyone who signs in does so within a realm. A realm is a self-contained sign-in boundary, and everything about how its users authenticate lives inside it:
| Users | Unique per realm, so the same email address can exist in two realms as two unrelated people |
| Login page | Its own, at https://<your-host>/auth/realms/<slug>/login. The realm marked default also serves the platform's main sign-in page |
| Identity providers | Its own set, and its login page offers only those — configure them |
| Sign-up policy | Self-registration, two-factor enforcement, passkeys and social sign-in, decided per realm |
| OIDC issuer | Every realm is a full OpenID Connect provider, at https://<your-host>/realms/<slug> |
| OpenStack access | Which domains its users are provisioned into, and how — configure it |
How you divide realms is your choice. One shared realm can serve everyone who signs up for your public cloud, and an enterprise client — typically one bringing its own identity provider — can be given a realm of its own. Most installations run both at once. A client with a dedicated realm signs in at its own URL, sees only its own sign-in options, and cannot reach anything in another realm.
One realm can also act as an identity provider for another, which is how a single broker realm fronts many customer realms and keeps OpenStack configured once for all of them — see Linking realms.
Whether the realm checks the password itself or delegates to a customer's own identity provider makes no difference to anything below: by the end of sign-in, OSIE knows who the user is and which realm they came from. Realms themselves are created and managed in the admin dashboard — see Realms.
Their work lives in organizations and projects
Inside the realm, an organization represents the customer company, and holds its billing details, its members and its projects. A project is where resources live — servers, volumes, networks.
A user holds two memberships, each with its own role:
- In the organization, their organization role decides whether they manage members, projects and billing for the company.
- On each project, their project role — Owner or Member — decides whether they may rename it, invite people to it, or delete it.
Project members are drawn from the organization: when a project is created you choose which members join, and organization owners and administrators join as project owners. Both sets of roles are described in Roles and permissions.
Nothing so far exists in OpenStack. This is the OSIE side of the picture, and it is the same whichever cloud the customer ends up using.
Provisioning a project on a cloud
A project becomes real on a cloud when it is provisioned there. The domain it lands in comes from the realm's OpenStack domain access mapping. That domain is not created by OSIE — it must already exist in Keystone, and the mapping only says which one this realm's users and projects belong to on this cloud.
That is the auto-provision strategy: OSIE creates a Keystone user for each person and manages its password, so they never deal with Keystone directly. It needs no Keystone-side configuration and works on any OpenStack deployment.
The result on each side:
| OSIE | OpenStack | Relationship |
|---|---|---|
| Realm | Domain | The realm's domain access mapping names an existing domain, per cloud; its users and projects are created there |
| Organization | — | An ownership and billing grouping; it has no OpenStack counterpart |
| Project | Project | OSIE creates one Keystone project per cloud the project is provisioned on |
| User | User | A Keystone user OSIE creates and manages, or the person's existing Keystone identity |
| Project membership | Role assignments | Roles granted to that user on that Keystone project |
Give each customer realm its own domain and the separation between customers extends all the way into Keystone, where domains are already the strongest boundary the identity service has.
A project provisioned on a second cloud gets a second Keystone project, in that cloud's mapped domain. The two are independent: a resource, a quota or a role assignment belongs to one of them, never to both.
Keystone federation
The other strategy applies where people already have a Keystone identity, and authenticate to Keystone themselves — through single sign-on, or by signing in to OSIE with their Keystone username and password against an LDAP-backed domain. OSIE creates no Keystone user for them and stores no OpenStack credentials. It works with the token they obtain, and pushes their project roles onto the identity behind it.
A realm can use both strategies at once: it is chosen per mapping, and a mapping can cover every user of the realm or only the users of one identity provider. The valid combinations are listed with the mapping form. See Keystone federation for the OpenStack-side configuration.
Checking the result from OpenStack
What the two flows leave behind is ordinary OpenStack, so the usual admin tooling reads it. Projects
OSIE created carry the tags provisioner:osie and osie_project_id:<id>, and users it manages are
named osie:<user-id> and carry the person's email address. Nothing else belongs to OSIE — domains
are used and never created, and every server, volume and network is created by the member who asked
for it, under their own identity.
openstack project list --domain acme
openstack role assignment list --project <project-id> --names
Adding and removing a member
Membership is the one thing OSIE is authoritative for, and it keeps Keystone in step with it. Roles are granted when someone joins, topped up when they sign in, and revoked when they leave.
The last exchange matters. A role a user holds through a Keystone group was not granted by OSIE and cannot be revoked by it, so OSIE reports the residual access instead of showing a removal that did not happen.
Working in the portal
The portal never acts as an administrator on a user's resources. It checks membership, obtains a token for that user scoped to that one project, and every call to the cloud carries it.
Working from the CLI
Resources do not have to pass through the portal. A member issues themselves an application credential and drives the cloud directly, with OSIE out of the path.
The credential carries what the user already holds, in one project on one cloud, and stops working when it is deleted or when they leave the project. The client-facing steps are in Access the cloud APIs.
Access scope
Three bounds apply to every call, in both flows above, and all three have to be satisfied.
Membership. A request that names a project is served only to a member of it. Projects a user does not belong to stay out of their listings and cannot be addressed by id.
Token scope. OSIE obtains a token for the user's own Keystone identity, scoped to the single project in play. Its cloud administrator credentials are used for lifecycle work only, never to act on a user's resources. A token issued for one project cannot name another.
Role assignments. A token grants what the user's roles on that project allow, and Keystone issues no token at all for a project the user holds no role on. The same bound applies from the CLI, where a credential carries what its issuer already holds.
Between domains, separation is Keystone's own: a domain-scoped role in one domain confers nothing in another. Mapping each customer realm to its own domain therefore extends the boundary to the whole customer.
Two things follow from this:
- Removing a member withdraws their access in both systems, as the membership flow above shows.
- Access granted directly in OpenStack stays outside OSIE's control. A role an operator assigns to a user, or to a Keystone group they belong to, grants the project regardless of OSIE. Remove the OpenStack-side assignment to withdraw it.
Access decisions
| Question | Decided by |
|---|---|
| Who the user is, and how they proved it | The realm, or the identity provider it delegates to |
| Which organizations and projects a user belongs to | OSIE |
| Which domain a user's projects are created in | The realm's OpenStack domain access mapping |
| Whether a specific API call on a resource is allowed | Keystone and the OpenStack service, from the token |
| Quotas, resource limits, policy | OpenStack |
OSIE is authoritative for membership, and grants the roles that follow from it. It never overrides an OpenStack decision, and it never relays a call the token would not have been allowed to make.