The Server Signing Application (SSA) is a software that acts as a kind of proxy. It interacts directly with the SAM and uses a cryptographic module to generate, hold, and use the signing keys. The SSA provides an interface to the SAM of the cryptographic module. All requests to the SAM (e.g., regarding signatures to be generated) by the SAK/OS or users of the SAM shall be received by the SSA and forwarded accordingly. The SSA requires each Signer to successfully identify and authenticate themselves before allowing any actions that may affect the SAM. The SSA is responsible for screening requests and managing audit logs. It may maintain Signer authentication for a specified period of time and/or for a specified number of signatures. The SSA optionally communicates with the SAM to provide data relevant to their function. Used to provide a registration service in accordance with [EN319411-1].
The SSA is called in the production process by the ProductionQueueProcessor. Surrounding applications and services are in particular the SignatureActivationModuleService, the proNEXT IdP, the SecureFramework Operations, and Audit Manager and Key Manager. The interfaces used are REST(HTTPS) and WebSocket (peering) based.
The interfaces of the SSA are secured via different security features. If the SSA is called in the production process from the ProductionQueueProcessor, the production request must include a data field signed by the RegistrationManager that contains the trusted eID data. The signing REST interface expects a valid ID token in the SAD. Other REST interfaces can only be invoked with a valid ID token in the Authorization header.
Depending on the interface, the ID token must include one of two roles: 'RemoteSignature-Signer' or 'RemoteSignature-PrivilegedUser'.