Archive
Using Oracle DB as OpenIDM’s repository
This article is dedicated to setting up OpenIDM with Oracle DB as repository. As of the OpenIDM 2.1 Xpress release, that has been used for the purpose of this blog, OpenIDM does not yet supports Oracle DB as an internal repository, but below in the article I’m providing procedure that could help reader to setup OpenIDM with Oracle DB for successful operation.This article is dedicated to setting up OpenIDM with Oracle DB as repository.
Read more…
OpenIDM: Using MS SQL as internal repository
As of the newest builds of OpenIDM 2.1.0 Xpress, among the others, a capability to use a MS SQL as internal repository has been added. Following lines will describe how you can set up Microsoft’s SQL database as OpenIDM’s internal repository.
Partnering with ForgeRock to deliver Open Identity and Access Management Solutions
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.
Connecting OpenIdM with Microsoft Active Directory – How to set it up!
This article is about setting up ForgeRock’s Open Identity Management with Microsoft Active Directory using standalone .NET Connector Server.
OpenAM Session Upgrade: Overview
SSO authentication introduces some technical challenges besides providing obvious benefits. Imagine for example that you need to assign different types or levels of authentication to different resources or different actions within a domain. E.g. you allow users to view information, if they successfully authenticate using user name and password, while you may require them to insert a special security code besides user name and password, if they want to start editing. Or you allow users to access general content using user name and password, while accessing specific content (e.g. admin content) needs a security certificate.
Now, what if the user is logged-in with one level or type of authentication, while she attempts to access a resource that requires a different level or type of authentication? Will she be asked to log-in again? What happens to the SSO session technically in such cases?
Knowing your subject
This article follows-up with the series of articles about tackling test complexity, adding a view on the importance of product knowledge, when coping with the complexity of testing. Let’s assume that you understand already, who your customers are;)
I managed testing of a large integrated suite of software products on one of my past projects. Each product had its years of individual history already, when the decision was made to release them as a suite. And each of them was quite complex on its own, even without considering integration with other products. The number of installation issues reported by customers started increasing to an unacceptable level after a couple of years of the products suite’s existence. The whole engineering organization became concerned about the issue. First hypotheses about the cause assumed that the released installer was defective or that the product documentation was unclear. These were not proven however. So, we decided to conduct a profound root-cause analysis.
A simple OpenAM realm scenario
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.
Certificate based authentication with OpenAM 10 and Tomcat 7
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.
Using OpenDJ as publishing directory for Red Hat Certificate System
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.
Automated installation and configuration of OpenAM
This blog is about automation of OpenAM architecture installation and configuration. As I recently automated architecture from my previous article [1] (simplified without using SSL), I would like to say something about issues I met.
