Identity federation
Identity federation lets your identity provider decide who has access to Strise. Your organisation gets its own single sign-on connection, and optionally user provisioning (SCIM): groups in your directory are synced to Strise, each group is mapped to a role on a team or on the whole organisation, and removing someone from the group removes their access here. Offboarding happens once, in your directory.
It builds on Single Sign-On. That page explains the difference between the shared Microsoft and Google buttons and a dedicated connection; this page covers setting up and running a dedicated connection with provisioning.
Where to find it
Open the account menu (your avatar, top of the sidebar) → Organisation → Identity federation. The page is visible to anyone holding the View identity federation permission and editable with Configure identity federation. Both are part of the Organisation Admin role. See Organisation for the rest of that area.
Setup
Setup has three parts. Strise starts it, the person who administers your identity provider completes it, and you finish by mapping groups.
1. Strise issues a setup link
Contact support@strise.ai. We issue a setup link that appears on the Identity federation page under Setup status. The link is valid for five days. If it expires before anything is connected, nothing that was entered is kept; ask for a new one.
2. Your identity provider team completes the guided setup
Share the link with whoever administers your identity provider (Copy link on the page). It opens a guided setup where they:
- Choose the provider: Microsoft Entra ID, Okta Workforce, or another SAML provider.
- Register Strise as an application there and paste the application's identifiers back into the setup. The setup shows the exact redirect URL and, for SAML, the entity id to use. With Microsoft Entra ID, they also change one attribute mapping when they turn on provisioning in step 6. See the warning below that step.
- Review the claims Strise reads: email is required, name, given name, family name and username are optional. These are standard claims that every supported provider sends by default.
- Assign the users or groups who should be able to sign in.
- Test the sign-in.
- Optionally turn on provisioning. The setup then shows a SCIM endpoint URL and a token. They paste both into the provisioning settings of the application in your identity provider. The token is shown once.
Microsoft Entra ID: change the externalId mapping before provisioning
Before the first provisioning cycle, open the application in Entra and go to Provisioning →
Mappings → Provision Microsoft Entra ID Users. In the externalId row, change the source
attribute from mailNickname, Entra's default, to objectId.
If you skip this, each person's first sign-in creates a second user in Strise next to the provisioned one. The second user has none of the roles their groups grant.
In the same externalId row, set Match objects using this attribute to Yes and
Matching precedence to 1. Entra needs a different precedence on each matching attribute, so
set externalId to 2 first, move userName to 3, then set externalId to 1. Without this,
provisioning never picks up a person who signs in before their first provisioning cycle.
If provisioning already ran with the default, fixing the mapping is not enough. Contact support@strise.ai to remove the duplicate users. Then use Stop provisioning and Restart provisioning in Entra. Entra does not notice that Strise removed the users, and restarting clears its list of users it already sent, so it sends everyone again.
Nothing changes for your users at this point. Anyone assigned can sign in through your provider; their access inside Strise is unchanged until you map groups and turn on enforcement.
3. Strise picks up the connection
The Identity federation page updates itself once the guided setup is finished, or use Check now. It then shows the connection, the groups seen so far, and the mapping editor. Groups and users that your provider pushes appear within about an hour of the connection being bound, usually much sooner.
Provisioning
With provisioning on, your identity provider tells Strise about users and groups. Strise never writes back to your directory.
| In your identity provider | In Strise |
|---|---|
| Assign a user to the Strise application | The user is created, with name and email from the directory. No team access yet. |
| Change a user's name or email | The user's profile is updated. |
| Push a group / add a group to the application | The group appears under Groups. Groups are discovered here, never created here. |
| Add or remove a member of a pushed group | While Discovering: recorded. While Enforcing: the mapped roles are granted or revoked. |
| Rename a group | The name updates. Mappings follow the group, not its name. |
| Unpush or delete a group | Its mappings are removed and the group disappears from the list. |
| Unassign or deactivate a user | The user can no longer sign in. Their memberships stay until the group changes revoke them. |
Users provisioned this way cannot be deactivated from Strise, and roles on teams your provider governs cannot be changed by hand while enforcing. Both are done in your directory. See Deactivating someone.
Mapping groups to roles
Open Edit mappings. Each group from your directory can grant one or more roles, each at a place:
- Organisation — the role applies in every team, including teams created later.
- Teams — the role applies in the chosen teams only.
Roles are the same ones you assign by hand, see Members and Roles & Permissions. A group with no mapping grants nothing; its members can sign in but have no team access from it. Mappings save per group, so finish or remove an unfinished grant before saving.
The By team view shows the same mappings from the other side: which groups grant which roles at each team.
Discovering and Enforcing
A connection is always in one of two phases.
| Phase | What Strise does |
|---|---|
| Discovering | Groups and memberships are recorded and shown. No roles are granted or revoked. Everything you configured by hand keeps working. Safe to leave on while you map. |
| Enforcing | Memberships drive roles. Adding someone to a mapped group grants the role, removing them revokes it. Roles at governed teams are locked to the provider. |
Start enforcing
Start enforcing opens a dialog that reads your provider first and shows what would happen:
- Where to enforce — The whole organisation, every team whether mapped or not, or Only teams with a role mapping. With the whole organisation, roles held by hand on unmapped teams are removed too, and organisation-level roles are enforced. With mapped teams only, unmapped teams stay manual, and mapping a new team later brings it under enforcement.
- Unmapped groups — groups that grant nothing, with how many people are in them. Mapping them is not required and can be done afterwards.
- Lockouts — people who would be left with no access because nothing they hold is backed by a mapped group. You can go ahead and fix them afterwards. If you are one of them, enforcing is refused rather than confirmed: map a group you belong to first, because there would be no way back in.
Return to Discovering is available at any time and takes effect immediately. It stops enforcing and unlocks manual changes; it does not undo grants or revocations already made.
While enforcing
- Every grant and revocation made by the provider appears in the Activity log with Identity provider as the actor, one entry per person per change. Changes to the federation itself — issuing or cancelling the setup link, setting it up, editing a group's mapping, switching phase and removing it — are logged there too, under the person who made them. A setup completed by Strise's hourly check shows Strise as the actor, and a mapped group your provider deletes shows Identity provider.
- A padlock in Users & access marks teams your provider governs.
- Strise reconciles the mapped state against the recorded memberships once an hour and corrects any drift, for example a change your provider sent while Strise was unavailable. Last sync on the overview shows when it last ran and whether it failed.
Provider notes
| Provider | Protocol | Provisioning notes |
|---|---|---|
| Microsoft Entra ID | OIDC | Entra provisions on a cycle of roughly 40 minutes. Use Provision on demand in Entra to push a single user or group immediately. Change the externalId mapping before the first cycle. See the warning in step 6 of the setup. |
| Okta Workforce | OIDC | Sign-in uses an OIDC web application; provisioning uses a second application from Okta's catalog, (OAuth Bearer Token) Governance with SCIM 2.0, with the endpoint URL and token from the setup. Both applications must have the same assignments, or provisioning silently does nothing. Okta pushes within seconds. |
| Other SAML | SAML | Provisioning depends on the provider's SCIM client. The endpoint URL and token from the setup work with any SCIM 2.0 client. |
Frequently asked questions
Can we use provisioning without changing how people sign in? No. Provisioning is tied to the dedicated connection, so users provisioned this way sign in through your provider.
What happens to people who were invited by hand before? Their roles stay as they are until you enforce. When you start enforcing, anyone whose roles are not backed by a mapped group shows up under Lockouts in the dialog, so you can map a group for them or accept the change. If your directory also provisions them, they keep the Strise user you invited. The next question explains when.
What happens to people who already have a Strise user when the directory provisions them? Once the connection is in Enforcing, a provisioned person keeps their existing Strise user when all three are true:
- their Strise user was created by an invitation to their login email, and they can log in to it with a login code or a passkey
- that login email matches their email in your directory
- all of that user's access is in your organisation
Logging in with a Google or Microsoft account as well doesn't change this.
From then on they sign in through your provider. Their teams, roles, and history stay on that user. While the connection is in Discovering, nothing changes for such a person and they get no second user. Strise matches them to their existing user at the first sync after you start enforcing.
Anyone else gets a new user next to the old one. That covers people who:
- got their Strise user by logging in with a Google or Microsoft account, or through another single sign-on connection such as SAML or Entra ID
- have a user with access in another organisation
- have more than one such user on that login email
The new user gets the roles granted by the groups the person belongs to in your directory. Contact Strise support if the two should be one user.
Does removing a group in our directory delete users in Strise? No. It removes the group's mappings, which revokes the roles those mappings granted while enforcing. The users remain and can still sign in.
How do we rotate the SCIM token or change the provider configuration? Contact support@strise.ai. The guided setup is issued per connection and is not reopened by yourself yet.
Last updated on