Business alignment

The Business alignment processes concern the business benefits obtained such as cost efficiency and risk management. These benefits are achieved by addressing roles, assignment and constraint policies, as well as the reasons for being in the organization or identities context.

As a result, for the success of any IGA project, and to reach the full potential of Omada Identity, it's important to have a good understanding and modeling of the business, such as the relationship of identities to user accounts, access rights and profiles, as well as business roles and processes and their connection to the organizational structure, as well as other relevant structures, for example, projects.

The following subchapters describe the processes included in the framework: Managing roles, Managing policy, and Managing contexts.

Managing roles

Basic entitlements or roles (also called birth rights) must be administered, allowing companies and organizations to introduce, modify or terminate roles. When a target system resource is not delivered by the source system anymore, a Data Administrator must update in Omada Identity that the resource cannot be requested anymore, and the Resource Status must be set to Obsolete.

Roles

In the Omada Identity Data model there is one Object Data Type resource which is subdivided into the following three resources:

• Account
• Permission
• Enterprise resource

By default, each system has one account resource for the personal account type, and one account resource for the unknown account type. Permission resources represent the target system, such as AD groups, SAP Roles and others. An Enterprise role only exists in Omada Identity and is a compound resource that includes a child Permission resource.

This diagram describes the relation between Enterprise roles, permissions and target system resources:

note

Enterprise roles can have multiple layers, however, out of the box, Omada Identity supports management processes only for one layer.

Out of the box, target system resources are read directly from the target system, and then the corresponding permission resources are created in Omada Identity.

When a target system resource is not delivered by the source system anymore, a Data Administrator must update in Omada Identity that the resource cannot be requested anymore, and the Resource Status must be set to Obsolete.

Creating, modifying and terminating roles

The creation, modification and termination of Enterprise roles in Omada Identity is performed by a Data Administrator through Master Data Management or using the Onboard application process.

Generally, and when not delivered by the target system, each resource in Omada Identity requires appropriate data enrichment for the following information:

• Owner (for Access approval):
  • Requestable in the Access Request process.
• The Resource Folder defining:
  • Manual Provisioner
  • Approval Levels
• The Resource Type defining:
  • Attributes
  • Post-validity
  • Delegation

Managing policy

Policy lifecycle management entails the creation, modification, ongoing maintenance or termination of access rights.

Create, modify, or terminate assignment policy

note

An assignment policy defines that a set of identities must have access to a set of resources.
A view is a concept in Enterprise Server that allows you to define a dynamic list of data, and in turn, identities can be defined by a context and/or a view.

Assignment policies are used in Omada Identity to automate the assignment of access for identities and is one way to establish a desired state for resource assignments. Another way to achieve this is through surveys, or a request process whereby someone approves it, or by creating a policy.

With assignment policies set up, it's easy to implement a role – or an attribute-based access control model – whereby identities are given access based on their context or other attributes.

Using views for the identity scope lets you apply filters to define the identities in scope.

important

Using a view in the identity scope means that there is no automatic queuing for the calculation of the affected identities.

Assignment policies are created and maintained manually in Omada Identity through Master Data Management, which can be performed by Data Administrators.

The table includes descriptions of the properties that apply to creating, modifying or terminating an assignment policy.

Property	Description
Name	Name of the policy, shown in assignment reasons.
Description	A description of the policy.
validFrom	Policy is valid from a specific date. Resources with a date before the valid date are not assigned.
validTo	Policy is valid to/until a specific date. Resources that are past the valid date are not assigned.
Identity filter	A view filtered by the Object Data Type Identity that you can filter. The policy only applies to those Identities.
Contexts	The policy only applies to identities belonging to all referenced contexts. If no context is specified, this filter criteria is ignored.
Resources	All referenced resources are assigned to the identities in scope during the validity period of the policy.
Account types	Policies only apply to the referenced account types.

important

To manage policies more effectively, the organization should have appropriate governance rules in place.

Assignment policies are used in the process of calculating access rights for identities. Consequently, identities that comply to a given set of assignment policies should receive access rights accordingly. Changing assignment policies are going to have an impact on groups of identities and their access profiles.

warning

To avoid breaking changes, implementation partners and consultants should have considerable knowledge of the consequences of making changes to the assignment policies.

To ensure availability of access identities, make sure that potential replacement policies are in place before terminating assignment policies. As terminating assignment policies may result in identities getting their access rights removed, it's recommended that future changes to an identity are communicated.

Create, modify, or terminate constraint policy

The Segregation of Duties (SoD) module allows for a fine-grained definition of constraints, based on a mutually exclusive business process matrix or a mutually exclusive resource matrix. It's possible to evaluate constraints based on resource or identity level.

Business processes allow the association of multiple resources with a business process, for example, allowing for the definition of constraints for a specific job function. This saves from adding constraint rules for every possible resource combination.

Constraints in Omada Identity are created and maintained manually in Omada Identity through Master Data Management, performed by Data Administrators.

Constraint properties

