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
- 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
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.
Signicat registers the IP address of the service provider (customer’s application that hosts the signature process).
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.
Billing of the transactions fee starts when the customer’s services are available in the production environment.