Overview
Bizagi supports integration with Identity and Access Management systems (i.e, Identity Managers or Identity Providers) which are SAML 2.0 compliant, such as Microsoft ADFS.
This section is a step-by-step guide to configuring in ADFS and in Bizagi to have an integrated authentication in Bizagi against ADFS.
For SAML 2.0, both your Identity Provider and your Bizagi project must be set up to support HTTPS.
For introductory information about SAML 2.0, refer to Authentication via SAML.
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). |
2. Configure your IdP in Bizagi
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 ADFS
Do this in the admin options in ADFS.
4.1. In your ADFS server, open the administration console.
4.2. Launch the creation of a relying party trust.
Right-click Relying party trust to display the options menu, and select the configuration wizard:
Click Start.
4.3. Select the data source.
To configure the relying party, select the Import data about the relying party from a file option and browse for the metadata file generated by Bizagi.
4.4. Select the metadata file.
Make sure you locate Bizagi's metadata.xml file.
Click Next when done.
4.5. Enter a unique name.
Give a display name to this configuration, for your convenience.
Click Next when done.
4.6. Skip multi-factor authentication.
Select the I do not want to configure multi-factor authentication settings for this relying party trust at this time option and click Next.
4.7. Choose issuance authorization.
Select the Permit all users to access this relying party option and click Next.
You see a summary of the information to set for this relying party trust, including the information that came from Bizagi's metadata file.
You may click Next when done.
You may also check (in the Advanced view) that the algorithm set for this use (either SHA1 or SHA256), matches the one configured in Bizagi.
4.8. Open the Claim rules editor.
Before you close the actual configuration window, check the Open the Edit Claim Rules dialog for this relying party trust when the wizard closes checkbox.
Then click Close.
4.9. Define a new claim rule by clicking Add Rule.
4.10. Select the Send Claim Using a Custom Rule template.
Click Next when done.
4.11 Create the following rules:
Rule 1
•Rule name: email
•Custom rule: c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"), query = ";mail;{0}", param = c.Value);
Rule 2
•Rule name: nameid
•Custom rule: c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress");
When you are done, your newly created rules are displayed as shown in the image below.
The rule may not be recognized right away. If so, delete the rule, create it once again and restart the ADFS server.
At this point you have configured your ADFS to rely on SAML 2.0 for an integrated authentication with Bizagi!
You will need to carry out the next part only if you have employed self-signed certificates.
Additional step for self-signed certificates
If you have issued and installed a self-signed certificate for your ADFS for signing and encrypting purposes, you will need to perform the following:
1.Access your ADFS server and open a PowerShell console.
2.Enter the following command:
Get-AdfsRelyingPartyTrust -Identifier [relying_party_trust] | Set-AdfsRelyingPartyTrust
-SigningCertificateRevocationCheck None -EncryptionCertificateRevocationCheck None
Replace [relying_party_trust] accordingly to the unique name given at the configuration above (when you register Bizagi's relying party trust).
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. |