Best Practice: Role Modelling for Provisioning and Access Requests in IdentityNow

Best Practice: Role Modelling for Provisioning and Access Requests in IdentityNow

 

Overview

 

 

When implementing IdentityNow, one of the first things done in a project is to begin planning how to structure roles.  At times during this process, it is discovered the roles are much more complex than originally thought.  The role analysis becomes very complex due to previous role modelling in different systems.

 

First some definitions:

  • role: Typically a business function of some sort. (e.g. job title, department, etc.)
  • reach: A statement about where the role is confined to. (e.g. location, branch, etc).  A reach can also be hierarchical.  The idea is there could be reach defined for items as granular as the city ("Austin") or as broad as the country ("United States") for example.

 

Example: User A is a bank teller that needs access into a number of applications due to his/her job title.  This is a role that grants that access.  But User A also has certain access specific to both the being a bank teller and at his/her local branch location.  User A doesn't need access to all branches, only the single branch they work at and for the bank teller job title.

 

This complexity often causes a lot of problems during planning and deployment.  There are 3 main approaches to this problem when designing a solution.

 

Notes:

  • In each of these approaches, there is still the need to maintain potentially large amounts of configuration items in relation to Access Profiles and Roles.
  • Access Profile generation cannot be dynamic.  This must be maintained via UI or Services written Role Importer Script. (See your engagement team or enter an Expert Services case for details)

 

Approach 1 - Independent Model

 

This option treats the role independent of the reach.  Because this is independent it can lead to over privileging of access.

 

Pros Cons
Quicker to Implement Can lead to over-privileging/incorrect privileging
Easier to maintain (reduced number of Roles/Access Requests - # of access + # of reach) Less than ideal user experience (Multiple requests - 1 for roles and 1 for reach)
Simplified user experience  
Processing time will be much shorter  

 

 

 

 

Approach 2 - Combined Model

 

This option treats the role and reach linked together.

 

 

Pros Cons
Very Specific access granted Large amount of combinations to maintain (# of roles x # of reaches)
No over-privileging More complex user experience
Less ambiguity of Access Request Processing time will be much longer

 

 

 

 

Approach 3 - Only Access

 

This option doesn’t consider the reach at all. IdentityNow will provisioning requests with the role needed only.  There will need to be an outside process to manage the reach access and changes to that.

 

Pros Cons
Quicker to Implement Cannot handle a Mover Use Case for the Reach (If role doesn't change, but reach does IdentityNow will not know about it)
Easier to maintain (reduced number of Roles/Access Requests)  
Simplified user experience  
Processing time will be much shorter  

 

Labels (1)
Version history
Revision #:
2 of 2
Last update:
‎Jun 23, 2020 03:37 PM
Updated by:
 
Contributors