profiq just announeced strategic partnership with ForgeRock for system integration of open-source and standard-based Access and Identity Management (IAM) products. This is a fundamental milestone in fulfilling profiq’s system integration and system testing strategy. We have spent the last 8+ years with deploying and testing ForgeRock products and their predecessors and looking forward to offering an extended service to customers in the Czech Republic, Slovakia and Hungary with ForgeRock.
A Realm is an OpenAM concept and a feature which is used to group and organise the information and configuration parameters. OpenAM has a top level realm which contains all other, user-defined, realms. We will try here to demonstrate the realm functionality on a simple but practical scenario where realms will be used to separate administration entities.
Let’s imagine a hypothetical service provider company (Example.com) which has a centralised directory for all of it’s clients, and a separate branch per client:
- suffix: dc=example,dc=com
- Client1: o=client1,dc=example,dc=com
- Client2: o=client2,dc=example,dc=com
Example.com would like to employ OpenAM for access management (authentication and authorisation) in a way that users from the client companies cannot access each other’s resources. This functionality can be easily achieved by the Realms feature such that each client company has it’s own sub-realm. Below we’ll explain the detailed setup procedure.
Although my use case for certificate based authentication is pretty basic, the existing documentation for Access Manager/OpenSSO/OpenAM is somewhat scarce and requires gathering information from various, often unrelated sources. For that reason, I have summarised the process in this article.
This is the first article in the series where we would like to focus on the integration of Red Hat Certificate System (RHCS) and ForgeRock OpenDJ.
We will start with the simplest use case – using OpenDJ as a publishing directory for RHCS Certificate Authority (CA). When you are running a Certificate Authority, the certificates have to be published typically in a LDAP directory which stores user information. The scenario would be:
- the company has a corporate LDAP directory running on OpenDJ which stores the information about the employee and client identity (and has to associate it respective user accounts with their digital certificates);
- RHCS is introduced to manage (and publish) digital certificates for the existing accounts.
In my previous articles  and  I explained how to install simple OpenAM architecture. Now I wrote one more article related to this architecture. This article provides detailed steps how to do an upgrade of this architecture from OpenAM 9.0 to OpenAM 9.5.4.
In my previous article “How to deploy OpenAM with DAUI” I wrote down steps how to install complete architecture where DAUI is configured with OpenAM. To keep it simple, I used only plain non-encrypted communication between individual components, however in the real world, many deployments require some more security and encrypted cryptography is a basic requirement. This article is based on previous one and it adds steps to install full architecture with SSL encryption.
Internet is full of tutorials and steps how to install and configure individual tools, but sometimes there are required steps to connect these tutorials together. Sure, there are some deployment guides for complex architectures, but they are typically very complex. The goal of this article is to provide complete, but simple steps how to install and configure ForgeRock’s OpenAM access manager and DAUI (Distributed Authentication User Interface) for authentication. This solution uses also ForgeRock’s OpenDJ directory server as configuration and user data store.