블로그 구독

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.


저자 소개

채널별 검색

automation icon

오토메이션

기술, 팀, 인프라를 위한 IT 자동화 최신 동향

AI icon

인공지능

고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트

open hybrid cloud icon

오픈 하이브리드 클라우드

하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요

security icon

보안

환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보

edge icon

엣지 컴퓨팅

엣지에서의 운영을 단순화하는 플랫폼 업데이트

Infrastructure icon

인프라

세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보

application development icon

애플리케이션

복잡한 애플리케이션에 대한 솔루션 더 보기

Original series icon

오리지널 쇼

엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리