LDAPWiki: User Provisioning

Overview[1]#

The User Provisioning process is intended to help organizations more securely manage information about users on multiple systems and applications.

All Organizations perform User Provisioning either manually or automated and most have some combination of both.

User Provisioning is typically associated within the an Identity Management Architecture.

User Provisioning is handled within the Identity Lifecycle Management

In the complex Regulatory Environment Provisioning Auditing must be implemented within User Provisioning.!! Goals of User Provisioning To begin with, a discussion on the goal of User Provisioning. Typically, the term User Provisioning to encompass a large set of functions. Sometimes, these functions are also collectively referred to as User Management.

The set of functions under the User Provisioning ‘umbrella’, then, are easily described with the acronym CRUD. If you’re familiar with database management, this acronym will be familiar as referencing the common database operations of Create, Read, Update, and Delete. When we borrow the acronym for User Provisioning, however, there is a slight modification:

Create: Create fresh users in the downstream application or directory based on values derived from the a user Profile and Claims (think Group assignments).
Read: Import users from the downstream application or directory in order to match them to existing users, or to create new users from the imported application or directory users.
Update: For an application or directory user that is affiliated with or ‘tied to’ an user, update the downstream user’s attributes when the user is updated.
Deprovision (not typically a Delete): ‘Deprovision’ the application user from the downstream application. This can take many forms; user disabled, user access permissions changed, user license pulled, etc. Confirm specific functionality on an app by app basis.

But, most Mobile Apps and WEB Application do not require a user to be provisioned to the WEB Application. Typically, the WEB Application, only needs some assurance that the user is has Authenticated. The OpenID Connect Provider provides a “sub” claim which is guaranteed to be Unique for that Provider. The WEB Application can use the "provider-sub" combination as a identifier so that when that same user returns to the WEB Application, the user can be identified.

Further, if an Organization desires central control of the user’s ability to Authenticate and/or of permission assignment, using OpenID Connect provides this ability without performing User Provisioning.!! More Information There might be more information for this subject on one of the following:

[#1] - User provisioning software - based on data observed:2015-05-18