Signum Architecture & Concepts

The following diagram provides a high-level overview of the architecture for Signum:

 1 - System Admin

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 through 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 - Developer

A Developer can authenticate to Signum with the client agents for Windows, Linux, or macOS 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 - Client Agents

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 Window, PKCS11 for Linux, or Mac Agent for macOS. For more information, see Signum Agents.

4 - Signum Server

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