Overview
This major release includes many changes and improvements under the hood, introduces exciting new features, and enhances existing features.
A key technical change is that DokuMate now requires at .NET Framework 4.7.2 or greater, which is no issue if you are on Windows 10. If you are on Windows 7 and your .NET Framework has not been updated for a few years, you can’t install this latest release. And the DokuMate Updater will also not update DokuMate for you.
New Functionality
The new functionality introduced with this release is all about digital signatures in the context of the eIDAS regulation. For more information on the new feature, please have a look at the corresponding knowledge base article. On top of this feature-related article, there are further “basic” articles on:
- Electronic and Digital Signatures,
- Associated Signature Containers (ASiC),
- XML Advanced Electronic Signatures (XAdES).
Changes
The DokuMate Word and Excel templates have been updated to also include the docClassification content control on the title page, which should contain something like “Confidential”, “Restricted”, or “Secret”. Previously, this content control was only included in the footers of the second and following sections but not on the title page.
Digital Expert Talk
We’ve been leveraging “the cloud” for DokuMate for quite some time. The established DocumentTracker feature calls the Microsoft Graph REST API to access SharePoint resources on the user’s behalf, and so does the new Digital Signature feature. And we’ve been using Azure DevOps kind of forever (long before it was called Azure DevOps). But now, DokuMate has a key functional component in the cloud: the digital signature microservice, which:
- is a containerized Spring microservice written in Java (whereas the components running on your local machines are written in C# and XSLT);
- offers a gRPC API (instead of a RESTful API);
- runs in our Kubernetes cluster in the Google Kubernetes Engine (GKE)
- behind an L7 load balancer managed by a GKE Ingress controller and using Google-managed SSL certificates;
- in a Pod with the Extensible Service Proxy (ESP), which is an NGINX-based proxy that enables cloud endpoints to provide API management features; and
- with a Horizontal Pod Autoscaler, which automatically scales the number of Pods based on the CPU utilization; and
- is built and deployed completely automatically by an Azure Pipeline as soon as we push code changes to the microservice’s Azure Repo.
To digitally sign documents stored on SharePoint Online, for example, the gRPC client (Office add-in) and server (microservice) use bidirectional streaming RPCs (Remote Procedure Calls) to exchange relevant data. For example, to create a so-called Associated Signature Container (ASiC):
- the gRPC client (Office add-in) initiates a gRPC call, providing:
- the signing X.509 certificate with its complete certificate chain up to the trusted root certificate (all of which can be shared publicly, because they only contain public keys);
- the location of the SharePoint Online folder containing the documents to be signed;
- the location of another SharePoint Online folder (in the same or different SharePoint domain or site) in which the resulting ASiC container should be stored; and
- access tokens obtained from the relevant Azure Active Directory (AAD) cloud authorities;
- the gRPC server (microservice)
- downloads the documents from SharePoint on behalf of the user, or users, represented by the access tokens provided by the client (using the OAuth 2.0 on-behalf-of flow to obtain access tokens required to authorize the Microsoft Graph API requests made on behalf of the user);
- creates the “data to be signed”; and
- sends that data back to the gRPC client;
- the gRPC client (Office add-in):
- signs the “data to be signed”, using the private key corresponding to the signing certificate (which contains the corresponding public key) and thereby creating the signature value; and
- sends that signature value back to the gRPC server;
- using the signature value provided by the client, the gRPC server (microservice):
- finalizes the creation of the ASiC container;
- uploads the ASiC container to the destination SharePoint folder on behalf of the user, authenticating requests as in step 2; and
- either sends a final success response or, in case the user wanted to attach the ASiC container to an email, streams the ASiC container back to the gRPC client.
Finally, all of this is secure. The user’s private key is kept secret at all times. Only the public key is shared and also included in the signature as part of the user’s signing certificate. The microservice reads files (i.e., the documents to be signed) and writes files (i.e., ASiC containers, XML advanced electronic signatures) on behalf of the user and with the access rights granted to it when the user consented to use the service.