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.
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.
