PrimeKey SignServer is a great solution for central management of digital signing operations, including signing of documents, code, timestamping, and many more. If you never had a chance, we definitely recommend to give it a try!
Recent release of the SignServer adds support for JWT to allow signature requests based on the provided JSON Web Token (JWT) included in the request. This is very handy feature as you can use variety of identity providers supporting OAuth 2.0. Upon successful authorization, JWT claims contain information required to accept or reject SignServer request for processing.
OAuth 2.0 is an authorization framework, not an authentication protocol. However, in many enterprise applications, there is a need for SAML 2.0. SAML (Security Assertion Mark-up Language) implementation. This is an umbrella standard that covers federation, identity management and single sign-on (SSO). Although both the OAuth 2.0 and the SAML 2.0 can be used for the same purpose, they were designed for different use cases.
Providing access (temporarily or permanent) to resources
Providing access to portal application
Centralized identity source
OAuth 2.0 and SAML 2.0 standards can be additionally combined. You can use for example SAML 2.0 for authentication, and once you have a SAML response including assertion, you can use that as the OAuth 2.0 bearer token to access protected resources.
SAML 2.0 implementation for SignServer
In the context of SAML 2.0, SignServer acts as a SAML consumer. The SAML assertions are digitally signed and can be verified with the public key and certificate of the SAML authority. The SAML SignServer configuration allows having the authorization server separate from the SignServer application and provides eIDAS compliant authentication and authorization to signing and validation workers using multi-factor authentication (MFA).
The following use case example outlines authenticating with the SAML authority to obtain a signed SAML response including SAML assertion. It is then used in the request sent from the client to SignServer (the SAML consumer). The client in the following overview could, for example, be an enterprise application communicating with a document management system.
1. Certificate with Public key of the SAML Authority distribution
The worker in SignServer is configured to trust the SAML authority server’s certificate. Authorization rules matching assertion’s attributes from the signed SAML response with assertion are also configured.
2. User sends the request to consume service
The user requests signing or validation services from enterprise application.
3. Authentication requested
The enterprise application request for authentication for SAML authority providing details about the user’s authentication domain.
4. SAML authority provides authentication context
The authentication context for the user is provided.
5. Authentication context forwarder to user
The user receives the authentication context that should be used in order to authenticate to the service from SAML authority. Context is used by the user.
6. Authentication of the user
User authenticates using credentials with the Authentication server / Identity provider. When MFA is enabled, there may be multiple rounds in the authentication process.
7. Producing signed SAML response with assertion
Upon successful authentication, the user receives the signed SAML response with assertion from the SAML authority. The response can also contain AudienceRestriction element to specify the target system for use of the SAML response. (specifically targeted for SignServer)
8. Forward signed SAML response
User forwards the signed SAML response as a proof of successful authentication and authorization for signing / validation request.
9. Request to sign / validate
The request with the signed SAML response is submitted to the SignServer.
10. Perform task and provide response
SignServer validates the signed SAML response and its assertion attributes, then performs the operation and provide a response to Enterprise application.
User receives response from SignServer.
Towards the eIDAS compliancy
Secure and robust authentication and authorization implementation is a very important step to achieve eIDAS compliant signing or sealing solution. By leveraging MFA, central signing solutions can work on any type of device using different mechanisms and authentication options.
SAML 2.0 with OAuth 2.0 supports the process and are vital for non-repudiation as they ensures that the user has authorization to use the signing private key. This prevents anyone from accessing sensitive information from any device. By using new or existing authorization service with MFA deployments, you can strat providing the central signing service compliant to eIDAS on each device, without any changes to the end-user device.
If you would like to discuss more details, or to try the SAML 2.0 implementation for SignServer, do not hesitate and get in touch with us!