Identity Management and Certificates

Identity Management (IdM) in Red Hat Enterprise Linux includes an optional Certificate Authority (CA) component. This CA is the same CA

included with the Red Hat Certificate System (RHCS). If they’re the same, what is the relationship between IdM and RHCS? Is there a secret plan to replace one with another? This post reviews some of the details associated with each of the offerings and explores different use cases – indicating where you might choose to use one solution over the other.

As explained in my previous post, IdM is a component of Red Hat Enterprise Linux; it is included as a part of your subscription. In a nutshell - IdM focuses on managing identities within the enterprise. Currently, as mentioned above, IdM includes a CA component that is derived from the same community project (Dogtag) as is RHCS.

RHCS, on the other hand, is a product (...and is not included as part of your Red Hat Enterprise Linux subscription). RHCS includes all of the components that are available in the Dogtag community project.

As IdM does not include all of the components available in Dogtag, IdM certificate related capabilities are currently limited. While IdM does issue certificates for hosts and services, it does not issue certificates for users, devices or client side certificates for services connecting to other services. Moreover, IdM cannot manage user smart cards or escrow keys. If you are interested in what may be coming (down the road) and/or if you want to help the community to move new features forward - check out www.FreeIPA.org and related the mailing lists.

In theory, IdM will incorporate additional components from the Dogtag project over time. Does this mean that RHCS will become obsolete? Will it essentially be replaced by IdM? The answer is most likely: no, and the main reason is scope. IdM deals with identities related to the enterprise. These identities belong to the same organization (i.e. they share a single namespace). All certificate operations in IdM are generally related to the identities operating within this namespace. In a sense, this is a controlled environment bound to the same Kerberos domain IdM servers.

On the flip side, RHCS is not bound by namespace. One RHCS deployment can issue certificates for users, devices, and services that are completely unrelated to each other. If, for example, you are considering the provision of certificates as a service – RHCS may be a good server to build your solution around. If, for example, you need to issue and manage certificates for entities operating within the enterprise then IdM would likely be a better choice. That said, RHCS could be used to manage enterprise identities if there is a need to issue certificates not only for internal identities but for external identities (e.g. customer / partners) as well.

In many scenarios, it actually might make sense to consider using both RHCS (as a root CA in the enterprise) and IdM (as a subordinate CA for the internal identities).

As can be seen, though there are a number of similarities, the use case for each solution is quite different and thus there is little sense in merging the offerings or eliminating one altogether... at least for now. Looking ahead, there is an option to offer most of the RHCS capabilities including serving different certificates for different purposes as an extension to IdM if we are able to figure out how to control namespaces within IdM. This will be a lot of work... but it is possible... and might be an approach that we would consider down the road.