[Start here] How does Authentication with CA Certs works?
Why CA Certs?
The purpose of this blog series is to give a deeper look on the use of Certificate Authority (CA) Certificates, especially on how this method of authentication works and how to use them for your different integrations.
A Quick Recap On Anaplan APIs Authentication
We recommend our readers to have some basic knowledge on Anaplan APIs.
In order to be able to trigger Anaplan actions remotely, one will need to get authenticated to the API server. If the authentication process is successful, the user will be granted a token that can be used for a limited period of time to activate Anaplan actions. The biggest challenge is to be able to get that token from the certificate you have.
Why would you use CA Certs instead of the well-known "basic authentication", involving the user email and password?
There are 2 main drawbacks of using basic authentication.
1. Critical information easily accessible
When using basic authentication, one will have to use username and password in the development of the integration process. Very often, this information is in clear text for any person who will have access to the scripts.
2. Regular update of credentials
Anaplan's password policy requires that any credentials must be updated at least every 3 months. The team in charge of integration will then be required to amend the scripts frequently, which increases the maintenance workload.
By using CA certs, we want to address those 2 concerns that are frequently raised by teams in charge of integration.
How does CA Cert based authentication work under the hood?
Sometimes, a schema is a great tool for understanding. So here is one:
Anaplan's cert-based method follows PKI basic principles, especially the rules of asymmetric cryptography.
Out of CA certificate, one will extract a private key and the public certificate. To have a thorough description of the steps needed to achieve this extraction, please use this link with a very instructive and interactive guide.
The private key will be used to "sign" a random string, generated externally for that purpose. Anaplan API server will receive this random string and its signed version. Via a specific calculation, it will validate if those two strings are related to each other using a private key's signature linked to the public certificate. Once the check is validated, the authentication process can be sure that the person who has sent the information is in possession of a valid private key.
So why is that method more secure than using Basic Authentication?
Based on what has been described above, we can state that:
As you could see in the previous part, certificate information decoding requires a minimum of technicality to be handled correctly.
No private or confidential information is sent on the web.
There is also another advantage, quite consequential: The integration based on CA Certs will remain valid until the end of the certificate validity. Hence, there is no need to have a regular maintenance of integration scripts.
Anaplan also adds another level of security: to authorize API actions triggering via certificates, public certificate needs to be registered in the tenant admin.
In the case that we want to deactivate a certificate, you can simply do it via this screen. This will be without any consequence on the actual user linked to the certificate.
What about the private information?
One concern can be made on the use of the private key. Indeed, that piece of information is critical and private. Then, it cannot be handled lightly and should not be easily accessed.
Nevertheless, when analyzing the diagram flow, we can see that no private information is passed through the web. Only the 2 strings and the public certificate are sent through the web.
In your integration, nothing prevents you from reusing this pair of strings and store the private key in a secure location. By doing so, you will be compliant with the necessity to secure sensitive information.
Now, let's compare 2 situations, both involving a person with bad intents.
Situation 1: Credentials have been retrieved
In this situation, an authorized person, in possession of Anaplan credentials, can log in into Anaplan and have access to sensitive information stored in Anaplan Platform.
Situation 2: Cert-based information (2 strings + public cert) have been retrieved
In this case, an authorized person can trigger APIs; However, the unauthorized person will have no access to other parts of Anaplan interface and functionality. The access is more limited than with the actual credentials.
Now, you'd also want to ensure that those strings aren't also too easily readable. We will show you a way to achieve this level of security later in the series.
In the next series of this blog, we will present details on creating required strings (2 strings + public certificate) to generate authentication token using Anaplan API. You will learn how to generate these required strings using following methods:
certAuthGenerator.bat: A windows application from Anaplan Support.
Custom Java utility provided with this blog.
Click here to access the next article: “How to leverage sample codes to generate authentication strings from CA Certs?”
Got feedback on this content? Please, let us know in the comments below.
The content in this article has not been evaluated for all Anaplan implementations and may not be recommended for your specific situation.
Please consult your internal administrators prior to applying any of the ideas or steps in this article.