Skip to main content
Version: Cloud

Omada Identity Platform

The Identity Governance and Administration (IGA) processes consist of:

  1. Master identity data, which must be imported to enable the IGA processes. There are different connectors to connect to HR systems such as SAP Human Capital Management (HCM) and others.
  2. The objects to be requested in the request workflows must be imported by the Onboarding applications process. The data (systems, accounts, resources) is imported into the data warehouse.
  3. Most IGA processes are managed by the Enterprise Server module.
  4. The Role and Policy Engine (RoPE) calculates assignments considering rules for implicit assignments (defined by automated rules, not explicit requests) or SoD rules.
  5. The Omada Provisioning Service (OPS) module provides the provisioning data for the target systems either directly to a target system through provisioning (an automated process) or triggers a ticket for an administrator for manual provisioning.

The processes are reflected in the Omada Identity reference architecture build, which is made up of the following components:

  • Omada Data Warehouse (ODW)
  • Omada Enterprise Server
  • Omada Identity Role and Policy Engine (RoPE)
  • Omada Provisioning Service (OPS)

Table 1: Omada Identity data flow description

  1. ODW imports identities and contexts from one or more identity sources (for example, an HR system). Protocol and port : Depend on the HR system.

  2. ODW imports data (such as systems, accounts, resources) from connected systems.

  3. ODW exports data such as identities, contexts, ownerships, systems, accounts, and resources to Enterprise Server.

    ODW imports actual state data for applications and Enterprise Roles from Enterprise Server. ODW can also import other data, for example, contractor identities that originate in Enterprise Server.

    Protocol and port : SOAP Web Service over HTTP/HTTPS. The port is configurable, but default is 80/443.

  4. Enterprise Server reads data from ODW for use in Surveys and in the application onboarding processes. Enterprise Server writes survey results from the account ownership survey to ODW. Protocol and port : ADO.NET connection to MS SQL Server. The port is dependent on configuration of the SQL Server.

  5. Enterprise Server reads data from RoPE to display calculated resource assignments and calculation results data in the Omada Identity Portal. Protocol and port : ADO.NET connection to MS SQL Server. The port is dependent on configuration of the SQL Server.

  6. RoPE reads data from Enterprise Server to determine the Desired state of resource assignments. The data includes:

    • Resource assignment objects (for example, created in the Access request process)

    • Assignment policies

    • Segregation of Duties (SoD) policies

    • Verdicts from surveys

    • Violation evaluations.

    RoPE reads provisioning claims from Enterprise Server for manually-provisioned systems. RoPE reads data from Enterprise Server to determine which identities to add to the calculation queue. Protocol and port : ADO.NET connection to MS SQL Server. The port is dependent on configuration of the SQL Server.

  7. RoPE reads Actual State data from ODW in the calculation of identities and to determine the compliance status. Protocol and port : ADO.NET connection to MS SQL Server. The port is dependent on configuration of the SQL Server.

  8. ODW imports survey results and compliance status from RoPE. Protocol and port : ADO.NET connection to MS SQL Server. The port is dependent on configuration of the SQL Server.

  9. RoPE writes provisioning tasks to OPS. Protocol and port : WCF Web service call. The port is configurable, but default is 8000.

  10. OPS provisions and deprovisions to connected systems. Protocol and port : Depend on the connected systems.

  11. OPS writes provisioning claims for successful provisioning jobs to Enterprise Server. Protocol and port : SOAP Web Service over HTTP/HTTPS. The port is configurable, but default is 80/443.

  12. Enterprise Server reads data from OPS to display provisioning status and other data in the Omada Identity Portal. Protocol and port: WCF Web service call. The port is configurable, but the default is 8000.

  13. The CIAM portal reads and writes data from/to the Enterprise Server. For example, writing of sign-up requests or reading identity Master Data. Protocol and port : REST/JSON Web service call over HTTP/HTTPS. Port is configurable, but default is 80/443.

Lifecycle management to prove compliance​

