See you on our new site,
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.
This article is about setting up ForgeRock’s Open Identity Management with Microsoft Active Directory using standalone .NET Connector Server.
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.
A problem you might face while extending the OpenDJ functionality with a plugin is to develop proper unit tests. OpenDJ comes with a set of tools to facilitate the testing, but since they are tightly integrated within the build framework, you might find it difficult to execute your unit tests from outside of the framework. This article will try to give you short guidelines on how to integrate and execute your tests.