Enterprise PKI · Digital Trust Engineering
SYNRION x.ID · ARCHITECTURE
From a compact deployment to distributed PKI: explore the roles, follow a request and see where the certificate is issued.
All services · database · CA
The starter package includes all required x.ID services, the database and a CA. Central orchestration, policy processing and CA integration are bundled. An existing PKI is not a prerequisite for this example.
LDAP and Entra can be integrated through dedicated Outposts when needed. The small diagram simplifies deployment, not security principles.
Browser · agent · hardware token
The user works with a browser, x.ID Agent and hardware token. Private token keys are generated on the hardware and remain there.
A jump host is not shown as an additional prerequisite in this compact example.
Included in the package
The database for inventory, assignments and operational data is included. You do not need to supply a separate database system.
Certificates within your setup
The included CA issues certificates for the starter setup. The bundled CA Connector submits policy-validated requests; the agent provisions the certificates.
The CA is part of the package, not an additional external prerequisite.
YubiKey stays with user
The user connects to the jump host via RDP. For PIV, the local YubiKey is redirected into the session as a smartcard. For FIDO, the x.ID Agent must run on the user host.
Private token keys are generated on the hardware token and never leave it.
Browser + x.ID Agent · PIV
The user opens the x.ID website on the jump host. The agent for PIV provisioning runs here and accesses the token redirected through RDP.
The certificate workflow shown is PIV. FIDO agent placement is separate.
OIDC
The browser authenticates the user with the identity provider. After OIDC sign-in, the user accesses the Core.
Authentication does not replace subsequent policy and source validation by PEP.
Lifecycle and policy routing
The Core provides central orchestration. It associates identity, token and request, and routes processing, target CA and template according to policy. It returns the issued certificate to the agent.
One central Core. The diagram shows logical roles, not a fixed server count.
Source validation + signature 1
PEP User validates the request and policy against the authoritative identity source and signs the request. It then routes directly to a CA Connector or, according to policy, to PEP Admin for additional validation.
The source can be AD / LDAP in the responsible forest or Entra.
Revalidation + signature 2
PEP Admin validates again against the authoritative source and adds a second signature. This policy route can lead to a different CA and template than the direct user route.
In this Enterprise example, this route leads to CA Connector B and CA B.
CA Connector
Outpost · CA integration
The connector submits the signed request to the selected CA. It receives the issued certificate and returns it to the Core.
The certificate returns to the Core and then to the agent.
Outpost · separate PKI zone
This connector serves the CA on the admin route. It submits the request signed by both PEP User and PEP Admin. The certificate returns to the Core.
PEP signatures on the request are distinct from the CA signature on the certificate.
One CA
User templates
Multiple templates
The direct user route leads to CA A in this example. The appropriate template within the CA is selected according to policy.
The compact setup uses one CA with multiple templates. Policy determines the template used for each request.
Root trust: for example RSA 4096 or ECC P-521.
Admin templates
The additional admin route deliberately leads to a different CA in a separate PKI zone here. Policy determines the target CA and template.
Separate CAs are one possible architecture. Policy could also route both paths to the same CA.
Multi-Forest · Multi-Domain · Entra
AD / LDAP · Entra
Forest A with domains A1/A2 and Forest B with domains B1/B2 represent multiple directory environments. Entra is additionally integrated natively. Each PEP validation uses the responsible source.
The compact example uses one domain in one forest. Entra can be added. Each PEP validates against the responsible source.
Source validation and directory provisioning are separate responsibilities.
Provision directory
The LDAP Outpost provisions LDAP / Active Directory. In Enterprise deployments, the responsible forests and domains are reached through the appropriate integrations.
This is a separate responsibility alongside PEP and CA Connector.
Provision cloud identities
The ENTRA Outpost provisions Microsoft Entra ID. It is not a CA Connector and does not replace PEP validation.
Entra remains visible as a separate target.
Optional integration
Forest A / B · Domains A1 / A2 / B1 / B2
One forest · one domain
LDAP provisioning target. Responsibilities and permissions are defined per environment.
Native integration
Separate cloud identity source and provisioning target for the ENTRA Outpost.
The workstation submits the request to the included x.ID system.
The Core orchestrates processing. Included policy services validate and sign according to configuration; the CA Connector submits the request.
The bundled CA issues the certificate. A separate existing PKI is not required in this simple setup.
The bundled services return the certificate to the agent. It provisions the hardware token; the private token key stays on the hardware.
RDP to the jump host, PIV smartcard redirection and OIDC through AD FS or Keycloak.
After sign-in, the Core orchestrates the request and selects the policy route. Private token keys are not transferred.
PEP User validates against the authoritative identity source and adds the first signature. Policy then determines the next route.
PEP User checks the authoritative identity source and adds the first signature. The request then goes to PEP Admin, not directly to the CA.
Source validation and first PEP signature. The direct route then leads to the CA Connector.
PEP Admin receives the request already signed by PEP User, validates again against the authoritative identity source and adds the second signature. Only then does it proceed through CA Connector B to CA B.
CA Connector B submits the request with two PEP signatures to CA B using the appropriate template.
The CA Connector submits the request with one PEP signature to the CA using the appropriate template.
The CA issues the certificate. The responsible connector returns it to the Core.
Core → agent on JMP → redirected YubiKey. The certificate is provisioned; the private key remains on the token.
After PEP User there are two alternative routes: directly to CA Connector A, or through PEP Admin for additional source validation and a second signature before CA Connector B. Policy selects the route per request; the two routes do not run simultaneously.
