Provisioning & de-provisioning
Provisioning & de-provisioning
Provisioning is part of access right management process, but most commonly its expanded when more and more use case from different processes are taken into use.
Provisioning generally means that information is delivered automatically or manually between IGA solution and directories / applications. When information is delivered automatically, it requires that one of the ready-made connectors are taken into use, or integration to the target system is established some other way (using API's, integration platforms etc.). Manual provisioning means that provisioning request is delivered as a ticket to support group or as a email to the application main users, usually also response is sent back to IGA solution after manual request has been closed. Provisioning can be also combination of manual and automatic provisioning.
Difference between provisioning and de-provisioning is the actual action what is performed, meaning that each time users, access right relations etc. are added to the directory or application, its called provisioning. When for example group-membership connection is removed, its called de-provisioning. Generally in this article is referrering to provisioning.
Provisioning is part of several use cases, like for example request access rights, when group-membership connection is created based on the request made in Self-Service. Provisioning can also happen several times during the use case like for example when users are created, provisioning happen several times during the workflow (for example users unique attributes are verified to be unique like email address, UPN, samaccountname etc.).
Use case description
This use case can be expanded with other processes and those has been marked,
* User lifecycle management
** Governance
*** Automation & provisioning
**** Expanded access right management
| Description | |
Overview |
This use case describes how provisioning process works. There are three (3) different provisioning types: If there is exception in provisioning, IGA solution will notify IGA Admin. |
Operators |
IGA solution |
Prerequisites |
All entitlements and user’s information for provisioning scope needs to be available for IGA solution. |
Result |
Provisioning task is completed successfully or an IGA Request / IGA Admin Task is created to IGA Admin for manual handling. |
Operating chain |
|
Related datacards |
IGA request |
Delete
Expansion possibilities
Expansion possibilities are categorized in three category, but it is always important to validate if requested change has affect to the delivery schedule or work estimations.
Notice, that these expansion possibilities concerns mostly features that need actual configuration changes. Daily admin tasks are described in the use case.
| Category | Description |
|
Small (less than hour) |
Small changes does not usually affect to the delivery schedule or work estimations and these changes can be done also by IGA admins,
|
|
Medium (0,5 - 2 work days) |
Medium changes can be for example,
|
|
Large (more than 2 work days) |
Large changes usually takes longer time, since they require more detailed definition-, and testing work. Those can be for example,
|
Relations & configuration instructions
Relations to other use cases,
This use case is related almost to all use cases where provisioning is made.
Relations to other data cards,
IGA Request
Person
Identity Storage
Configuration instructions,
- With IGA baseline there is no need to edit workflows or EPEtasks to achieve this use case. Event-based task are executing these provisioning and those are configured in other use cases.
Unit testing instructions,
- This use case is tested along with other use cases, so no need to make separate tests
System and user approval testing instructions
This use case is tested along with other use cases, so there is no need to test this use case separately.
Delete