Format [ENV:AppName:RoleName] where:
ENV - environment (TEST/ACC/PROD). Mandatory when roles from all environments are managed in one MP.
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.
e.g. TEST:Office365:EndUser
Additional format examples:
[AppName:RoleName_ENV], [appname-rolename]
IGA Deployment Methodology - old notes
Table of Contents
| This page is a work in progress. |
This document lists what should be identified and defined at the early stages of the IGA implementation in an organization. Role engineering and maintenance and Role request processes are in main focus now.
This definition is customer specific. Results of the methodology definition may be listed in the "Role design" document.
1. Naming conventions
Naming convention for roles
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.
- Additional notes
-
-
language - should be English. If the organization doesn’t use english at all, then the naming can be in other language. This also relates to all components of the role (description, ..).
-
decrease complexity - do not overcomplicate. Must be easy to understand for people.
-
whether all roles are managed in all environments
-
Environment name may not be included in the role name, but additional care must be held during role management - to be sure what environment is admin modifying.
-
role type (application/business) should not be defined in the role naming. Readability can be increased by different graphical display of the roles using archetypes.
-
- 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
e.g. SK:Accountant:PROD
2. Structures of main objects
Interpretation of "Who has access to what" in midpoint.
-
Role structure (how many levels)
-
Application structure
-
User’s structure - scoping users in reports
-
Organization structure
3. Rules for specifying risk level and access level
There can be 2 views for computing the risk of access - quantitatively define level risk of assigning the application role,(represented by risk level number) or qualitatively identify roles that are risky (represented by access level value).
The user’s overall risk of the access then may be computed by (e.g.) sum of risk level of all roles assigned to the user. Or, it may be computed by identifying the user’s highest access level value.
Definition of risk level or access level may be subjective, but if the values are assigned consistently to all or most of the roles, it would be very helpful in risk based management of the access.
It is hard to say whether identification of the risk based on risk level or access level is better.
- Risk level
-
Risk level represented as value can be used for computing risk level of access for roles. It is easier to compute and can identify users with broad access.
- Access level - application roles
-
Access level helps better distinctive manage risk of access level
-
Basic user access
-
Power user access
-
Privileged access
-
- Access level - business roles
-
The field should be computed for business rules. The value is based on application roles access level, but most of business roles contain different types of roles. Following types can explain access level of the role quite nice:
-
Basic user access
-
Partially power user access
-
Power user access
-
Partially privileged user access
-
Privileged user access
-
The access level values will be computed according the following rules:
| Level | Rule |
|---|---|
Basic user access |
all contained roles are only basic access level |
Partially power user access |
>0 and <50% of contained roles are of power user and 0 privileged user |
Power user access |
>=75% of contained roles are of power user, 0 privileged user |
Partially privileged user access |
>0 and <50% of contained roles are of privileged access |
Privileged user access |
>=50% of contained roles are of privileged access |
Was this page helpful?
YES
NO
Thanks for your feedback