In Omada Identity, there are several mechanisms to manage and link identities and resource assignments. These mechanisms make up the overall control process to ensure compliance.

Desired state and actual state​

In the overall concept of creating the resource assignment for identities, the ODW serves as an Actual state repository, while the Enterprise Server serves as the Master Data repository for the Desired state with management and compliance workflows accessed through the Omada Identity Portal.

Creation of the desired state workflow​

  • Data from HR, AD, or other systems is loaded into the ODW.
  • Data is imported to Enterprise Server from the ODW. This data is then used in the IGA request and approval processes.
  • RoPE calculates Calculated Resource Assignments (CRAs) for identities and determines the compliance status for each assignment.
  • Contractors originate from the Enterprise Server and are imported into ODW from the Enterprise Server.
  • Application assignments are imported from the Enterprise Server.

Creation of the Actual state workflow

When systems are managed by the Omada Provisioning Service (OPS), the Role and Policy Engine (RoPE) creates provisioning tasks to provision the Desired state.

  • If OPS writes directly to the target systems, data provisioning is performed automatically. If possible, the administrator of the relevant target system doesn't have the right to grant access rights. These tasks create the Actual state data.
  • If OPS creates a manual task for an administrator, provisioning is performed manually. These tasks create the Actual state data.

In many companies or organizations, to ensure that there are no discrepancies, it's necessary that a periodic comparison of the Desired state against the Actual state is carried out. For example:

  • In the Desired state , what does Omada Identity contain as approved accesses to resources for identities, compared to the Actual state?
  • What do the target systems allow an identity to do (what is in the system)?

This is the case if Omada Identity submits a provisioning ticket (through Manual provisioning) to an administrator who, in turn, performs a manual action to provision an access right.

important

When performing Manual provisioning, the possibility for mistakes can increase, and in a worst-case scenario, a system administrator has sufficient rights to manipulate accesses.

When this occurs, the as-is data is periodically brought to Omada Identity (for example, through OPS), and then Omada Identity checks for data inconsistencies.

Any irregularities are then displayed in the Omada Identity Dashboard so that actions such as new provisioning can be started.

Surveys​

In Omada Identity, the surveys allow managers to review and provide attestations for their users’ access rights to information, applications, and other resources contained within IT systems. In a survey, respondents receive survey questions as work items that they must answer through the My work items view.

It helps organizations manage user-access rights in compliance with government regulatory laws, industry-specific standards, internal security requirements, and SoD policies. Omada Identity automatically starts the recalculation of resource assignments and eventual deprovisioning tasks.

Even when Desired state and Actual state match, the control process is not complete.Decisions that have been made previously – such as approvals – must still be verified as being true. Surveys address the following questions that are considered crucial when referring to compliance:

  • Is an identity still entitled to have the resource assignments it has or should some of them be revoked?
  • Are assignment rules still valid?
  • Is the role definition or model still valid?

Omada Identity Governance​

Omada Identity is used to manage and govern external systems to achieve compliance and reduce risk by being in control of the access rights.

It is equally important to manage the internal access rights within the IGA system itself, e.g. manage the accounts, permissions, and resource assignments that manages what access, users have in Omada Identity. As an example, System Administrators have extended access rights to change the configuration settings within the IGA system and can affect who gains access to both Omada Identity and other connected systems. It is therefore imperative that there is full control over the access rights within Omada Identity itself.

In Omada Identity this is achieved by treating the Omada Identity system as a managed system on par with other connected systems. This allows you to manage the Omada Identity Users, and User Groups according to best-practice. This includes:

  • Review and audit access through historical reports, including the decision log.
  • Control how to provision users including setting the language and time zone settings.
  • Assign access through roles and policies.
  • Detect Not approved assignments for manually assign user group memberships.
  • Enable “Exclusive managed” resource types to automatically deprovision assignments without a desired state.
  • Recertify assignments through Access review surveys.
  • Assign ownership to orphaned accounts.
  • Enable multiple account types to separate privileged access (e.g. administrator user groups) from personal user accounts.

