Introducing the 2024 PKI & Digital Trust Report     | Download the Report

  • Home
  • Blog
  • PKI Design Considerations For Identity Federation

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.

Recommended PKI view:

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

Recommended Identity Federation infrastructure view:

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.

keycomp-1