How does Authentication with CA Certs work?
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. Please visit to learn how to create the strings securely.
Comments
-
Hi @annejulie ,
The OpenSSL download links in the interactive guide are no longer available (404 Not Found). Can you please update it? Thank you!
Best,
Amy
0 -
Hello.
Is below link supposed to work ? If not, where should I expect to find similar instructions as in your "instructive and interactive guide" ?
Regards, Anstein
https://community.anaplan.com/t5/Common-Support-Questions/Interactive-CA-Certificate-Guide/ta-p/58492
0 -
@NORCEASTR - try this please! https://anaplanenablement.s3.amazonaws.com/Community/Interactive+CA+Cert+Guide/story.html
0 -
Thx, very useful.
0 -
QQ - Just want to make sure I am understanding this statement:
"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."
If I use the method outlined here:Is it correct that I only need to perform the above process once and then can reuse the following until my CA Cert expires?
encoded_string:A randomly generated string of at least 100 bytes, encoded in base64.Encoded_signed_string:This string is the "encoded_string" signed by your private key and then base64 encoded.
Or is it recommended to generate a new
encoded_string:each and every time I need to authenticate?Just trying to understand best practices here.
0 -
Yes - that is correct. You only need to perform that process once. After your CA certificate expires, you need to recreate the
encoded_stringand yourEncoded_signed_string0
