PKI Design Considerations For Identity Federation

In this blog, we’ll explore taking business enablement to the next level by integrating two security technologies, PKI and Identity Federation.

Business Model: Global partnership with independent territory local firms.

Requirement: Leverage IT to provide a secure business environment for supporting resources, collaboration and sharing.

Goal: Identify and establish a unique distinguished namespace for each individual territory local firm while establishing identity trust relationships among those disjoined namespaces to share resources across territory and security boundaries.

Solution: Public Key Infrastructure (PKI) with federated identity aware.

Certificate Management System (CMS)

Seamless certificate issuance and management across devices and service

https://www.css-security.com/cms

Managed PKI

Powerful digital and secure solution for less cost than you ever thought possible.

https://www.css-security.com/managedpki

Approach for solution architecture, design, and implementation is outlined below:

• Build global trusted root CA with multi-tiered certification authority hierarchy to support global-scope PKI infrastructure while implementing subordination namespace constraints to restrict territory subordinate CA’s certificate issuance within its own local-scope PKI administration and management.
• Facilitate end-to-end namespace linking mechanism between territory, global and cloud to enable core identity information provisioning/synchronization into linked namespaces at each identity store.
• Bind certificate to unique identity ID associated with namespace, and enable certificate mapping back to identity.
• Implement certificate issuance policies (such as high assurance level …) and application/key usage policies (such as non-repudiation, smart card login …) into certificate content, the relying party can leverage it for authentication/authorization/access control purpose without reinventing the wheel.
• Equally important, STS (Security Token Service) can translate those policy settings from certificate to claims into a security token, deliver to the relying party which can also do the same for access control purposes. You would see certificate policies enforcement settings being carried out end-to-end in its entire life.
• Apply key usage to its purpose only. For instance, non-repudiation is very a specific key usage which should not be overloaded. It at least implies the private key is never exported from a secure place, such as a smart card, TPM/virtual smart card, HSM, etc.
• Due to the nature of dis-joined namespace among global and territories, most windows clients appear to non-domain joined devices when accessing global or foreign resources. Windows 2012 R2, Windows 8.1, and above supports non-domain joined certificate enrollment and key-based renewal via CES/CEP.