Format [AppName:RoleName:ENV] where:
AppName - short name of the application. May be different from full name to keep role names shorter. Just must be pretty clear which application it means.
RoleName - Explanatory name of the access role. This name must be clear for users using the application.
ENV - environment (TEST/ACC/PROD). Mandatory when roles from all environments are managed in one MP.
Example: "Office365:EndUser:TEST"
Additional format examples:
[ENV:AppName:RoleName], [appname-rolename]
IGA Deployment
Table of Contents
1. IGA Deployment
The IGA deployment is not only about technology implementation. This is not enough. IGA solution acts as interconnection between business (processes) and IT (technology) worlds. So it must be integrated into processes of organization.
IGA solution is complex - it integrates data from multiple sources, affects multiple internal processes. The iterative implementation with continual improvements is a good way how to achieve good results.
Even when going in iterations, some things must be done in advance:
1.1. Initial steps
As a result of initial steps, the basic role model should be prepared. Part of the applications are imported in IGA and roles for these applications are assigned to people.
The IGA is no longer just a theoretical exercise, but has real examples to show real approach, and it is possible to get involved in internal company processes.
Start with low-hanging fruit - it will help you show results faster and onboard applications/users/processes with less effort. Choose systems that are well-prepared or teams you have good communication with. Do not go too deep in role management, do not try to resolve all issues on particular applications.
- Business driver
-
When you finish initial steps, you can tell who has access to what. Just on very small scope of applications.
So, how to start ?
1.1.1. Initial Role model design
To start, you need to define basic design of roles. At least something to start with. Even with knowledge that the design will be updated later.
Decide scope of the role model - which applications will be managed. You can start with applications from some organizational part (e.g. internal applications) that are quite well-prepared. The scope should declare also environments that will be managed by IGA. But this depends on the configuration of organizations IT infrastructure.
Decide depth of the roles - what roles will be managed in IGA. Do not try to go too deep in role structure and stay in coarse-grain access level. For most apps, the good start is to have just few roles - 10 is maximum.
Applications typically have few roles for users with large user sets (e.g. user, power users, approvers, …) and then there are small set of technical users performing support (application administrators, database admins, operators, … ). Start with standard users. Their management is more automated and organized, there are fewer exceptions to be resolved and including these users provide faster results in increasing visibility and faster provisioning.
Define basic structure of business roles for initial role model. You don’t need to prepare this model per organizational structure, just identify top level (e.g. Internal employees, contractors, managers, ..). Prepare naming and description and find agreement with their ownership.
Naming convention for roles
Define naming structure of the roles and some rules. Define what everything should be in the name. Balance complexity and readability.
Well-defined naming helps in daily operation and working with the roles. It saves time on daily basis of all the users by easier searching and better overview.
Application roles shall contain application name (short form is acceptable). This is visually telling the user that he will get access to the particular application. Application name is well explaining the scope of the role.
Business roles, on the other hand, will not contain any application definition. These roles do not need scoping by default. In large organization, the business role name may include the highest organizational level or country definition for scoping.
- Examples of the application role naming
- Examples of the business role naming
Format [ORG:RoleName] or [ORG:RoleName:ENV] where:
ORG - highest level organization in large corporation - or country in country organization
Examples: "SK:Accountant:PROD"
or just "Accountant"
1.1.2. Integrate applications
To integrate an application into midPoint means creating objects representing the application itself and application roles and synchronizing their content with the state in the environment.
Start with applications and sets of roles that are easy to integrate. You don’t need to integrate all roles from the application at the beginning, just start with the most used ones. But implement all that are easy to implement - or share the same configuration pattern.
Example of application integration - new application
We can describe the integration on an example of application App 1 that has access managed via LDAP groups.
An user accessing application need to have account in LDAP system and be member of app1-users or app1-power-users groups.
Let’s assume in the beginning, that the application is new, the LDAP groups are configured and are empty and the LDAP is configured as resource in midPoint.
- Step1
-
The application
App 1is represented in midPoint by service object. So you need to create it. Manually, or load from any application inventory (if you have one). Fill in details - at least name, description and ownership.If you are managing multiple environments in one IGA, then define one service per each environment. Access to application in production is something else than access to test environment and this must be distinguished.
- Step2
-
Create role representing each application role. In the role define construction of LDAP account and the entitlement - assignment of the user in the particular LDAP group.
Additionally, create inducement to the Application object. This inducement represents user’s access to the application. TODO xref:
- Step3
-
Assign newly created roles to the particular users and verify that the roles were correctly provisioned.
1.1.3. Initial update of assignments
The previous example described situation when the entitlements (group membership) was not provisioned yet.
In reality, there are a lot of individual entitlements already configured in systems and IGA solution must not only manage new roles, but also map existing ones.
Existing entitlements must be loaded to midPoint and transformed to application roles. The entitlements may be already loaded in midPoint. If not, engineer need to load them as technical roles.
Technical role archetype represents entitlements in midPoint, that are not fully configured to represent application role. The creation of new Application role for the application is represented by the transformation of technical role to application role.
Example of update of assignments
Let’s continue with previous example, but assume, that the groups app1-users and app1-power-users are filled in LDAP with users and are already used.
- Step1
-
Load the entitlements (the LDAP groups) from LDAP resource. Define specific object type for the entitlements in the resource definition, configure it and perform initial load - e.g. via reconciliation. The entitlements should be represented as technical roles in midPoint. Together with entitlements, load also their assignments to the users.
- Step 2
-
Transform the entitlements represented by technical roles to application roles. Fill in business details of the application role (description, owner, risk level, …) and, as defined in creation of application role, define inducement to application.
TODO - unfinished
1.2. Start of processes
TODO
1.2.1. Start Access Request process
TODO
1.2.2. Start Role Engineering process
TODO
1.2.3. Initial tuning of processes
TODO
1.2.4. Start Access Certification process
TODO
Was this page helpful?
YES
NO
Thanks for your feedback