Bizagi
Bizagi helps organizations to transform into digital businesses. Its process automation platform connects people, applications, devices and information to deliver the engaging experience that. Bizagi’s industry-leading low-code business process modeling and automation platform connects people, applications, robots, and information on a single platform.
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 Okta.
This section is a step-by-step guide to the configuration needed, both in Okta and in Bizagi, to have an integrated authentication in Bizagi against Okta.
For SAML 2.0, both your Identity Provider and your Bizagi project need 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. |
Bizagi Competitors
Prerequisites
To configure Okta 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 (tracking expiration dates and responding to any other maintenance requirements such as 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 (at least one, for testing and verification purposes).
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 user identifier. |
What you need to do
1. Configure in Bizagi the settings that make reference to the specification of your SAML setup.
2. Configure Bizagi as Service Provider in Okta.
Procedure
1. Configure in Bizagi the settings that make reference to 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. In 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 at the bottom right:
Click Update.
You will get a confirmation message. Additional parameters appear under the Authentication item.
If you applied this change into an environment other than development, make sure to apply the same changes in your Development environment. To do this, follow the same procedure using the Bizagi Management Console. |
1.3. Configure the additional parameters as described below. Click Update for each one that you modify.
Parameter values are case-sensitive. Make sure you provide them accurately.
Configure these settings:
•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, Okta 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 Okta, 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 to the Okta metadata file. This location is typically an URL.
However, configuration for this setting with Okta is not done in a single step.
Okta will not issue its metadata file location before Bizagi is configured. As with Bizagi, you generate the metadata file of these settings to use later in Okta.
For now, leave this setting blank in Bizagi, and generate Bizagi's metadata file.
Once you can use Bizagi's metadata file to move on with the configuration in Okta, you can obtain Okta's metadata URL and come back to this option to provide the URL for this setting.
•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 Okta.
•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:
https://[environment]-[project]-[company].bizagi.com
For on-premises projects, the URL uses this format:
https://[server]/[project]
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. We recommend using the SHA256 as the SHA1 is a deprecated algorithm.
•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.
Once you are done, review that your changes have been applied.
Authentication changes may not be reflected immediately; in which case, 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, are not reflected until the cache of the application server is explicitly refreshed.
1.5. Browse for the location of the metadata file that Bizagi generates based on the previous configuration.
To configure Okta more easy in the next steps, Bizagi downloads the metadata file into a local path so you can use it as input in Okta.
You can review this metadata file by browsing it at:
https://[environment]-[project]-[company].bizagi.com/saml2/metadata.xml?mode=preview
Download the file by inputting in your browser:
https://[environment]-[project]-[company].bizagi.com/saml2/metadata.xml?mode=attachment
2. Configure Bizagi as Service Provider in Okta
2.1. Log in with admin rights to your Okta portal.
2.2. Locate the Applications menu and from it to select Applications.
Then click Add Application:
2.3. Click Create New App.
2.4. Provide the following details:
•Platform: Select Web.
•Sign on method: Click SAML 2.0.
Click Create when done.
2.5. Go to the Create SAML integration section.
2.6. Fill out General settings:
•App name: Provide unique name for your app.
•App logo: Select a representative for your app.
Click Next when done.
2.7. Fill out Configure SAML:
•Single Sign on URL: Provide the URL of your Bizagi Work portal followed by the /saml2/assertionConsumer suffix.
For Automation Service, the URL has this format:
https://[environment]-[project]-[company].bizagi.com/saml2/assertionConsumer
For on-premises projects, the URL has this format:
https://[server]/[project]/saml2/assertionConsumer
•Use this for Recipient URL and Destination URL: Check this option.
•Audience URI (SP Entity ID): Provide the URL of the Bizagi Work portal just configured in Bizagi Studio (or the Bizagi Management Console).
For Automation Service, the URL has this format:
https://[environment]-[project]-[company].bizagi.com
For on-premises projects, the URL has this format:
https://[server]/[project]
•Use this for Recipient URL and Destination URL: Check this option.
•Default RelayState: Leave empty.
•Name ID format: Select E-mailAddress.
•Application Surname: Select Email.
2.8. Fill out Show Advanced Settings:
•Response: Select Signed.
•Assertion Signature: Select Signed.
•Signature Algorithm: Select RSA-SHA1 or RSA-SHA256, according to the one configured in Bizagi.
•Digest Algorithm: Select SHA1 or SHA256. We recommend using SHA256 as SHA1 is a deprecated algorithm.
•Assertion Encryption: Select Encrypted.
•Encryption Algorithm: Select AES256-CBC.
•Key Transport Algorithm: Select RSA-1.5.
•Encryption Certificate: Browse for the public certificate for encryption purposes and upload it.
•Enable Single Logout: Select Allowapplication to initiate Single Logout.
•Single Logout URL: Provide the URL of the Bizagi Work portal followed by the /saml2/logout suffix.
For Automation Service, the URL has this format:
https://[environment]-[project]-[company].bizagi.com/saml2/logout
For on-premises projects, the URL has this format:
https://[server]/[project]/saml2/logout
•SP Issuer: Enter the URL of the Bizagi Work portal just as it was configured in Bizagi Studio (or the Bizagi Management Console).
For Automation Service, such URL uses this format:
https://[environment]-[project]-[company].bizagi.com
For on-premises projects, such URL uses this format:
https://[server]/[project]
•Signature Certificate: Browse for the security certificate for signing purposes and upload it.
•Authentication context class: Select PasswordProtectedTransport.
•Honor force authentication: Select Yes.
•SAML Issuer ID: Leave the default value as generated by Okta.
Click Next when done.
2.9. Leave the defaults and empty fields for other options and click Next.
Bizagi Modeler
You can preview how the assertion would be set in runtime:
2.10. In the Feedback tab, you may choose to set:
Bizagi Modeler
•Are you a customer or partner?: Select I'm an Okta customer adding an internal app.
•App type: Check the This is an internal app that we have created checkbox.
Click Finish when done.
2.11. Finally, once the app is created, browse to its details and into the Sign On tab.
2.12. Select the hyperlink labeled as Identity Provider metadata.
You need to copy this URL so that, in Bizagi, you can set the Identity Provider Metadata File Path setting to point to it.