Intermediate 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 >

Intermediate hardening


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


To carry out the recommendations presented below, you should have already followed what is described in Basic recommendations.



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

This section describes the recommended configuration for an IIS Web server version 7.5, and such hardening is carried out according to the IIS capabilities.


Intermediate recommendations

These apply to your testing or staging environment as well.



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


1. Encrypting information using HTTPS

Include the following element in the web.config file of your Work portal (by default, located at C:\Bizagi\Projects\[your_project]\WebApplication\) to encrypt cookies.

Include in the <system.web> element the following line:

<httpCookies httpOnlyCookies="true" requireSSL="true" />




You may verify the proper configuration by logging to the Work portal and using a tool of your choice to inspect how cookies are obtained (e.g. by means of Google Chrome's developer tools):




In the same web.config configuration file in your Work portal, edit the definition for <pages>, so that the ViewState attribute always uses encryption. This action secures the information dictionary as described at

To do this, locate the pages element having:

<pages controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID" />

And include:





Save the changes and close the file.


2. Including additional protection in Bizagi web services

By default Bizagi includes its built-in web services in the .\WebApplication\WebServices\ folder (inside the default path at C:\Bizagi\Projects\[your_project]\).

There are two types of web services published at this location: business-oriented web services which make up Bizagi's API, and web services which provide functionality used internally by Bizagi.


We strongly recommend that you provide an additional layer of security to restrict access to these web services, and to use separate folders for the two types of web services to implement different security measures for each.

You may even leave as inaccessible the business-oriented web services if your project will not be using them.

Even though you should use HTTPS configuration, you should explicitly configure the web services' folder and access with the measures described in the table below.


Service type


Web services for internal purposes of Bizagi

Define an IP whitelist which only includes the local Bizagi server's IP, as an authorized server allowed to access these web services..


Web services which are part of Bizagi API (business oriented)

Define an IP whitelist which only includes the identified and authorized external servers (or an IP range), as those allowed to invoke web services in Bizagi.

Configure basic authentication to access these web services. This way, external application would need to authenticate prior to invoking web services in Bizagi.


To do this, follow these steps:


Separate the Web services

Separate those internal services from those which provide integration capabilities.

Internal Web services are: Cache.asmx, WFEQuery.asmx and WFAsynch.asmx.


To do this, create a new folder in the Web application's structure provided in Bizagi's Work portal (by default at C:\Bizagi\Projects\[your_project]\WebApplication\).

You can name this folder SOAPservices (or a different name of your choice):




Move all of the files located at the .\WebApplication\WebServices\ folder except Cache.asmx, WFEQuery.asmx and WFAsynch.asmx, into this new folder:




Once you are done, verify that only Cache.asmx, WFEQuery.asmx and WFAsynch.asmx, are still located at the .\WebApplication\WebServices\ folder.


Set Basic authentication for the Web services for integration

Configure the IIS, so the .\WebApplication\SOAPservices\ folder containing Bizagi's Web services which promote application integration (i.e, WorkflowEngineSOA, EntityManagerSOA, QuerySOA), uses basic authentication.

Through this setting, external applications invoking these services will need to specify basic authentication credentials (user, password).


To do this, enable Basic Authentication and make sure Anonymous authentication is disabled for that folder:




Make sure that users allowed to access this content are granted privileges to its physical path (according to your registered domain).

For this grant permissions for the SOAPservices folder:




Click OK to save this configuration.



You can even leave as inaccessible the business-oriented web services, or delete them, if your project will not use them.

When setting basic authentication for web service access, make sure that your other applications invoking such services will be able to authenticate.


Set an IP whitelist to access Web services

For the IIS configure that:

oThe .\WebApplication\WebServices\ folder containing Cache.asmx, WFEQuery.asmx and WFAsynch.asmx, is accessible only by authorized IP addresses (in this specific case, only by the local server).

oThe .\WebApplication\SOAPservices\ folder containing business-oriented web services is accessible only by authorized IP addresses or an IP range of addresses (in this specific case, those IPs belonging to the external application invoking Bizagi).


To do this, include each allowed IP address explicitly by using the IP and Domain restriction feature in the IIS:




For the whitelist approach to work, make sure that your default feature settings deny access for unspecified clients (choose Deny):




Click OK to save this configuration.


3. Delete unused folders in the production environment

We recommend that you delete the folders whose use is oriented to the development environment.

This action is to avoid leakage of code information (a vulnerability known as Source code leakage).


You may delete the following folders located inside the jQuery folder (by default C:\Bizagi\Projects\[your_project]\WebApplication\jquery):












Delete as well:

Readme.txt located at the desktop templates (by default at C:\Bizagi\Projects\[your_project]\WebApplication\jquery\overrides\templates\desktop\Readme.txt).

Login.aspx located at the Admin folder (by default at C:\Bizagi\Projects\[your_project]\WebApplication\Admin\Login.aspx).



For Bizagi, security is an aspect of critical importance.

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

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


We strongly recommend that you consider a periodic 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 all upgrades.

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

Take proper contingency measures (e.g. backups) before starting the update.

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



When you have customizations or applying hardening measures such as the ones above, follow one of two alternatives when carrying out a version upgrade:


1. If upgrading through the Bizagi Management Console, reconfigure and verify that such measures are still applied after the upgrade (we recommend backing up customizations before starting the upgrade).

An upgrade done through the Management Console will not check whether you have done modifications to the original files and file structure.


2. You may upgrade through a manual procedure, without using the Bizagi Management Console.

If you do, 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 issue hot fixes and recommend that you apply them without waiting for a newer version.


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