IGA process parameters and mechanisms
To guarantee an efficient and compliant functioning of the IGA processes, there are several parameters that must be configured. The parameters range from governance in the form of responsibilities to setting timers to trigger events.
Stakeholder definition
The table shows a list of key stakeholders that interact with Omada Identity.
| User group or type of user | Definition or criteria | What can they do in the Omada Identity portal? |
|---|---|---|
| Everyone | All users of the Omada Identity portal. | - Have read access to users and process templates (additional security can be applied to the actual process templates). - View which access rights they have. - Request additional access for themselves or others. - Reset password for owned auxiliary accounts. - Remove access for themselves. - View all resources. - Change password. |
| Employees | All identities in the Employee category. | Update contact information of their identity record. |
| Contractors | All identities in the Contractor category. | Update contact information of their identity record. |
| Managers | All identities that are managers of an identity or an Org. Unit. | - Approve access requests requiring manager approval for their managed employees and non-employees. - Attest current assignments of managed identities (re-attestation). - Lock/unlock identities for managed employees and non-employees. - Remove access for managed employees and non-employees. - Update identity information for own identity and managed non-employees. - Own resources. - Transfer ownership of managed non-employees (only primary manager). - Re-attest non-employee identity/status. |
| Application Onboarding Administrator | All users in this group. | Execute the Verification step in the Application onboarding process. |
| Application/System Owner | Responsible for/owner of an IT system. Criteria: Owns one or more systems. | - Monitor who has access to their system. - Transfer IT system ownership. - Conduct recertification of accounts without owners. - Act as default owner of resources without owners. - Maintain system/application configuration for data import and provisioning. |
| Resource Owner | Responsible for/ owner of specific resources/permissions. Criteria: The primary and alternate owner of one or more resources and resource folder owner. | - Approve access requests to owned resources that are made by anyone in the enterprise. - Transfer ownership of owned resources. - Assign alternate resource owners. - Attest current assignments of resources (re-attestation). - Update the metadata on owned resources. - Attest the metadata on owned resources. - Terminate owned resources. |
| Identity & Access Manager (Operations Administrator) | Operations | - Have read access to all data, including master data such as properties, and more. - Terminate and reassign processes. - Track process status. |
| Identity & Access Manager (Data Administrator) | Administer Master data in the Omada Identity portal (such as role types, role folders, and more). | - Create, update, and delete resources, resource folders, Org. Units, and more. - Have read access to all metadata such as properties and data object types, as well as users and user groups. |
| CISO (Security officer) or Risk Manager | N/A | Approve toxic SoD conflicts. |
| Auditors (internal/external) | Identities inspecting assigned resources and permissions. | - Have read access to all data, including Master data such as properties. - Have access to audit reports. - Download data contained in views available to auditors. Note: By default, menu items are not available to Auditors. |
| System Administrator | Creates and modifies Omada Identity portal configuration, including views, user groups and security. | - Change the metadata of the system (properties, data object types, and others). - Maintain users and user groups. - Maintain system wide view definitions. - Maintain process templates. - Have read access to all master data (data objects) such as resources. Note: Only System administrators and Platform administrators can modify the security setup of the system. |
| Platform Administrator | Has elevated permissions for product configuration that's critical for its upgrade and integration. | - Prevent the solution from being reconfigured in a way that would prevent normal operation and upgrade. - View and edit critical types of data objects. - Edit master settings and certain customer settings. - Update the Omada Identity license key. - Whitelist built-in and feature package configuration objects for editing. - Change the members of the Platform Administrators user group. |
| Survey Administrators | Triggers and monitors survey campaigns. | - Start a survey and set the scope. - Inspect questions assigned to a specific assignee. - Monitor survey progress. - Reassign individual questions to another resource owner. - View survey reports. - Close a survey. |
| Administrator of target systems (valid only for manual provisioning) | If manual provisioning is used, the Request interpreter/ Administrator of target systems gets the tickets from Omada Identity. | Process tickets from Omada Identity. |
Time-dependent parameters
Timers and pre/post-validation periods must be configured for each company or organization separately.
Timer parameter
Timers are used for very different use cases and range from periodic imports of data to regular triggering of surveys. Timers must be defined and scheduled for every company according to its needs.
Every 6 months, financial authorities require an attestation of access rights of critical applications. For all other applications, it's every 12 months. When the surveys are set up, the stakeholders trained in these surveys can trigger them with timers.
Pre- and post-validity periods
A pre-validity period is the time when resource assignments exist but are in the disabled state. RoPE takes these assignments into the calculations and the calculated resource assignments are shown in reports and dashboards. This is for onboarding identities whereby someone starts at a predefined date, but the preparation starts earlier.
A post-validity period is a period after the Valid to date has been reached. When this happens, RoPE takes these assignments into the calculations and the calculated resource assignments are shown in reports and dashboards. During this time the assignment is in the disabled state.
| Parameter | Sample values |
|---|---|
| Pre-Validity | 3 days |
| Post-Validity | - 30 days for AD and LDAP accounts. - 3 days for other Resource Types. |
For more information about the validity period, see: RoPE Pre- and Post-validity.
Event-based workflow control
Events trigger actions in Omada Identity based on the following criteria:
- The change of a status of an object like an identity, a role or a context.
- A timer.
- The creation or deletion of an object such as an identity.
Actions triggered are part of the event-based workflow capability of Omada Identity, and are typically notifications, escalations or the start of processes or surveys.
For the creation of events, Omada Identity offers template-based functionality. The following screenshot shows an example (triggering the onboard process when a new ID object is created).
Escalation in workflows
The standard mechanism for escalation in IGA processes runs as follows:
Prerequisites
Ensure you have configured an automated escalation, deadline or time limit for a process or a process step.
Escalation
X days before a time limit's reached – and as a reminder – an event first triggers a notification message for the responsible stakeholder. If this notification has no effect, Omada Identity moves the tasks in question to the next level in the hierarchy. This takes place Y days after the deadline. The X and Y values must be defined, as they may differ in each company.
It's recommended to observe the processes and behavior of the stakeholder and adjust the values periodically.
Escalation in surveys
When surveys are created, escalation can be included as part of the survey. To do this, the survey template has a Workflow tab where escalation can be defined by timers and events.
The following screenshot shows a new survey template:
The Survey Administrator can also execute another form of escalation. As the Administrator sees the progress of the reports in a dashboard, they can reassign tasks if necessary. The escalation is then a combination of the information in the Surveys dashboard and the decision taken by the Survey owner executing their governance role.