Assignment Model​

Roles must be managed throughout their lifecycle, allowing companies/organizations to introduce, modify, and terminate them.

Defining a model for roles​

The assignment model covers all aspects of assigning a role permission to an identity, for example:

  • Obtaining objects from target systems and mapping them to the Omada Identity-intrinsic role definition or modeling.
  • Building a business-suitable role model or definition in Omada Identity to ensure users know what to apply for, and for managers to know what they’re approving or rejecting. The objects coming from the target systems can often be ambiguous or difficult to understand, and, in consequence, difficult for the organization or company to understand.

When establishing a model for managing access, there are typically two major perspectives to keep in mind. The resource perspective versus the business context perspective.

The resource perspective (Application roles) : What does this give access to? What is the risk associated with having access to this resource? Who have access to this resource?

  • Typical tasks: Resource owner approval/access review. Naming, describing, and classifying resources. Define segregation of duties requirements.
  • Typical responsibilities for the resource owner in the role model: Owner of application roles. Preparing resources for entering into business roles like organizational and job function roles. Approving that owned resources (application roles) can be utilized (become a child) in business roles.

The business context perspective (Business roles) : In what business context should people have access to this collection of resources. Is there a business need / work- related need for access to the resource? What resources does my employees have/need?

  • Typical tasks: Manager approval/access review. Assigns job function roles to new hirers.
  • Typical responsibilities in the role model: Owner of organizational and job function roles.
note

The terms Enterprise roles and Business roles are interchangeable in this context.

Mapping target system object to Omada Identity roles​

The raw data from the target systems are not suitable to be used directly in access request processes. The main reasons why the raw permissions from target systems should not be directly requestable are:

  • Not everything is relevant for request.
  • Ownership should be established.
  • Ensuring classification on all requestable resources (applying a risk-based approach).
  • The description and naming of the objects are often not business-friendly and difficult to understand and therefore not easy for end-users and managers to understand.
  • Without a mapping to an application, the level of granularity can lead to a list with thousands of entries to choose from. This list makes it difficult for users to choose what they need, too many questions in approval and survey processes, which in turn leads to compliance issues.

The resource owner is accountable for specifying the required protection of the resource, e.g., classification, approval levels, SoD, recertification cycle, etc. They are also accountable for ensuring that the name and the description is reflecting what access is granted in a clear and understandable language by the consumers (beneficiaries, approvers, and access ordering parties) of the resource.

In Omada Identity, everything that can be requested is a resource. There are distinct resource type categories. The three main categories are:

  • account
  • permission
  • role

It is considered best practice to perform a 1:1 (one-to-one) mapping of an imported permission resource to an Omada Identity Application role. Application roles can also contain other application roles, to support a situation where the system permissions contained in the Application roles are interdependent and must be granted together in the target system. In this case, the application role is still considered a part of the resource perspective as opposed to the business perspective.

We do not recommend that multiple permissions are placed within one application role if these are also modeled as a 1:1 application role. This would cause multiple implicit assignments for the same resources, which is not desired.

note

An application role is an Omada Identity resource, where the resource type on the resource has the category “role” and the resource type is named “Application role”. When the resource type on the resource has the category role, then the resource can have child resources and inheritance is calculated.

Applications and Application roles allows for a business-friendly logical layer and at the same time to disable self-service access request directly on all permission resources. This way any newly imported permission will not be requestable before it is onboarded to an application role and owner, name, description, and classification is ensured.

Permission, application role and Enterprise role​

Omada Identity provides a model to define a hierarchy of roles using inheritance. This allows the definition of comprehensive business roles which can be understood by both the requesters and the approvers in a business context.

note

A business role is an Omada Identity resource, where the resource type on the resource has the category role and the resource type is named Business role or Enterprise role. The terms enterprise role and business role are in this case interchangeable.

