Managing user identities decentrally and manually directly within applications is not only error-prone, it also takes up valuable time and involves administrative overhead. Storing users and their access authorizations for certain systems and applications in a central location makes sense, especially in hybrid environments, where applications exist both on-premises and in various clouds.

Identity and access management (IAM) tools typically provide a number of functions to facilitate this work. Not only does the software provide user lifecycle and access management, it needs to offer other features, such as a self-service portal for resetting user passwords or for additional authorization requests. A single sign-on based on modern protocols such as OpenID Connect or Security Assertion Markup Language 2.0 (SAML2) should also be part of the standard scope. Flexible auditing is necessary to implement compliance requirements for a centralized system of this type, and SAML2 will certainly become interesting for increasing numbers of businesses in the light of data protection regulations (e.g., the European Union's General Data Protection Regulation, GDPR).

Although the vast majority of IAM products support these requirements, they present no uniform implementation approach in practical terms. OpenIAM [1] is a fully integrated platform that manages user identities and access rights, supporting all requirements companies need in a modern IAM tool.

Microservice-Based Architecture

OpenIAM essentially comprises two components: Identity Governance and the Access Manager. To fulfill its task, the software relies completely on a service-oriented architecture (SOA) and uses an enterprise service bus (ESB) for communication between the individual services. To map these two core components of the software, the tool provides more than 20 different services in the service layer that communicate with the help of the ESB. Figure 1 shows the schematic structure of the individual layers and their components.

Figure 1: OpenIAM provides its services in different layers.

Users usually access OpenIAM from a graphical interface. The user interface allows access to both the self-service portal and administrative tools. For access to enterprise applications, OpenIAM also acts as an identity provider (IdP). As usual, the interface can be adapted to reflect a corporate identity.

A Tomcat server provides the individual services in the service layer. The infrastructure components comprise RabbitMQ for the message bus, Redis as an in-memory cache, and Elasticsearch for all search queries.

Any relational database can run on the backend. OpenIAM offers schema files for MySQL, MariaDB, Microsoft SQL Server, PostgreSQL, and Oracle databases. Notably, the software provides a REST API in addition to the graphical user interface, which allows developers to extend the software according to their own requirements or to link it with external tools.

User Provisioning with Connectors

In a typical IAM use case, as soon as a new employee joins a company, they are given access to all the systems they need for their daily work. Likewise, when an employee leaves the company, access to these systems must be revoked.

OpenIAM solves this task by provisioning or deprovisioning user accounts on the respective systems. The software assumes a single authoritative source in the company that holds all employee data – usually a human resources (HR) system, but in the simplest case it can also be a CSV file, which is very well suited in testing scenarios for becoming familiar with the system.

With the help of connectors, OpenIAM accesses and imports the data into the OpenIAM identity repository. This process takes place during the initial setup of the software until a consistent state exists between the source system from which the data comes and the OpenIAM repository. During operation, constant synchronization between these systems takes place. If, for example, the department in which an employee works changes on the HR system, it is also reflected in OpenIAM. The systems can be synchronized either by regular polling of the source system or triggered by events.

In event-based synchronization, the source system relies on OpenIAM's provisioning API to initiate a quasi real-time sync. The software evaluates the data from the identity repository and decides, on the basis of pre-defined rules, to which systems a user should have access and which rights they should be given on those systems. Rules can be created according to any attributes of a user object. For example, users with the devel role could be given access to all development systems within the company or a department, whereas access to HR systems would be denied to these users.

Rules Assign Attributes

With the help of rules, you also can map attributes between OpenIAM and a target system. For example, if a user from the HR system has been synchronized and has an employee_ID attribute, you will probably want to assign this attribute to the Lightweight Directory Access Protocol (LDAP) employeeNumber attribute when synchronizing with Active Directory or some other directory. Within the software, you create a suitable rule for this purpose, which is then stored as a Groovy script in OpenIAM. You can modify the script at any time with the GUI editor.

When data evaluation is complete, the accounts are provisioned to the target systems. For this purpose, the connectors I mentioned before are again used. To this end, OpenIAM offers a whole range of predefined connectors that enable access to LDAP, Microsoft Office 365, Active Directory, Exchange, Google Suite, SAP enterprise resource planning software, Oracle RDBMS and eBusiness Suite (EBS), Workday, ServiceNow, and Linux systems. You will find a complete list online [2]. If required, you can, of course, adapt these connectors or add new ones.

In OpenIAM, rules define which accounts should be provisioned to which target systems. The system appropriately calls these target systems "managed systems." Again, if a change is made to an account in the OpenIAM repository, it is also reflected in the managed systems.

At this point, note that OpenIAM naturally lets you configure password policies. If a user's password changes within the application – either through the self-service portal or by the actions of an administrator – it must meet the complexity requirements defined in the policy.