Skip to main content
With SCIM provisioning, you can let your identity provider (IdP) create, update, deactivate, and delete Plerion users automatically, and keep your directory groups in sync as Plerion user groups. Plerion exposes a SCIM 2.0 endpoint that Okta, Microsoft Entra ID, and any other SCIM 2.0 client can connect to, so a person who joins, changes, or leaves your directory is reflected in Plerion without an administrator inviting or removing anyone by hand. SCIM carries users and groups, not roles. You grant roles to the synced user groups in Plerion, and every member holds them. See User groups.

​
What changes when SCIM is enabled

SCIM becomes the source of truth for your Plerion users. Your existing SAML connection stays in place, but its job narrows to authentication.
  • SAML is used for authentication only. Just-in-time provisioning is switched off. A person who has not been provisioned by SCIM cannot sign in, even with a valid SAML assertion.
  • Only the email mapping stays in effect. Plerion still reads the email attribute out of the SAML assertion, because that is how it works out who is signing in. The display name and role mappings are disabled and hidden in the Attribute mapping section while SCIM is enabled, and Plerion takes those attributes from the SCIM payload instead.
  • User attributes are managed by the IdP. Your identity provider owns the attributes of a SCIM-managed user, so their name can no longer be edited in Plerion.
  • Roles come from user groups. SCIM carries no roles, so a user your IdP creates starts with none. Grant roles to the user groups your IdP pushes, under Admin > Directory > User groups, and every member holds them. A SCIM-managed user cannot be granted a role directly; their roles are whatever their groups grant. Users that already existed in Plerion lose the roles they had when they are adopted, so grant roles to the groups first. See User groups.
  • SCIM-managed admins do not create users in Plerion. People arrive from the identity provider, so the Add user control is not offered to a SCIM-managed admin. A break-glass admin keeps it.

​
Before you start

You need all of the following:
  • The Organization Admin role in Plerion.
  • An active SAML single sign-on connection. Set one up first with the Okta or Azure guide. Plerion refuses to enable SCIM without one.
  • Permission in your IdP to create and configure a provisioning application.
  • An organization API key with the readWrite access level, which is the credential your IdP presents to Plerion. See Organization API keys.
Use two browser sessions, or two separate browsers, while you configure your IdP and Plerion side by side. This avoids conflicts caused by sharing one login session.

​
Steps to enable SCIM in Plerion

1

Create the organization API key

  • In Plerion, go to Admin > Security > Organization API keys.
  • Click Create API key.
  • Enter a name, for example Okta SCIM.
  • Set the access level to readWrite. SCIM writes users, so a read key is rejected.
  • Click Create and copy the key. Plerion shows it once and stores only a digest of it.
Create this key while signed in as a break-glass admin. Deprovisioning a user revokes the API keys that user created, so a key created by an ordinary account stops working the moment your IdP deprovisions that account, which would leave SCIM unable to reach Plerion.
2

Go to the single sign-on settings

  • Go to Admin > Security > Single sign-on.
  • The configure screen holds four sections: Trust, Attribute mapping, SCIM provisioning, and Break-glass admins.
3

Confirm a break-glass admin

  • Open the Break-glass admins section and check that it lists at least one active organization admin.
  • If it is empty, add one, or continue and Plerion will make you a break-glass admin when you enable SCIM.
4

Enable SCIM provisioning

  • Open the SCIM provisioning section and turn SCIM on.
  • Plerion checks that a SAML connection exists, that you hold the Organization Admin role, and that a break-glass admin exists. If nobody is a break-glass admin, you become one.
  • Just-in-time provisioning switches off as soon as SCIM is enabled, and the display name and role mappings disappear from the Attribute mapping section. The email mapping stays, because SAML sign-in still needs it.
5

Copy the SCIM base URL

  • Copy the SCIM base URL shown in the SCIM provisioning section. It is specific to your Plerion region.
  • Keep it and the organization API key at hand. Your IdP needs both.

​
Connect your identity provider

With SCIM enabled and the base URL and key in hand, configure provisioning in your IdP.

Okta

Configure the Okta SCIM connector and push users and groups to Plerion in near real time.

Microsoft Entra ID

Set up automatic provisioning of users and groups in an Entra ID enterprise application.
Any other SCIM 2.0 client works too. Point it at the base URL, authenticate with the organization API key as a bearer token, and see the SCIM API group in the API reference for the supported endpoints.

​
How the user lifecycle behaves

Plerion derives the user’s email address from the SCIM payload. It uses userName when that value is an email address, and otherwise the primary or work email in the payload. Email matching is case-insensitive, and an email address is unique across all Plerion organizations.

​
Create

A user your IdP pushes for the first time is created in Plerion as a SCIM-managed user with no roles. They can sign in through your SAML connection as soon as one of their user groups grants them a role.

​
Adopt an existing user

