Intermediate recommendations

<< Click to Display Table of Contents >>

Navigation:  Bizagi Engine > Bizagi system administration > Bizagi server configuration > Bizagi Engine .NET platform configuration > Security setup recommendations >

Intermediate recommendations



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


In order to carry out the recommendations presented below, note that you should have already followed what described at Basic 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.


Intermediate recommendations

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. Cyphering 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\) in order to cypher cookies.

Include inside of the <system.web> element the following line:

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




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




In that same web.config configuration file of your Work portal, edit the definition for <pages>, so that the ViewState attribute uses cyphering always. What this action targets is to secure that information dictionary as described at

To do so, locate the pages element having:

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

And include:





Save changes and close the file.


2. Including additional protection to Bizagi web services

By default Bizagi will include its built-in web services in the .\WebApplication\WebServices\ folder (inside of 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.


It is strongly recommended to provide an additional layer of security in order 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. a 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

You will first need to separate those internal services and those which provide integration capabilities.

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


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

You may name this folder as 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 you have created:




Once you are done, you may ensure 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

Make sure you configure at the IIS, that the .\WebApplication\SOAPservices\ folder containing those Bizagi's Web services which promote application integration (i.e, WorkflowEngineSOA, EntityManagerSOA, QuerySOA, RenderSOA), 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:




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

For this case, permissions are granted for the SOAPservices folder:




Click Ok to save this configuration.



Recall that you may even leave as inaccessible the business-oriented web services if your project will not be using them (or delete them).

When setting basic authentication for their access, you will need to make sure that your other applications invoking such services will previously consider authenticating.


Set an IP whitelist to access Web services

Make sure you configure at the IIS, that:

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

oThe .\WebApplication\SOAPservices\ folder containing business-oriented web services is set to be accessed 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 for that folder by using the IP and Domain restriction feature in the IIS:





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




Click Ok to save this configuration.


3. Delete unused folders in the production environment

It is recommended that you delete the folders which use is oriented to the development environment.

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


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












Delete as well:

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

The 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 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.



It is also a common practice to set Bizagi Work portal into a different IIS Web site of your choice, other than the one used by default (called Default Web site).

This is part of an additional security measure which targets security by obscurity, and it is entirely optional in your project.

For more information about this possibility, refer to Configuration of the Work Portal outside of the default web site.


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