Provisioning / SCIM - General information

What is automatic provisioning ?

By default, Steeple users' access and role to an organization's communities must be manually assigned or revoked by an administrator of those communities.

This manual management can be simplified by using SSO, which allows administrators of the identity provider used (provided it is compatible) to configure access and roles directly within the tool using properties specific added to its users. The moment the SSO authentication mechanism occurs, these specific properties are evaluated by Steeple to provide access to new communities (if any) with the appropriate role. Note that this mechanism does not allow to revoke accesses or roles, only to give new ones if necessary, and that it only triggers when the user authenticates (i.e. say at the renewal of his session).

It therefore appears that management by default or by SSO does not constitute a fully automated and continuous solution for configuring access and roles for an organization. For such a solution, one must use the automatic provisioning functionality for the organization.

Automatic provisioning allows the following data of an organization to be configured directly within the identity provider (if compatible):

  • identity data (first name, last name, email, etc.) of a user
  • right of access of a user to a community
  • user access roles to a community

Changes made within the identity provider are then reflected in a few moments on the content of the Steeple organization, without any need for manual action on the Steeple side.

Since the effects of auto-provisioning are produced from the same source of truth used for SSO (namely the identity provider), there is no risk of conflicts between these two functionalities, which meet different but complementary needs.

We therefore recommend that any organization that wants simple, consistent and secure management of its users on Steeple configure both SSO and single provisioning.

Configuring automatic provisioning

Steeple implements auto-provisioning using the protocol SCIM.

The implementation is based on a principle of one-way communication from an identity provider with a user directory (Azure AD, Okta, etc.) to a service provider (Steeple). Three sets of resources can thus be automatically synchronized from one to the other:

  • the users
  • the groups
  • user group memberships

When a change to a user, group, or user/group membership is made on the identity provider side, it is communicated almost immediately to Steeple through a direct exchange between the identity provider and steeple.

For a given organization, Steeple is therefore able to reconstruct the state of a directory of users and groups as maintained and published by the identity provider.

Note that it's not entirely possible to directly match the resources exposed by the identity provider to those of the Steeple org:

  • an organization's communities are independent of the identity provider
  • the identity provider does not directly expose objects that may correspond to a user's role in a community

To solve this correspondence problem, the groups of the identity provider are associated on the Steeple side with a couple (community, role), thus making it possible to derive from the membership of a user to a group on the IdP side the membership of a community with a role given to a user on the steeple side.

Setting up automatic provisioning therefore requires two specific actions:

  1. configure communication between the identity provider and Steeple on the access provider side
  2. configure group/community/role mappings on the steeple side

We refer you to the dedicated document for the configuration according to your identity provider:


Remarks

  • Disabling or deleting a user on the provider side results in the removal of the user from the organization on the Steeple side. The account will remain available to its owner, but he will no longer be a member of any community in the organization.
  • When a user is removed from a community as a result of automatic provisioning, any posts in the community become invisible to the community. A manual action from the support or a coach is then necessary to reassign the publications on request to another user still belonging to the community.