Managed Cloud Signature Server or On-Premise (In-House) Signature Server
It's your choice! Decide for yourself whether you want to operate the server yourself in your own data center or any other data center of your choice, or whether you want us to operate the server for you (here you can select a data center or we can suggest one that meets your requirements for data protection, data security, availability, etc.). We will then operate your signature portal server exclusively for you there so you don't have to worry about its operation, availability or updates).
Licensing Options
Secure Managed Cloud
The perfect solution for customers who have both high data protection requirements but also a cloud strategy.
You want to keep the HR investment on your side as low as possible, and/or you simply lack the experts in your company
who can take care of running of it? Then our all-round carefree package with the Managed Signature Portal is just right for you.
Together, we will find the right data center for you, where your signature portal can then be operated exclusively for you by us.
This can be, for instance, the data center of the Bundesdruckerei or another German data center, but also a data center of Amazon, Microsoft or Google.
You have all configuration and customizing options for the Signature Portal, just as if you were running it yourself.
The big difference is that we take care of the installation, configuration and operations.
We apply updates and patches and ensure that the service performs well, is highly available, and much more.
In-House (In-House (Self-Managed))
The signature portal is then operated in your own data center or in a data center of your choice by you or one of your partners.
This option is usually chosen if other internal systems need to be connected to the signature portal, e.g. an SAP, DMS, etc.
or if there are increased data protection requirements such that your policies require that only you have access to the data center.
In-house setup allows you to always maintain full control over operations, update processes and availability.
But of course, it also requires you to have staff that can take care of operations, even though our expert support team
will assist you to the very max with guaranteed response times, so you don't need experts in cryptography or anything like that on your end.
Your benefits at a glance
Security:
On Premise
Cloud Server
- You decide which requirements apply to the data center
- How long which files or data are stored on the server and when which data are deleted
- Which users can use the service and which user has which role
- How which user or user group should authenticate (e.g. password or two-factor authentication)
- Files are always sent encrypted according to BSI guidelines
- The server is multi-client capable
- You decide when updates are installed
- we take care of the TLS certificate
- If the signature is qualified, you (or we) can apply for the account at the trust center¹.
¹: Convenient connection of the trust center via web interface
Actions:
On Premise
Cloud Server
- Supplying the hardware
- Administration of firewalls, load balancers, etc.
- Ensure the availability of the signature portal
- Installing updates and patches for the signature portal
- Maintenance of the TLS certificate and its validity for the server
Technical requirements for the operation
Of course, the exact requirements depend heavily on the planned usage, e.g., how many users will be using it and with what intensity, and how usage is distributed over the course of a day. To ensure ideal use of the signature portal, some requirements must be met.
This figure shows one possible infrastructure configuration for the signature portal. It must be taken into account here that, for example, the path to the remote signature provider (remote signature service) is only necessary if, for example, qualified signatures need to be created with a remote signature service. In this case, only the hash value for the signature is transferred. Also, the connection to an Active Directory is only required if you intend on using an existing Active Directory for authentication. Other possibilities are the connection of an Azure AD, ADFS, etc. or the use of an internal user management of the signature portal, so that you do not need an Active Directoy or the likes.
Likewise, numerous other databases can be used. For example, a default database of the signature portal can also be used. The mail server connection is relevant if the e-mails sent by the signature portal (e.g. for a signature request) need to be sent from your company domain with your company sender. If this is not the case, you can also use the internal mail server or do without mails altogether.
Infrastructure depending on signature level:
You want to sign with a qualified remote signature:
The SecPKI server must be able to reach the URLs of the remote signature provider. The signature portal can be connected to all European trust services. You can take the trust center of your choice. The connection is made conveniently via the dashboard website.You want to perform advanced signatures:
There are different ways to do this. The two most popular are as follows: You let the server create the certificates. This path is mainly used for internal use. The CSM tool from Bundesdruckerei can be used as an alternative. Here, the certificates created by the server are issued with a certificate from the Bundesdruckerei, so that you also have a green checkmark in Adobe, for example.You would like to apply a seal:
A distinction must be made here between remote sealing and sealing with a seal card. For remote sealing, the same requirements apply as for setting up the trust service for the QES. This is done conveniently via the website. For the seal card, it must be ensured that the server can access the seal card or the seal HSM.Seal Card:
- The signature portal can also be run with a seal card connected to the server
- In this case, the infrastructure must take into account the fact that the server can access the card reader and thus also the seal cards
There can be an Active Directory connection, Azure connection or SAML IDP:
- If, for example, the company's own Active Directory will be used for authentication at the signature portal
- There is also a convenient AD connector for this in the signature portal dashboard
- ADFS can be connected via SAML
- An external Active Directory does not have to be connected; the internal identity management of the signature portal server can also be used.
- Azure can be connected for instance via OAuth 2.0 or via SAML
E-Mail Server Connection
- In the signature portal - to inform the participants of a workflow of the new signature request by e-mail - an e-mail is sent
- In order for these emails to be sent from your mail server, an email server can be connected to the signature portal server
Special Feature:
- If external users also need to be able to access the signature portal, the web pages for this must also be accessible.
- Alternatively, the service can also be operated completely behind the DMZ and fine-grained URL restrictions can be used to control which URLs are allowed to leave the DMZ and which are not.
The signature portal can be installed on:
- all servers running Java. This makes it universal in terms of platform.
- on a Windows server
- in a VM
- in a container (e.g., in a Kubernetes cluster). and much more
Example of resource requirements:
For a light scenario (the documents in a workflow should not exceed 50 MB, and there should not be more than 100 workflows per month) we recommend 4 vCPUs and 8 GB RAM. Normally, 8 vCPUs and 16 GB RAM can be used. For larger setups, the infrastructure must be adapted accordingly. A connection to the Internet to the selected remote signature service on port 443 needs to be possible.
Please contact us here for further assistance.
Contact