# Onboarding to Signicat
Page contents
# Process outline
Integration with Signicat is a relatively simple process. Realization of the source code for authentication or signing services is straightforward and requires no eID-specific competence on the customer side. The integration is done over open, industry standard and platform-neutral protocols such as OIDC or SAML and Web Services.
However, in a normal integration there are several agreements that must be established, as well as preparation of the infrastructure between the customer, Signicat and eID suppliers. Some of these tasks will take some time. Our recommendation is that the customer plans the integration project thoroughly, and allocates sufficient time for these tasks.
The overall process for integrating with id.signicat.com will typically include the following steps (the order of the steps may vary slightly from case to case):
It is useful to set up and communicate a schedule to ensure that Signicat has sufficient capacity in the integration period. This also allows Signicat to gain a better understanding of your needs and priorities.
# Contract/Specification phase
In the contract/ specification phase, the basis of the rest of the integration process is formed. Information needs to be exchanged, and several clarifications should be made. Generally, it is advantageous to get an overview and clarify tasks and issues as early as possible in the process.
# Sales/ presales activities
Initial sales/ presales activities are usually handled by one of Signicat’s key account managers. They will inform the customer about relevant products, services and ID solutions.
If the customer comes to an agreement with Signicat, contracts will be signed:
- The customer selects products, services and ID solutions, and signs an agreement with Signicat.
- The customer signs an agreement either with the ID authority or Signicat for every ID infrastructure they want to connect to.
# Clarifications with ID authorities
# National identification numbers
National identification numbers (such as the Swedish personnummer or Norwegian fødselsnummer) are regarded as personal sensitive data in most countries. In order to obtain permission to use national identification numbers in applications, some ID authorities require that the customer has a a license or implements end-user consent in their application. Signicat informs the customer about these requirements, and how they can be handled.
# Roles/ authorizations
Signicat’s roles and authorizations should be clarified in the agreements between the customer and the ID authority. The purpose is not only to secure and simplify the establishment process, but also future maintenance.
Roles and authorizations are not standardized among the ID solutions and may vary. One of Signicat’s Operations specialists may advise the customer in this regard. Typical authorizations are:
- Responsibility to receive and install merchant, enterprise or SSL certificates
- Responsibility to accept and sign ID-specific certificate tests
- Responsibility to renew merchant, enterprise or SSL certificates
- Responsibility to revoke merchant, enterprise or SSL certificates
# Formal ID-specific approval
Some ID authorities require performance of formal ID-specific tests before merchant certificates for production can be issued. If necessary, Signicat may advise the customer about the procedures.
# Authentication protocols
Signicat supports authentication protocols like OpenID Connect, SAML 1.1 and SAML 2.0. The selected protocol affects the configuration of the service, and if a client library from Signicat is needed or not.
Remark: It is quite possible to use a SAML client kit from other parties than Signicat. However, this requires that Signicat’s SAML signing certificate is configured with this client kit.
# Security certificates
Several of Signicat’s products and ID solutions require the installation of security certificates that represent the merchant. Depending on products/ ID-solutions the customer has selected, the following certificates must be ordered and properly installed:
- Most ID solutions require a merchant certificate issued by the ID authority.
- Use of Signicat’s signature and archive web services requires client authentication of the customer’s application. A client SSL certificate for the web services, issued by Signicat, must be installed in this application.
- Signicat’s subdomain product requires an SSL certificate issued by a certificate authority. This SSL certificate must be installed in Signicat’s production environment.
- Signicat’s PAdES product may need an enterprise certificate for signing OCSP requests. This requirement applies to Buypass specifically.
- Signicat’s SSO product requires a SAML signature certificate that represents the SSO partner. This certificate must be installed in Signicat’s production environment.
# Configuration name
Each customer configuration in Signicat’s systems has a unique name. This name represents a company or merchant uniquely in our systems, and it will be used in a variety of contexts: in the technical integration, in the extranet, in the URL, in reporting, and in billing. This name should be as intuitive as possible. Signicat informs the customer about the use of this name, and suggests a suitable name for the configuration.
If the customer orders several subdomains, we will need to establish one customer configuration for each subdomain. This is due to system requirements.
# Development phase
The development phase includes technical as well as graphical integration with Signicat’s services.
# Graphical profiles
Graphical profiles are used to customize the user experience of a customer’s application. A graphical profile consists of a collection of files which will be a part of the customer-specific configuration on id.signicat.
A customer may have several brands or applications. In this case it is convenient to establish a different graphical profile for each brand, application or website using id.signicat. It is also possible to have several profiles for the same website, and even share the same profile between several websites.
You can find more information on graphical profiles in our documentation on Graphical adjustments and customization.
# Authentication
Signicat provides authentication capability with a wide range of public and private eIDs in the Nordic region. The service is easily integrated into any website and web application to enable secure login with strong authentication.
For more information on authentication, see our documentation on Getting started with authentication.
# Signing
Signicat’s signature services are designed for use in web applications covering almost any B2C, B2B and B2E scenario. You may integrate with the signature services using our Sign API, a RESTful web service that can be used to obtain electronic signatures from customers, as well as with our legacy DocumentService SOAP API.
For more information on signing, see our documentation on Getting started with signing.
# Test users
Customers will normally need test users during the development and test phase. Please see the pages for each ID method for test user information.
# Environment
During the development phase it is recommended that customers use Signicat test certificates and the public test environment “demo”. Please see our Demo Service page for information on which authentication and signing methods are available in Signicat’s demo service.
# Pre-production phase
The pre-production phase includes the creation/ deployment of the customer’s services in Signicat’s and the ID provider’s pre-production infrastructures.
# Establish customer configuration
Signicat establishes a new configuration for the customer in the pre-production environment. The name of the configuration is normally decided in the contract/ specification phase.
# Access to the pre-production infrastructure
Some ID providers require that access to their pre-production systems is ordered. Signicat may assist customers with this task.
# Merchant certificates
Some ID providers require that merchant certificates for pre-production are ordered, installed and verified before a production merchant certificate can be issued. Signicat may assist customers with this task.
# Formal ID-specific tests
Some ID providers require that formal ID-specific tests are performed and accepted before a production merchant certificate can be issued. Formal tests and self-declaration is normally performed by the customers, but Signicat may advise regarding this task.
# Billing
Billing of the subscription fee usually starts when the customer’s services are available in pre-production.
# Production phase
The production phase includes the creation and deployment of services in Signicat’s and the ID provider’s production infrastructures.
This page is relevant for customers that have completed their technical integration with id.signicat and have carried out the necessary tasks in the pre-production phase. Before going into production, the following tasks must be performed.
# Establish customer configuration
Signicat establishes a customer-specific configuration for the customer. The name of the configuration is the same as in pre-production.
Merchant certificates or secret keys for the production infrastructure are an important part of the customer configuration. Normally customers need certificates/ keys for every ID solution they want to integrate with. Merchant certificates/ secret keys can be ordered from the ID authority itself, and be made available for Signicat in the following ways:
- By sending activation information for the certificate to Signicat. This is normally the case if Signicat is technically responsible for the certificate (recommended).
- By sending the certificate itself to Signicat over a secure channel.
Signicat installs and verifies the merchant certificates/ private keys in the customer-specific configuration.
# Access to the production infrastructure
Some ID providers require that access to their production systems is ordered. Normally the customer sends the order, but Signicat may assist with this task.
# Establish security measures: Authentication
# SAML-protocol
- The customer configures their application to use HTTPS. Signicat’s authentication service uses SAML, and requires the use of the HTTPS protocol between the service provider (SP) and id.signicat.
- The customer sends the URL of their application to Signicat. Each application that receives SAML responses (the security packet with authentication information) from id.signicat must be registered in our systems. This is typically the target URL. Any number of target URLs may be registered. See this page about SAML certificates in production.
# Establish security measures: Signature and archive services
# Two-way SSL
The communication between a web service client and Signicat’s web services must be protected with two-way SSL. All clients using Signicat’s Sign API, DocumentService or archive web services must be authenticated using a client SSL certificate. Such a certificate will provide access to all data associated with a particular ‘service’. If the customer has more than one application, each application will need to have a separate certificate.
Signicat issues the client SSL certificate.
Other relevant articles:
# Web service password
The communication between a web service client and Signicat’s web services must be protected with a customer-specific password. Signicat issues the password, and sends it by SMS to a technical responsible person on the customer’s side.
This requirement applies also in the pre-production environment, but usually with a common password for all customers.
# Using subdomains
If the customer has ordered Signicat subdomain, the domain name must be correct on both sides. Change this from https://id.signicat.com to the hostname of the customer’s subdomain.
This task must be coordinated between Signicat and the customer, if the application is already in production.
# Acceptance test
Before going into production, you should ensure that everything works as planned in production before officially going live. If needed, Signicat can adjust the setup in cooperation with you. After you have accepted, the service is deployed in Signicat's and your production infrastructures.
# Billing
Billing of the transactions fee starts when the customer’s services are available in the production environment.