For more information and all parts of the series visit Introduction to eIDAS package for SignServer.
The SignServer is not designed to be in the role of an Identity Provider or Authentication / Authorization provider. However, it needs to be able to process identity verification and authorization prior performing operations. See the eIDAS SignServer: Typical setup and basic terms for the logical architecture of the remote signing solution and where it fits.
eIDAS compliant authentication and authorization is an important topic and needs to be a part of the overall architecture to achieve the advanced or qualified remote signing, so let’s take a look how it works in the context of SignSever.
Usually, the first step for someone who would like to consume electronic services, is to identify himself. The identification can be done in a various ways, such as:
- identification based on a legal document at the Registration Point (e.g. passport)
- remote identification methods (e.g. video-identification)
- identification based on previous valid electronic ID (e.g. issued by different provider)
After a successful identification and validation, the user’s identity is provisioned within an Identity Provider solution. It means, that your ID is registered in a system. The scope of the Identity Provider depends on which services needed to be consumed:
- private solutions have usually more narrowed scope because they are operated for the private purpose, typically applied in the bigger organisations
- national eIDs are operating on a broader scope, as you can use the national ID with many electronic services (although usually only in the particular state)
Authentication and Authorization
When you have an electronic identity, you are assigned with the credentials and permissions to consume the services. To comply with the eIDAS regulation, you need to implement and enforce multi-factor authentication (MFA). The most common is the combination of the following authentication factors:
- username / password
- push authentication on mobile device
- biometrics (face recognition, fingerprint)
- client certificate
- SMS OTP (which is currently being considered as not secure)
- TOTP (time-based one-time codes generated based on seed)
In most cases, you’ll be assigned with the role or a group of roles, that determine your permissions and access rules. This is checked after the successful authentication (providing the proof of your identity). Based on the authorization, you can access specific electronic services.
How it works with SignServer
As mentioned earlier, SignServer does not act as Identity Provider. It relies on the eIDAS compliant Identity and Authentication / Authorization Providers services. Authorization and its behavior is configured as part of the Signer properties. It is called Authorizer.
For more information, access the official SignServer documentation.
Authorizer is, in another words, and authorization layer in front of the Signer, which validates the conditions to access the service and outputs the identification of user, in case of successful authorization.
Additionally, to fully comply with the ETSI standards for the qualified remote signing under Sole Control Assurance Level, which we will describe in the next articles, the authorization must be provided as part of the Signature Activation Data (SAD) over Signature Activation Protocol (SAP). This ensures end-to-end confidentiality and integrity between the user and the Signature Activation Module (SAM) and that only the user is able to perform the signature operation.
Because the data to be signed is part of the SAD, and they are not available prior executing the Signer, it provides additional authorization layer on top of the Authorizer.
SAML 2.0 authorization
Let’s take a look at an example of how to configure and use SAML 2.0 authorization for any Signer.
There are several authorization servers available. The following example outlines authenticating flow with the SAML authority to obtain a signed SAML Response, then used in the request sent from the client to SignServer (the SAML consumer). The client in the in the flow can, for example, be an Enterprise application communicating with a document management system.
SAML 2.0 configuration
The following is a sample configuration of the SAML 2.0 Authorizer within the context of the Signer:
You should use the following implementation class in order to enable SAML 2.0 auhtorization:
In order to identify the SAML 2.0 server issuing assertions and validate its source and signature, you need to configure the SAMLSERVER properties:
- SAMLSERVERn.ISSUER – identifies the issuer and must be the same as the issuer property inside the signed assertion
- SAMLSERVERn.CERT – certificate of the the issuer (as the SAML authority) which will be used to validate the signature of the assertion
You can specify as many SAML authorities as you would like to support.
Through SAML attributes, you can create matching rule to check the presence of the attribute in the signed assertion:
- SAMLATTSn.ISSUER – identifies the issuer to which the matching rule relates
- SAMLATTSn.ATT.NAME – name of the attribute that should be present in the signed assertion
- SAMLATTSn.ATT.VALUE – value of the named attribute that should be present in the signed assertion
If there is no match according defined matching rules, authorization is rejected.
You can define and further restrict to work only with the signed assertions that should be used for the signing and SignServer purposes through the Audience attribute of the signed assertion.
If the Audience attribute does not match any comma separated accepted audience configured for the signer, authorization is rejected.