Authorization Center

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.

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.

Self-Service Portal

Users already provisioned can request access to additional systems or extensions of their rights on existing systems in the user interface. For this purpose, OpenIAM provides a service catalog from which users can select the desired systems and authorizations.

One interesting feature is the ability to limit the access rights requested in this way, which is particularly useful if an employee only needs temporary access to certain services for a project. The procedure also includes an approval process. If the OK for the request comes from one or more approvers, the software in turn automatically ensures that the user is provisioned to the system and receives the necessary rights. Figure 2 shows the complete provisioning process.

Web Access Manager

In addition to Identity Governance, Web Access Manager is the second integral component within the OpenIAM framework. As the name suggests, this component authorizes users after they have gained access to a system. As well as access controls, it provides other services and features, such as single sign-on, multifactor authentication, and session management and integrates these into Access Management.

One central component of Web Access Manager is single sign-on with federated user identities. In this case, OpenIAM serves as an identity provider and ensures that access to service providers, such as Salesforce or Oracle, takes place transparently for the user through the use of state-of-the-art protocols like OpenID Connect or SAML2. For this purpose, a position of trust between different security domains must be established in the configuration.

In practical terms, a redirect to the OpenIAM framework occurs when one of these applications is accessed. For example, the user authenticates against OpenIAM with OAuth 2.0 and, if successful, is issued a JSON web token (JWT) that then serves as an ID token to log on to the service provider. Users can also call an application from a remote security domain directly from the OpenIAM interface (Figure 3).

The authentication process is completely transparent to users, who can also use the ID token to log on to other systems. Another interesting feature is that OpenIAM provides a reverse proxy for applications that do not support the federation protocols used, which means that legacy applications can also benefit from single sign-on.

Testing OpenIAM

If you are interested in trying out OpenIAM, you have two possibilities: the Community and Enterprise versions. The Community version is available for free download on the OpenIAM website [4]. The Enterprise Edition offers two subscription models that provide access to additional resources and support beyond the software itself. The current 4.2.0.1 version (at press time) supports Red Hat Enterprise Linux 8 and CentOS 8, but earlier versions of the RPM package before 4.1.6 only run on Red Hat Enterprise Linux 7 or CentOS 7.

It is somewhat unusual that the RPM only packages the OpenIAM sources as a tarball, which it then simply unpacks under /usr/local/OpenIAM/ when installing the package. But at least the package makes sure that these files disappear when you uninstall the software. As an alternative to installing the RPM file, you can also obtain a container image of the software and then run it with a container runtime. Only Docker is officially supported, but the container image should work with the Podman runtime without any problems; I did not try this out when writing this article.

Conclusions

OpenIAM is an extremely complex and comprehensive piece of software for the management of user identities and access rights. The tool supports all requirements that companies have for a modern IAM tool. Thanks to SOA (Special Operations Associates) security and the numerous APIs that the software provides, it is easy to adapt or extend it to your own needs.

The integrated Groovy scripting language lets you create scripts that synchronize users from a source system to any target system with flexible mapping of user attributes. Together with single sign-on support, OpenIAM also acts as an identity provider and combines this with sophisticated access management. The feature scope naturally requires a certain amount of training; however, the effort will certainly pay off in later operation. After all, OpenIAM helps you automate almost all operations for identity and access management.