Overview
The SAML authentication protocol requires that you manage certificates. There are two usages for certificates: To sign the SAML assertions and to encrypt the assertions. This section gives some considerations related to the management of these certificates.
Considerations about certificates
You can either use certificates generated from Bizagi in the Customer Portal, certificates signed by a certificate authority (public or local CA), or self-signed certificates. If you use self-signed certificates it is important that the certificate is created with the following requirements:
•The certificate must be in .P12 or .PFX file format. This format contains both the private and the public key and needs a passphrase to open.
•The password for the certificate file, as defined by you when you exported the public and private keys.
•Give the certificate the maximum expiration date allowed in your organization.
•The following parameters are recommended, though, they are not mandatory:
oSubject parameters
▪Common Name or fully-qualified domain name (CN), for example, www.example.com.
▪Organization name (O)
▪Country code (C)
▪City code (L)
oSubject Alternative Name (SAN). For example, DNS name = *mycompany.com
|
Because certificates have expiration dates, it is very important that you keep track of the due date. Otherwise, if the certificate expires without renewing it, users will NOT be able to access the web portal using the SAML identity provider using that certificate. |
About the P12 format
The P12 or PFX format is an encrypted file that encompasses both the private and public keys. When generating these certificates you must include a password (passphrase) so this password is used to decrypt its content.
This certificate is used to sign SAML2 assertions, therefore, private and public keys will be used to encrypt outgoing messages and decrypt incoming messages.
You must use P12 files for two purposes:
•Signing SAML2 assertions (mandatory usage)
•Encrypt messages (optional usage)
How to generate self signed certificates
You can generate certificates in the Customer Portal or refer to Issuing self-signed certificates to learn how to create certificates.
FAQ
Is the certificate for HTTPS/TLS purposes?
No, this certificate is only to sign and encrypt SAML2 assertions. In our cloud services, HTTPS/TLS is already in place.
Does having a certificate represents an extra cost?
No, you can rely on local CA or self-signed certificates.
Is using a self-signed certificate less secure?
Not for signing purposes because this certificate is not exposed to the public, hence, it does not represent a vulnerability. It is only used for signing messages at the application level based on the SAML2 logic.
Does use a certificate depend on the Identity Provider?
No, You will always need a certificate and uploaded in Bizagi's Customer Portal when configuring ANY Identity Provider.
Generate Authentication Certificates in the Customer Portal
You can generate security certificates used for the Authentication Protocols within the Customer Portal. This feature allows you to either create and configure a new certificate or upload an existing one in the Customer Portal. Once the certificate is created, you can visualize all its details in the Authentication Certificate section, where you are able to delete or download it.
In the Authentication Certificates article you learn all about creating the security certificates along with some restrictions and protocol configurations.
Restrictions and Considerations for generated Authentication Certificates in the Customer Portal
1.This feature is only available for Enterprise subscriptions environments.
2.Once a certificate is created, it cannot be edited given its immutable nature.
3.When a certificate expires, it’s necessary to create a new one and configure it with the protocol that was previously being used.
4.Internally, the SHA256 algorithm is used in the self-generated certificates, which is the most secure and recommended.
Last Updated 7/7/2023 2:50:44 PM