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.
If you plan on using an authentication method different than Bizagi and you are performing a deployment to an environment with no users on it (normally this would only be the case for a project's first deployment), follow these steps so that you can correctly configure your users and authentication without getting locked out of the Work Portal:
1.Perform the deployment with the authentication method set to Bizagi. This lets you access the Work Portal as the Admon user without providing any credentials.
2.Once in the Work Portal you can manually enter your users, or alternatively you can rely on the method of your choice to synchronize your users' information into the WFUser table (SOAP, Excel file, LDAP Synchronization, or performing a Data Synchronization procedure).
3.Perform an IISRESET so that the Admon user can no longer access the Work Portal.
4.After having your users registered in the Work Portal, use the Management Console to set the authentication method to your preferred one.
If you plan on using LDAP authentication with periodic users synchronization, you may ignore the previous steps since you will only need to wait until the next synchronization happens for your users to be able to log into the Work Portal.
1. Generate certificates to sign assertions (mandatory)
This step is not bound to Bizagi nor restricted by any special requirement of Bizagi (you normally do it yourself).
If you need some guidance or an example on this step, refer to Certificates for SAML 2.0 authentication.
To proceed with these guided steps, you need to have:
•One certificate to sign assertions (mandatory) in .P12 or .PFX file format. You need The password for the certificate file, as defined by you when you exported the public and private keys.
•One certificate to encrypt messages (optional) in .P12 or .PFX file format. You need The password for the certificate file, as defined by you when you exported the public and private keys.
You will need to be in charge of managing your installed certificates (keep track of its expiration date and other relevant maintenance aspects such as changes in your Identity Provider's endpoints).
After you configure the application in Azure AD, now you must access the Bizagi Studio or the Management Console and register the Identity Provider. Follow the steps in Configure a SAML 2.0 IdP in Bizagi.
3. Download the Bizagi metadata file
After you configure the identity provider in Bizagi, you must generate the metadata file. Refer to Download the metadata file.
4. Configure Bizagi as Service Provider in NetIQ Access Manager
You do this in the NetIQ Access Manager admin options.
4.1. Log in to the NetIQ Access Manager Access Manager.
4.2. From the menu select Devices -> Identity Servers -> <YOUR_SERVER>.
Replace <YOUR_SERVER> with the name of your configured NetIQ Access Manager server/cluster.
4.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.
4.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:
4.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 #3.
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.
4.7. Locate the recently-added Service Provider (Bizagi), and click it.
You can specify which information (attributes) is returned within a response (assertion).
4.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.
4.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.
4.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.
4.11. Click Import... to install the certificate (.cer, or .crt file):
4.12. Use the Choose File button to locate the certificate. Give it a meaningful name in the Certificate name field:
Click OK when done.
4.13. Click Add Trusted Roots to Trusted Store... and select the certificate you just imported to add it to the root trusted store:
4.14. Select your certificate and trusted stores:
4.15. Click OK when done.
You may need to restart your NetIQ Access Manager services.
4.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.
4.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!
Now when you run the Work Portal, Bizagi displays the IdP log-in page and users can be authenticated with your Identity Provider.
Remember to do this configuration in all your environments, or to deploy security configurations in your target environments, for example, test or production environments.