Business roles have a people and organizational perspective versus application roles that have a resource perspective. Application roles considers what is being protected/granted and the business role considers in what business context a collection of application roles should be granted (e.g. an org unit, a job etc.).

When using business roles, the number of requests, approvals and questions are reduced as a process/question does not have to be processed for every single contained application role. This means that efficiency is realized with business roles, even without assigning them with an assignment policy.

System permissions represents the access control models in the IT-systems. Application roles belongs to Applications and are constructed by collections of System permissions and potentially other Application roles. Application roles are represented by the Special Layer in the Conceptual Role Model. Business roles consists of collections of Application roles. Business roles are designed and arranged after the principles of the Conceptual Role Model described in the Enterprise Role Model section below.

Build a business-suitable model for roles​

The Enterprise role model defines the four layers of roles and the purpose of each layer in the role model. An identity’s (typical a person) access rights are often represented by assignments to several business roles or application roles distributed over several layers in the role model.

The following are the different layers of the enterprise role model:

Basic Layer
The purpose of the basic layer is to give identities (typically a person) the very basic roles and authorizations needed to have an IT workplace. The content of the base layer is automatically assigned through assignment policies based on basic data about identities (e.g., type). Therefore, the base layer must contain only application roles that apply all identities of same basic type (e.g., Employee/Contractor, and such) and proper master data must be assigned. It is considered best practice to not allow the basic layer to contain classified (e.g., business-critical, privileged) application roles. The content of the basic layer is typically owned and maintained by the IGA Team.

Organizational Layer
The purpose of this layer is to give identities the access necessary to perform tasks specific for their area of the organization. The organization layer content is typically automatically assigned through assignment policies based on basic data about identities and their relationships to the organization. Therefore, it is recommended that the organizational layer only contain application roles with access to, for example, distribution lists and area drives. It is considered best practice to not allow it to contain classified (e.g., business-critical, privileged) application roles. Depending on the need, the organizational layer can be assigned specifically for one organizational unit or assigned as a result of inheritance (hierarchical structure). If inheritance is used, the assignment policy must be defined at the highest relevant level. The content of the organization layer is typically owned and maintained by the Head of department.

Functional Layer
The purpose of this layer is to give identities access to business-oriented job functional roles (business roles). Functional roles are typically assigned on access request with proper approval. It is considered best practice to not allow the functional layer to contain high-risk (e.g., privileged) application roles. Functional roles are normally owned by the manager responsible for the function.

Special Layer

The purpose of the special layer is to provide the opportunity to obtain individual application roles that do not necessarily belong to all identities in a job function.

The special layer is allowed to contain application roles classified as business-critical and privileged. Application roles are assigned after access request and proper approval. For application roles that requires application role owner approval at the time of assigning (vs. time of including the application role in business roles), the application role should not be included in business roles and instead kept only in the special layer as a standalone application role.

Improving efficiency is pursued by using automatic calculation of assignments of business roles on the basic and organizational layers i.e., without explicit request and approval processes. Assignment of business-critical business roles in the functional and special layers are only fulfilled based on appropriate explicit approval processes (workflow).

Each role in the hierarchy has an owner. An approval process for the role itself is provided by a two-step standard survey process. In the first step, the owner of the role approves the role definition, e.g., name, description, and content. In the second step, each owner of the contained child application roles approves that their owned application role is allowed in the business role.

Furthermore, surveys can be initiated to manage the classification of application roles and verify the assignments to business and application roles. As a result, the lifecycle of roles is covered.

Application onboarding concept

Application onboarding is the process where application roles are created. Application roles can be created or onboarded in different ways - in the Onboard application process, manually via forms in the Omada Identity UI, or via data import through a Data Exchange or OData integration. The process is the same in all cases, but the method differs.

  1. Create the application.
  2. Create application roles.
  3. Verify the data.

The Application onboarding chapter in this document describes how to onboard application roles using the Onboard application process template in Omada Identity. The Application Onboarding Feature Guide contains additional information on how to create the required prerequisites and how to onboard roles manually via forms.