WSO2 Identity Server 5.0.0 Provisioning Framework

The WSO2 Identity Server 5.0.0 takes the identity management into a new direction. No more there will be federation silos or spaghetti identity anti-patterns. The authentication framework we introduced in IS 5.0.0 powers this all. Along with the authentication framework we also introduced a provisioning framework. The objective of this blog post is to introduce high-level concepts associated with the provisioning framework.

Inbound Provisioning

Inbound provisioning talks about how to provision users to the Identity Server. Out-of-the-box we do support inbound provisioning via a SOAP based API as well as the SCIM 1.1 API. Both the APIs support HTTP Basic Authentication. If you invoke the provisioning API with Basic Authentication credentials, then where to provision the user (to which user store) will be decided based on the inbound provisioning configuration of the resident service provider.

The SCIM API also supports OAuth 2.0. If the user authenticates to the SCIM API with OAuth credentials, then the system will load the configuration corresponding to the service provider who owns the OAuth client id. If you plan to invoke the SCIM API via a web application or a mobile application, we would highly recommend you to use OAuth instead of Basic Authentication. You simply needs to register your application as a service provider in Identity Server and then generate OAuth keys.

Just-in-time (JIT) Provisioning

Just-in-time provisioning talks about how to provision users to the identity server - at the time of federated authentication. A service provider initiates the authentication request, the user gets redirected to the Identity Server and then Identity Server redirects the user to an external identity provider for authentication. Just-in-time provisioning gets triggered in such a scenario when Identity Server receives a positive authentication response from the external identity provider. The Identity Server will provision the user to its internal user store with the user claims from the authentication response.

You configure JIT provisioning against an identity provider - not against service providers. Whenever you associate an identity provider with a service provider for outbound authentication, if the JIT provisioning is enabled for that particular identity provider, then the users from the external identity provider will be provisioned into the Identity Server's internal user store. In the JIT provisioning configuration you can also pick the provisioning user store.

JIT provisioning happens while in the middle of an authentication flow. The provisioning can happen in a blocking mode or in a non-blocking mode. In the blocking mode, the authentication flow will be blocked till the provisioning finishes - while in the non-blocking mode, provisioning happens in a different thread.

Outbound Provisioning

Outbound provisioning talks about provisioning users to external systems. This can be initiated by  any of the followings.

1. Inbound provisioning request (initiated by a service provider or the resident service provider)
2. JIT provisioning (initiated by a service provider)
3. Adding a user via the management console (initiated by the the resident service provider)
4. Assigning a user to a provisioning role (initiated by the the resident service provider)

WSO2 Identity Server out-of-the-box supports outbound provisioning with following connectors. You need to configure one or more outbound provisioning connectors with a given identity provider, and associate the identity provider with a service provider. All the provisioning requests must be initiated by a service provider - and will be provisioned to all the identity providers configured in the outbound provisioning configuration of the corresponding service provider.

1. SCIM
2. SPML
3. SOAP
4. Google Apps provisioning API
5. Salesforce provisioning API

Conditional Provisioning with Roles

If you want to provision a user to an external identity provider, say for example to Salesforce or Google Apps, based on the user's role, then you need to define one or more provisioning roles in the outbound provisioning configuration of the corresponding identity provider.