Basic hardening

<< Click to Display Table of Contents >>

Navigation:  Automation Server > Automation Server configuration and administration guide > Initial project configuration > Best practices in the production environment > Security hardening at the IIS >

Basic hardening


This section presents security recommendations to apply in Bizagi Work portal, regarding aspects which are relevant to Bizagi's configuration (application hardening).

Recall that you should be in charge of ensuring security in access and configuration of your premises and equipment, appliances or components involved in the complete solution which are not per se part of Bizagi (i.e the system architecture), such as: the network and storage, firewalls, load balancers or other appliances, and other servers such as domain controllers or database servers, etc.


For more information regarding these recommendations' scope, refer Security setup recommendations.



The following recommendations apply when Bizagi runs in a .NET platform, independently from the Web server IIS version on which it runs.

In this section, recommended configuration is described by taking as an example an IIS Web server version 7.5, and such hardening is carried out according to the IIS capabilities.


Before you start

Make sure you keep in mind the following considerations before moving on.


Considerations regarding the platform

Keep in mind that you should always consider and apply those recommendations issues by Microsoft as the vendor of the base platform on which Bizagi runs for .NET environments.

Consider bulletins and notifications about fixes and patches announced by Microsoft regarding your Windows OS or the IIS.

When you do, keep in mind that you should carry out proper tests as well and verify you are not affecting your Bizagi project.


Considerations regarding the database

For a higher level of security regarding data access, Bizagi presents the possibility to configure the service account which is used to configure database access by the Work portal (and the scheduler service) having the minimum required rights.

For more information about the setup of these accounts, for instance when using SQL Server, refer to SQL Server requisites.


Considerations regarding authentication in Bizagi

Before you continue with the web-related configuration recommendations for the Work portal,, make sure you use in whichever authentication scheme you setup for your project, the use of security policies for passwords (where you consider password formation and length, their duration, and other elements for protection and compliance for these).

When using the Bizagi local type of authentication, configure the relevant parameters to cover such policies, as described at Bizagi authentication.


It is recommended to set up as minimum the following parameters:

Enable Lock Account: On

Enforce Password change: On

Enforce Password History: On

Log Authentication Events: On

Max Logon Attempts: 3

Password expiration time: 30 days, or according to your criteria.

Password minimum length: 8 characters, or according to your criteria.

Password must have letters: On

Password must have capital letters: On

Password must have small letters: On

Password must have numbers: On

Password must have special characters: On

Session Time: 5 minutes.

Verify Password Sequences: On

Password block time: According to your criteria.

Blocked account duration: According to your criteria.

Duration to restart failed attempts: According to your criteria.


Considerations regarding the system user in Bizagi

Recall that the domain\admon is the system user employed internally by Bizagi (created by default).

You may not disable this user since it is needed to perform automatic tasks such as timers or scheduled jobs, and it is recommended that you ensure that such user is always enabled in your project.

Though, note that it is strongly recommended to edit this user's setting so that it is not set with rights to access administration options at the Work portal (it should be a user capable of starting specific processes and running tasks, but not a full admin).

To ensure this for instance, you may exclude this user from those authorized to manage your Bizagi system (i.e this user should not be able to manage users, nor modify values in Bizagi such as parameter entities, abort cases, etc).



Basic recommendations

Follow the configuration recommendations which mitigate most of the vulnerabilities.

These apply to your testing or pre-production environment as well (when using one).




For the next described steps, make sure you have installed the IIS component called World Wide Services -> Security -> Basic Authentication, and IP and Domain restrictions (when installing the IIS).


1. Using the HTTPS protocol

It is strongly recommended to configure your Bizagi Work Portal using the HTTPS over SSL protocol.

To do this, ensure you have a valid certificate for your server which registers to your server's domain.


Once you have a valid certificate for your server, register it for Bizagi Work portal by using the Server certificates option for the IIS Server:




Once registered, make sure that you specify the bindings at the Work portal's web site (by default, at Default Web site):




Notice that for the bindings, you will be able to specify HTTPS use, with its secure port, and select the registered certificate.

Click Ok to save this configuration.



When using HTTPS, consider editing the web.config file to specify <add key="PROTOCOL" value="HTTPS"/>.

This applies when using case links in process notifications, as described at Notifications using case links.


2. Filtering unauthorized requests

It is recommended to identify the gateway from which your end users access Bizagi Work portal.

This way, you can use a range of valid IP addresses to filter HTTP requests to your application.


To do so, explicitly include a white list of IP addresses authorized to access Bizagi Work portal at the site level (note you may even specify an authorized domain).

Use the IP Address and Domain restrictions option:






Similarly, you may rely on Web Application Firewall products to harden the security to access Bizagi (to rely on additional features such as those oriented to intrusion detection, etc, and to consider additional corporate policies to secure your application especially when having Bizagi setup for internet access).


When using a DMZ, ensure that both the inside firewall and the outside firewall do not allow indiscriminate access through firewall configuration and ports.



For Bizagi, security is an aspect of critical importance.

Therefore, Bizagi releases periodical new versions which feature multiple improvements and fixes for issues detected in previous versions.

Fixes for those detected issues may include definitive solutions for security vulnerabilities.


It is strongly recommended to consider a periodical upgrade in your solution to Bizagi's newest releases, by always following the usual guidelines for an upgrade procedure such as:

Plan, coordinate and test appropriately these upgrades.

Rely on the different environments (development, testing, pre-production when applicable, and production).

Previously take proper contingency measures (e.g backups).

Evaluate customizations or additional security configurations such as the ones listed above, so that stakeholders are aware that it is part of the plan to reconfigure certain aspects after the upgrade.



When having customizations or applying hardening measures such as the ones above, one of the two alternatives needs to be followed when carrying out a version upgrade:


1. If doing this through Bizagi Management Console, you will need to reconfigure and verify that such measures are still applied after the upgrade (and backing up customizations before doing so is recommended).

Note that by default, the upgrade done by the Management Console will not consider if you have done modifications to the original files and file structure.


2. You may choose to do this through a manual procedure (without using Bizagi Management Console).

If you do, make sure you consider all the relevant components and files that you need to replace manually for the Work Portal and Scheduler, while avoiding overwriting your configured customizations or the already applied hardening measures.


For highly critical security issues, Bizagi may consider issuing hot fixes and recommend to apply them without the need to await for a newer version.


To evaluate or consider additional application hardening aspects, refer to the Intermediate recommendations.