Bizagi supports integration with Identity and Access Management systems (i.e, Identity Managers or Identity Providers) which are SAML 2.0 compliant, such as NetIQ Access Manager.
This section is a step-by-step guide to the configuration you need to do, both in NetIQ and in Bizagi, to have an integrated authentication in Bizagi against NetIQ Access Manager.
SAML 2.0, requires that both your Identity Provider and your Bizagi project are set up to support HTTPS.
For introductory information about SAML 2.0, refer to Authentication via SAML.
To configure NetIQ Access Manager you need:
1. To have previously generated and imported your own certificates.
The integration uses the for signing assertions.
This step is not bound to Bizagi nor restricted by any special requirement of Bizagi (you usually do it yourself).
If you need some guidance or an example on this step, refer to Generating and installing certificates.
To proceed with the guided steps below, you need to have already imported certificates in your Identity Provider. You need the following information:
•The certificate information (.p12 file).
•The password for that .p12 file, as defined by you at the moment of exporting the public and private key.
You need to be in charge of managing your installed certificates (keeping track of expiration dates and any other maintenance aspects such as responding to changes in your Identity Provider's endpoints).
2. To have already imported and synchronized your users into Bizagi.
When integrating any Identity Manager you must synchronize user accounts that are authorized to access Bizagi's Work portal.
Synchronizing means importing or updating only each account's primary identifier (domain plus username typically, and the email address).
Bizagi does not store passwords when integrating with an Identity Manager. See User Synchronization.
Once you have verified in the Work Portal that there has been at least an initial import of your users into Bizagi, you may proceed.
In Bizagi, unique identifiers for users are either email or the combination of domain and username.
The examples of SAML-based authentication provided below use email as the unique identifier for users.
3. An installed and fully configured and supported version of NetIQ Access Manager.
Bizagi supports NetIQ Access Manager version 4.
The following example (and official certification) is worked on with version 4.4.
If you want to use a different version, which supports SAML 2.0, it is advisable to first check with our support team.
What you need to do
1. Configure in Bizagi, the settings that reference the specification of your SAML setup.
2. Configure Bizagi as Service Provider in NetIQ Access Manager.
1. Configure in Bizagi, the settings that reference the specification of your SAML setup
Use the Bizagi Management Console targeting the environment you want this configuration to apply to (e.g, development, testing, or Production environment).
Alternatively, and only for the Development environment, you may use Bizagi Studio.
1.1. If you are going to configure it from the development environment, open Bizagi Studio.
1.2. Locate the Security module and click the Authentication option found under the Security item.
Select Federated authentication from the drop-down list in the panel to the right, and SAML v2.0 from the drop-down list at the bottom right:
You will receive a confirmation message. Additional parameters appear under the Authentication item.
If you applied this change into an environment other than development, apply the changes are applied in your Development environment as well.
To do this, follow the same procedure you used in using the Bizagi Management Console.
1.3. Configure the additional parameters making sure to click Update for each one that you modify.
Parameter values are case-sensitive. Make sure you enter them accurately.
Fill in or configure these settings as described:
•Cookie type: Define the type of cookie Bizagi uses Persistent o Session cookies. The idle session time-out defines the expiration time for cookies.
•Enable assertion encryption: When Bizagi sends messages to the Idp, it sends two types of assertions.
-Authentication request: which does not have any sensitive information, therefore is not encrypted by standard definitions.
-Session log out request: This assertion contains sensitive information, and can be encrypted. If you set this property on, session log out request are encrypted by Bizagi. However, NetIQ Access Manager does not support receiving encrypted messages, therefore this option must be off.
On the other hand, Bizagi can handle any encrypted message sent by the IdP, even if this property is set off. Therefore, you can activate encryption from NetIQ Access Manager, to give security to messages sent by the IdP.
•Enable authentication logging in database: Check this checkbox (set to On) to direct the web application to log every authentication event, according to your auditing requirements and expectations. You can view the log in the Work portal.
•Encryption certificate: Use the Browse button to locate and upload the digital certificate (in P12 format, containing the public and private key) that will be used to encrypt the assertions generated by Bizagi.
•Encryption certificate password: Provide the password of the digital certificate used for the encryption of assertions.
This password should match the one you defined when you exported certificate information in P12 format.
•Force authentication: Check this checkbox (set to On) to disable SSO capabilities so that every time users attempt to log in to Bizagi, they have to provide their credentials. Using this option depends on your authentication requirements and expectations.
•Identity Provider Metadata File Path: Provide the path for the NetIQ Access Manager metadata file. It is typically a URL, such as the default https://<YOUR_NetIQ Access Manager_DOMAIN>/nidp/saml2/metadata
•Idle sessions time-out: Define the minutes of inactivity after which a session expires, according to your authentication requirements and expectations (e.g, 5 minutes).
•Organization name: Provide the name of your organization. This is included within the request messages sent by Bizagi.
•Organization URL: Provide the URL of the website of your organization.This is included within the request messages sent by Bizagi.
•Redirect to a logoff page after loggoff process: Check this checkbox if you wish to redirect users to a static logout page when they logout.
•SAML Protocol Binding for SLO: We recommend selecting REDIRECT as supported specifically by Azure.
•SAML Protocol Binding for SSO: We recommend selecting POST so that there is support for longer messages.
•Service provider URL: Provide the full URL for the Bizagi Work portal.
For Automation Service, such URL uses this format:
For on-premises projects, the URL uses this format:
The above URL is case-sensitive. Do not enter anything for [environment]- to reference the Production environment.
•Show detailed authentication error messages: Check this box if you want authentication errors to be shown in a detailed way when they occur.
•Signature certificate password: Provide the password of the digital certificate used for the signing of assertions.
This password should match the one you defined when exporting certificate information in P12 format.
•Signing algorithm: Select either SHA1 or SHA256.
•Signing certificate: Use the Browse button to locate and upload the digital certificate (in P12 format), containing the public and private key that will be used to sign the assertions generated by Bizagi.
•Technical email contact address: Provide an email address for contact with your corporation regarding technical issues.
When you are done, review that your changes have been applied.
Authentication changes may not be reflected immediately. You may need to reset the Bizagi services.
1.4. Perform a reset on your Bizagi services
For on-premises projects, this means executing an IISReset.
Any change in the authentication type, or any of its settings, do not take effect until the cache of the application server is explicitly refreshed.
1.5. Browse for the location of a metadata file that Bizagi generates based on the previous configuration.
To configure NetIQ Access Manager through the next steps more easily, download the metadata file from Bizagi to a local directory so you can use it as input in NetIQ Access Manager.
You can view this metadata file by browsing it as:
Download the file by inputting in the browser:
2. Configure Bizagi as Service Provider in NetIQ Access Manager
You do this in the NetIQ Access Manager admin options.
2.1. Log in to the NetIQ Access Manager Access Manager.
2.2. From the menu select Devices -> Identity Servers -> <YOUR_SERVER>.
Replace <YOUR_SERVER> with the name of your configured NetIQ Access Manager server/cluster.
2.3. Enable the SAML 2.0 protocol for your NetIQ Access Manager server (or servers/clusters).
Check the SAML 2.0 checkbox found in Enabled protocols:
Click OK when done.
2.4. Click new on the enabled SAML 2.0 tab menu.
Select Service Provider from the drop-down options to register Bizagi so that its connection is trusted:
2.5. Fill in:
•Provider type: General
•Source: Metadata Text
•Name: Provide a unique identifier that is clear and describes the purpose of the service. Using Bizagi's URL is good.
•Text: Paste the content of Bizagi's metadata.xml file as produced in step #1.
Click Next when done.
2.6. Confirm the certificate.
Review the certificate's details to make sure they are accurate (the metadata.xml file has the certificate employed by Bizagi). Then click Finish.
2.7. Locate the recently-added Service Provider (Bizagi), and click it.
You can specify which information (attributes) is returned within a response (assertion).
2.8. Locate the Attributes tab. For its Attribute set, select Email.
Use the arrow icons to pass this attribute into the Available list on the right:
Click Apply when done.
2.9. In the Authentication Response tab, select POST for Binding.
Check the Email checkbox and confirm that its Value shows the corresponding email attribute configuration you selected.
Click Apply when done.
2.10. In the upper menu, select the Security -> Trusted Roots tab.
In that tab, import the certificate so that these are localizable at NetIQ Access Manager's trusted key store.
These steps are not always needed if you are not working with self-signed certificates. If this is you case, then you may skip or simply review steps 2.10 through 2.15.
2.11. Click Import... to install the certificate (.cer, or .crt file):
2.12. Use the Choose File button to locate the certificate. Give it a meaningful name in the Certificate name field:
Click OK when done.
2.13. Click Add Trusted Roots to Trusted Store... and select the certificate you just imported to add it to the root trusted store:
2.14. Select your certificate and trusted stores:
2.15. Click OK when done.
You may need to restart your NetIQ Access Manager services.
2.16. In the upper menu, select Devices -> Identity servers -> <YOUR_SERVER>.
You should replace <YOUR_SERVER> with the name of your configured NetIQ Access Manager server/cluster.
2.17. In the SAML 2.0 tab, check the Encrypt assertions checkbox to have NetIQ Access Manager encrypt messages it sends to Bizagi.
Do not check the Encrypt name identifiers checkbox.
Save your changes and exit when done.
You have now configured your NetIQ Access Manager Access Manager to rely on SAML 2.0 for an integrated authentication with Bizagi!