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.
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.
We have previously written about the plugin development for OpenDJ based on the example-plugin.zip which comes with the binary distribution. However, as OpenDJ is evolving and slowly migrating to Maven, on the initiative of the ForgeRock team we have come up with the Maven archetype to make the plugin development easier and more developer friendly. Read more…
Although the integration of OpenDJ with Samba is not explicitly documented, it does exist for OpenDS - which, as we already know, is the same product as OpenDJ. However, what is not covered is the synchronisation for the Samba password attributes with the LDAP password. This is the aspect we would try to cover in this article.