Concepts

Overview

It is necessary for users to become familiarized with the concepts used throughout the OpenIAM platform. These are described below.

User versus identity

A distinction must be made between the concept of a user versus an identity. In the context of OpenIAM user lifecycle management, they are not synonymous. Understanding this difference is critical to understanding the OpenIAM platform and navigating the UI.

• User. Represents a person such as an employee, contractor, customer, etc.
• Identity. Accounts that users have in services and applications are called identities in OpenIAM. There will be numerous identities belonging to the user that reside in multiple systems. Users can have multiple identities within a system, such as an administrator account, a user account or a service account. Identities do not need to have the same name (e.g., barbara.ramirez, _bramirez) as they are linked to the same user.

For example, Barbara Ramirez is an HR Specialist for a corporation that has implemented OpenIAM. She is a user. Barbara has a user account in Active Directory, admin and user accounts in BambooHR and a user account in Office 365. These accounts are known as identities within OpenIAM.

A user profile is a picture of all the related identities in a system. The diagram below gives a view of the relationship between the user and their identities.

Provisioning

Provisioning refers to the creation of identities in target applications. (For the distinction between users and identities, please refer to the section “User versus identity” above.) Throughout the user lifecycle, OpenIAM will evaluate the assigned entitlements of a user (such as groups and roles) and provision identities into the systems that correspond to those permissions. The type of account created in the target application will also be determined by the entitlements the user is assigned.

For provisioning to be enabled, a connector must be deployed between OpenIAM and the target application, and an active connection between both systems must be established. In OpenIAM, user information (such as name, position, employee ID, etc.) is mapped to objects. When provisioning commences, the user data is pushed through the connector to the target application to create the identity/account.

Conversely, deprovisioning refers to the termination of an identity from a target application.

Knowledge of provisioning is requisite to gaining an understanding of synchronization which is described below.

Provisioning status versus identity status

There are two status levels in OpenIAM: one at the user level and one at the identity level. Identity-level operations include values like 'locked.' Operations such as 'disabled,' 'active,' and 'terminate,' which occur at the user level, do not reflect on the UI at the identity level. However, those messages would be pushed to the target system.

Therefore, when discussing statuses in detail, there is the provision status of identity (the last status pushed to the target system), reflecting the identity status. Additionally, there is the status of identity in IAM, indicating whether the identity is used during provisioning or not.

Synchronization

The process of importing user information from a source system into OpenIAM and then provisioning identities into downstream target systems according to user entitlements is known as synchronization. During synchronization, user information (such as name, position, employee ID, etc.) is queried from an authoritative source (such as an HR system), and then mapped to objects in OpenIAM. Business logic, such as birthright rules, are applied to these objects to evaluate the access the user should have to determine the types of accounts to be created and the target systems the identities should be provisioned into. Based on this data, identities may be deprovisioned as well.

Let’s use a new hire for an example. An organization that has OpenIAM deployed is using BambooHR as an authoritative source, and there is an active connection between both systems. The organization is using ServiceNow for its help desk personnel and Office 365 companywide. During synchronization, OpenIAM detects there is a new user in the HR system named Bill Andrews with the job title of help desk technician. Bill’s information is imported, and a new user is created in OpenIAM. The birthright rules engine evaluates his job title which initiates the provisioning of identities into Office 365 and ServiceNow so that Bill has access to the help desk software he needs for his position.

Reconciliation

While synchronization involves a one-way transfer of information from the source system to the IDM, reconciliation is a bi-directional process where data that resides in a target system and in OpenIAM is compared for differences. If differences are detected, reconciliation rules set by the organization ensure that OpenIAM takes corrective action so that the data in both systems match. This operation addresses the issue of maintaining integrity if changes are made to a target system outside of OpenIAM.

As an example, let's suppose an organization wants to compare a population of users in Active Directory and in OpenIAM. Prior to running the reconciliation operation, they would specify a user attribute for both systems (sAMAccountName) to find a match. Additionally, they will set a reconciliation rule that determines if a user exists in the target system that does not exist in OpenIAM, the user would be automatically created in the latter. When the reconciliation operation is run, it is detected that there has been a user added to Active Directory that does not exist in OpenIAM. Because of the reconciliation rule that was set earlier, a new user is created in OpenIAM to ensure that the data in both systems match.

Connector

A connector, as the name implies, is a module that establishes a connection between OpenIAM and an application such as an HR system, Active Directory or Google Suite. An active connection allows for the flow of data between both systems to enable operations such as synchronization, password reset, reconciliation and CRUD operations for users and entitlements. All interactions with applications are performed through connectors.

Deploying and registering a connector is integral to application onboarding.

Managed system

While a connector enables communication between OpenIAM and an application, a managed system is a configuration which directs the connector to talk to a specific instance of that application. Once configured, the managed system will provide settings that instruct a connector on how to connect to an instance of an application (such as host URL and login credentials), and which attributes in that instance should be updated as well as the rules for each attribute. Multiple managed systems can be configured per connector.

To illustrate this further, let’s assume an organization has OpenIAM deployed and has three Active Directory domains that it needs to manage. After deploying a single AD PowerShell connector, three managed systems would be configured to allow the connector to link each AD domain to enable a flow of data between the systems. Similarly, one LDAP connector could be used to talk to several different directories by having a managed system associated with each directory. Thus, a one-to-many relationship between the connector and managed system can exist. Managed systems enable synchronization and reconciliation operations between OpenIAM and multiple instances of an application.

Content provider

When configuring OpenIAM for the first time, administrators will be prompted to define a content provider. A content provider should be regarded as an alias for a domain, such as idm.companyname.com. The following are linked to the content provider:

• Authentication policy. This configuration determines whether OpenIAM functions as an identity provider (IdP) or a service provider (SP).
• Branding. This includes logos and custom CSS themes.
• Protection of URLs. This includes the URLs of OpenIAM as well as those of legacy applications. Legacy application URLs can be configured to support:
  • SSO via the rProxy
  • Enforcement of access control at the URL level via the rProxy
  • Step-up authentication at the URL level

The most common configuration consists of a single content provider that is mapped to the IDM system. However, multiple content providers can be configured to support different user populations that will be interacting with OpenIAM. For example, let’s suppose an organization needs to support employees and customers but both groups require different authentication processes: employees would need to sign in using Azure as their corporate IdP while customers would authenticate using OpenIAM as the IdP. For this set of criteria, we would do the following:

• Configure a domain for employees, such as employees.companyname.com, and a corresponding content provider. The content provider would then be linked to an authentication provider that mandates user to log in using Azure as the identity provider. Upon successful authentication with the IdP, employees are federated into the OpenIAM UI.
• Configure a domain for customers such as customers.companyname.com, and a corresponding content provider. The authentication provider linked to this content provider would require customers to authenticate themselves using OpenIAM as the IdP.