Property	Description
Name	The name of the constraint is shown in the SoD Violation Evaluation process.
Description	A description of the constraint.
Disabled	If you don't enable the constraint, RoPE ignores it.
Policies apply to all identities who are in this scope	A view filtered by Object Data Type identity that can be filtered. The constraint only applies to those identities.
Negate	Negates the identity filter.
Toxic business process combination	Combination of toxic business processes. In the case that only one business process is selected, all resources belonging to the process would be toxic to the identities in scope.
Toxic resource combination	Combination of conflicting access rights that cannot be assigned to the same person.
Attribute scope	Constraint only considered if the assignment shares these attributes.
All attribute values must be equal	Constraint only considered if all attribute values are the same.

Managing contexts

In addition to (or instead of) the organizational structure of the company, the context concept in Omada Identity lets you manage business contexts, which represent the relationship an identity has with the organization.

A user can be assigned to a predefined business context, or they can be created, modified or terminated, as well as prolonged or removed altogether.

Create, modify, or terminate a context

Regarding contexts, you can manage a project’s hierarchy, location, job function or work collaboration. For example, the location of the organization can be considered a context, such as the Chicago branch of it. You can also create your own data object and use it as context. Each context can have one or more owners, who in turn have the responsibility of managing those who are assigned to the context.

Identities who are assigned to a context can request access to be used while performing specific duties. Once an identity is no longer assigned to a context, the system automatically revokes the access granted.

Some of the business benefits include:

• The ability to manage other business contexts in addition to the organizational structure.
• Self-service requests for access rights to be used in a specific context with the subsequent approval of the Context Owner.
• Automatic revocation of granted access rights for use in a context when an identity is no longer assigned to it. This is due to the identity’s context assignment being expired or otherwise removed, or because the context itself has a validity period and its end date has been reached. For example, this can happen at the end of a project.

All identities must specify a primary context type, and a context assignment to a context of this type. An identity’s primary context type is normally specified on the identity object but can also be set for all identities in an Enterprise Server custom setting.

The primary context type for identities is often the OU, which is the default context type in the standard application.

In Omada Identity, context types are manually created and maintained through Master Data Management and performed by Data Administrators.

Organization Units Properties

Properties	Description
Name	Name of the context type.
Object Type	The system name of the Object Data Type that represents the contexts.
Parent property	If the context type is a hierarchy, the property with a reference to the parent context.
Owner property	The system name of a reference property on the Object Data Type that's used to specify the Context Owners.
Delegated owner property	The system name of a reference property on the Object Data Type that's used to specify the delegated Context Owners. This property is optional.
Supervisor property	The system name of a reference property on the identity Object Data Type that's used to specify the identity's supervisor in the context. This property is optional.
Membership property	The system name of a reference property on the identity Object Data Type that's used to specify the context(s) of the specific type that the identity is a member of. This property is optional.

Context Data is typically created in Omada Identity after a data import from an authoritative source. This data can also be maintained within the Omada Identity portal by creating a view. Context Data can also be created directly in Omada Identity through Data Exchanges, which is performed by System Administrators or manually through Master Data Management performed by Data Administrators.

Request and approve a context assignment

An identity can explicitly request to become assigned to a context. After approval from a Context Owner, the identity is assigned to the requested context.

Direct context assignments are created through the Create a new context process. Context Owners can also add them when they edit the context objects.

You can specify a membership property for contexts that create context assignments, based on a reference between an identity and a context, instead of direct context assignments.

There are 3 ways to become a member of a context:

1. Through a membership property, for example, an identity has a reference to an OU through the OUREF property, which is specified as Membership property on the Context Type.
2. Through Master Data Management as Context Owner. The Context Owner opens an owned context and can add additional identities to their context.
3. As described in the Request and approve a context assignment process, the identity requests business context membership, and after the approval of a Context Owner, the identity is assigned to the context.

Stakeholder(s) in the process

• The requester
• The approver(s) or Context Owner

Pre-conditions

• Context Type must be registered.
• Context Data must be loaded, and ownership must be defined.

Post-conditions

• Request to join a Business Context is approved by a Context Owner.
• A Context Assignment is created.
• An identity can select an assigned context through the Access request process.

Data objects

• Identity of the Requester
• Identity of the Approver
• Context Assignment

Process flow

1. Any identity with an active user in Omada Identity can start the Join a business context process.
2. The Requester can select context membership for them or other managed or owned identities through the Request membership process.
3. The Requester must specify the context to become a member of it and specify a reason for the request. For example, a context can be a department, project, cost center, building, etc.
4. The Context Owner must approve or reject the request.
5. Once approved, the system creates a Context Assignment object.

The process flow is also illustrated on this diagram:

Best Practices, considerations and recommendations

• Requesting and receiving membership of a context implies that, due to the context membership (reason), the identities get more access rights.
• Relationships (context) can be considered as a reason for requesting and granting access, therefore it should be part of the request process and approved by the responsible person(s). Essentially, this reason for request can be interpreted as: "the user gets access in the context of ______".

Prolonging or removing a context assignment

Context assignments are modified/deleted in Master Data Management by Context Owners or Data Administrators.

From the Context Assignments page, a Data Administrator can open views for different available context types and maintain the validity. Only the Data Administrator can delete context assignments.

On a specific context you can create, maintain, or delete a context assignment.