Versions Compared
Version | Old Version 4 | New Version 5 |
---|---|---|
Changes made by | ||
Saved on |
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Table of Contents | ||||
---|---|---|---|---|
|
Description
Secure Doc is a Web Signing Service that allows to create signing flows as well as generate the certificate to accomplish a proper digital signature. It is a service that organizes the signature of multiple PDF documents between multiple users, setting the signing order, expiration date and more. Secure Doc also manage notification via email. Secure Doc allows:
The generation of credentials, protecting them with second-factor authentication (such as PIN and OTP).
Use this credentials (or other ones) to create remote signatures in different formats.
- The creation of closed parties where the members can view and sign (or reject) a common set of PDFs documents. Members can also play an auditor role.
///////////////
Its REST interface allows managing the complete life cycle of a credential, and it may require the participation of the holder for some tasks, such as the renewal or re-issue of it.
Alison-Server has a modular architecture, which allows defining several redundant modules to operate in high availability mode, with clusters replicated by means of a shared database.
Alison-Server is designed so the same instance can be shared between different organizations. It is also possible to separate different users of the same organization into isolated groups.
Below are some fundamental terms that are useful to understand the configuration and architecture:///////////////
Flow
A flow is a set of users and documents to be signed (or rejected) by this users.
It can also have auditors. An auditor is a special flow member. The auditor function is not to sing or reject, but to observe how the flow develops.
Each flow has its own configuration, such as the expiration date, the signature type and the position where the signature will be.
A flow can have additional documents as well, that play a complementary role. This additional documents will not be signed.
Tenant
A Tenant work like a group. Each Tenant has its policy, roles and users.
Each flow and credential is created within a Tenant, which usually represents a complete organisation.
A Tenant can contain credentials with certificates that were issued by different issuers (ACs) within the PKI of an organisation.
Role
A role is a set of permission. Each role is created within a Tenant, and each user has a role in each Tenant that the user is in. The role permissions are:
- Read permission: allows to view flows.
- Write permission: allows to start, sign or reject a flow. Its also allows to extend the expiration date or to add additional documents.
- Create permission: allows to create a flow.
- Auditor permission: allows to play the auditor role.
- Administrator permission: allows to play the administrator role.
By default, every Tenant have four roles automatically created:
- Operator role: it has read, write and create permissions.
- Auditor role: it has auditor permission.
- Administrator role: it has all permissions.
- Blocked role: it has no permissions.
Each Tenant have a default role. The default role is assigned to any new user that joins the Tenant. If no default role is defined, then the operator role is set as the Tenant default role.
/////////////////////////
Info |
---|
When a product or service wants to access certificates stored into different Tenants, it must use an API-Key that allows access to all of them at the same time. |
Seat
A Seat represents an individual, holder of credential. Each Seat belongs to a particular Tenant.
A Seat can contain several credentials.
Credential
A credential is the combination of a public/private key pair and an x.509 public certificate.
It is protected with second-factor authentication (OTP and PIN) to improve security.
Second Factor Authentication
An authentication factor is a piece of information used to verify the identity of an entity.
A second-factor authentication means that in order to access the protected resource (the credential) the user must have something to prove his identity. Alison-Server supports the use of PINs, OTPs or both.
OAuthClient
An OAuthClient is an application that can make use of Alison-Server services.
It must have a key (API-Key) that allows access to all Alison-Server resources.
Enroll Administrator
Access https://alisonserver-admin.certisur.net to create a new administrator.
Contact CertiSur Validation to request that your account will be associated with your company tenants.
You have to enter a valid email (it will be validated), and a complex password with:
- Lower and uppercase letters
- Numbers
- Symbols
- Minimum of
Your Corporate Contact will be contacted to approve your enrollment and your role.
Image Removed
Administration Console
Access administration console https://alisonserver-admin.certisur.net. Each user is enabled to watch or administer several Tenants, depending of the role defined for each one.
Functionalities found in this console:
- Statistics: certificates and signatures quantities.
- Last certificate and signature
- Log information
- Generate API-Keys to share with applications to allow listing certificates (by Tenant) and get Access-Token to share with End-User (certificate owner) to generate a signature.

Panel
Image Added