Signum Architecture & Concepts

The below diagram provides a high-level overview of the architecture for Signum.

1. System Admins can authenticate to the Admin Web Console using SAML/OAuth with the organization's Identity Provider (IDP). Once authenticated, Certificate Signing Requests (CSRs) can be generated where the corresponding private key is stored on the HSM and is not exportable. These CSRs can then be sent to internal/external Certificate Authorities (CAs) and issued certificates can be imported via the Admin Web Console. With signing certificates imported, the System Admin can assign an organization's users and groups to specific roles, permissions, and policies defining certificate access.

2. A Developer can authenticate to Signum via the client agents for Windows or Linux using several different methods. Once authenticated they are able to look in the Windows certificate store or PKCS11 provider and see the certificates that are available to them. They can then sign using a native signing tool like Microsoft’s SignTool, and after a quick policy check by the server, the signing operation will be logged and completed successfully. All signing operations happen on the HSM, and the keys are never exportable.

3. The Signum client agents can also be deployed in an unattended mode for CI/CD scenarios. In either the unattended or attended modes the agents control certificate usage and availability using Microsoft’s CSP/KSP interface for Windows or PKCS11 for Linux.

4. The Signum server only makes certificates available to users/machines based on policies defined in the Signum Web Admin Console. All agent activity is logged and can be exported to a Syslog server. Anytime an authenticated and properly provisioned user signs using a native signing tool the private key never leaves the HSM boundary.