If the derived email matches a Plerion user who already exists, Plerion adopts that user rather than creating a second record. The user keeps their user ID and their history, and becomes IdP-managed from that point on. Nobody has to be deleted and re-invited before you switch SCIM on. Adoption clears the roles the user held, including any granted to them directly. From then on their roles are whatever their user groups grant, like every SCIM-managed user, so a user whose groups grant nothing is refused at sign-in until one does. Grant roles to the groups before you assign existing users to the Plerion application in your IdP. A break-glass admin keeps their roles through adoption. Adoption also switches the user to identity-provider sign-in. From then on they sign in through your IdP, and password sign-in stops working for them, including for someone who used a password until now. The exception is a break-glass admin, who keeps password sign-in whatever else changes.

​
Update

Attribute changes in your IdP flow through to the Plerion user record. The email address is the exception: once a user is SCIM-managed, the email is fixed, because it anchors sign-in, adoption matching, and cross-region lookup. Renaming a user’s email or user principal name in the IdP surfaces as a provisioning error until you resolve it. Contact Plerion support if a managed user’s email has to change.

​
Deactivate

Deactivating or unassigning the user in your IdP removes their access to Plerion in near real time:
  • Their Plerion sessions end, so anyone signed in is signed out.
  • Every API key that user created is revoked.
  • The user record stays in Plerion as inactive, so audit history keeps its attribution.
Reactivating the user in your IdP restores their access.

​
Delete

Deleting the user in your IdP is treated as a soft delete. The user disappears from SCIM reads and cannot sign in, but the underlying record is kept. Provisioning the same email address again revives the same user rather than creating a new one.
How quickly a change reaches Plerion depends on your IdP, not on Plerion. Okta pushes changes as they happen; Entra ID syncs in cycles that can take up to about 40 minutes. Once a change arrives, Plerion applies it within seconds.

​
How user groups behave

Each group your IdP pushes becomes a Plerion user group marked as managed by your identity provider.
  • Name and membership come from the IdP. Renaming the group or changing its members happens in your IdP and syncs across. Plerion refuses those edits on its own side, and it refuses to add a SCIM-managed user to a user group you created by hand.
  • Roles are granted in Plerion. Open the group under Admin > Directory > User groups and grant it built-in or custom roles. Every member holds them through the group, and a member who is removed loses them at once.
  • Deleting the group in your IdP removes it from Plerion along with what it granted. Members keep whatever their other user groups grant. An organization admin can also delete an IdP-managed group in Plerion.
  • Your IdP only sees its own groups. User groups you created in Plerion are invisible to SCIM reads, so nothing your IdP does can touch them.
Group membership changes take effect on the member’s next request. Nobody has to sign out and back in.

​
Break-glass admins

A break-glass admin is an organization admin who always keeps password sign-in, so a misconfigured IdP or a mistaken deprovisioning can never lock your organization out of Plerion.
  • At least one is required while SAML single sign-on or SCIM provisioning is active. Plerion refuses to demote the last one.
  • You are enrolled automatically when the organization has none. Whoever first activates SAML single sign-on becomes a break-glass admin, and so does whoever enables SCIM provisioning.
  • Only active organization admins qualify. The role can be held directly or through a user group. A deactivated or invited-but-not-yet-active user is refused, because they could not sign in to recover the organization.
  • SCIM-managed users can be break-glass, and a break-glass admin can be adopted by SCIM. Neither state rules out the other.
  • SCIM cannot lock them out. While a user is break-glass, SCIM keeps syncing their attributes, such as their name, but it can never deactivate them or delete them. A deactivation or delete addressed to a break-glass admin is refused and reported back to your IdP as a sync error.
  • Their roles are locked. Promoting a user to break-glass places the Organization admin role on them directly, so a change to their user groups can never take it away. While they are break-glass, nobody can change the roles granted to them directly: not SCIM, not another admin. Demote them first if their roles have to change. A break-glass admin can also still add users.
  • Demotion hands a SCIM-managed admin back to their groups. When a SCIM-managed break-glass admin is demoted, the roles granted to them directly are cleared, the anchored Organization admin role included, and from then on they hold whatever their user groups grant. A break-glass admin who is not SCIM-managed keeps their roles on demotion, and those roles become editable again.
  • A password is not a prerequisite. A break-glass admin who has never set one uses the forgot-password flow to set one when the glass is broken.
Manage the list in the Break-glass admins section of Admin > Security > Single sign-on. Sign-in works a little differently for a break-glass admin. After they enter their email address they land on the password form, which also carries a Continue with single sign-on button, so they choose which method to use. Everyone else covered by single sign-on is sent straight to your identity provider. If single sign-on fails, the error page reminds break-glass admins that they can sign in with a password instead.

​
Troubleshooting

Provisioning problems surface in your IdP’s own log: the Okta system log or the Entra ID provisioning logs. Plerion returns a SCIM error with a message describing the cause.