This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links
User Provisioning
User Provisioning

Version management

Difference between version and

At line 1 added 25 lines
!!! Overview[1]
The [{$pagename}] process is intended to help organizations more securely manage information about users on multiple systems and [applications].
All Organizations perform [{$pagename}] either manually or automated and most have some combination of both.
[{$pagename}] is typically associated within the an [Identity Management Architecture].
[{$pagename}] is handled within the [Identity Lifecycle Management]
In the complex [Regulatory Environment|IDM Related Compliance Items] [Provisioning Auditing] must be implemented within [{$pagename}].!! Goals of [{$pagename}]
To begin with, a discussion on the goal of [{$pagename}]. Typically, the term [{$pagename}] to encompass a large set of functions. Sometimes, these functions are also collectively referred to as [User Management].
The set of functions under the [{$pagename}] ‘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 [{$pagename}], 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:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [User provisioning software|Wikipedia:User_provisioning_software|target='_blank'] - based on data observed:2015-05-18
This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthorTop