Configure ADFS using WS-Federation 1.0


<< Click to Display Table of Contents >>

Navigation:  Automation Service Management > Accessing Portals and Applications > How to manage Identity Providers > WS-Federation 1.-0 examples >

Configure ADFS using WS-Federation 1.0



To integrate your Customer Portal with your corporate ADFS carry out the configuration steps described in this section.

These steps are done only once, typically by an admin user of Customer Portal having access to your ADFS system.



We recommend considering using the SAML 2.0 protocol before using WS-Federation. See Configure ADFS using SAML 2.0.


Once you have carried out these steps users sign in to any cloud-based service directly via your ADFS, as described at Signing in the Bizagi Cloud Portals and Applications.


Before you start

The Customer Portal and cloud-based services supports ADFS using the WS-Federation protocol. Other protocols are not supported. The WS-Federation supported version is 1.0. Other versions are not supported.

Additionally you need:


To have already users into the Customer Portal

When integrating any Identity Manager, you need to synchronize authorized accounts so they can access Bizagi 's cloud-based portals.

Synchronizing means importing or updating the account's primary identifiers. The Bizagi's account email must match with the attribute considered as the identifier in ADFS. See Create company users.


Bizagi does not store passwords when integrating an Identity Manager.



You cannot have two or more users with the same email, because it is considered as part of the primary identifier.


Once you have verified in the Customer Portal that there has been at least an initial import of your users into Bizagi, you may proceed.


Review ADFS compatability

Before you get started, make sure that your ADFS system complies with these requirements:

ADFS version 3.0 and 4.0 are supported.

The ADFS is accessible via a public URL.


What you need to do

Here are the steps for configuring Bizagi for sign-in using ADFS:

1.Create relying party trust

2.Configure ADFS in the Customer Portal



Follow these steps to integrate the Customer Portal with your ADFS, after you've created the company users in the Customer Portal:


1. Create relying party trust

To set the trust relationship between cloud platform services (the relying party) and your ADFS, create a relying party trust.


Click Add a trusted relying party.




Click Start.


Select the Enter data about the relying party manually option to specify the data source.




Click Next.


Specify the display name and description.




Click Next.


Configure the certificate for token encryption purposes as an additional security measure (optional).

You can skip this step and click Next.




Configure the URL by selecting the Enable support for the WS-Federation protocol.

Specify the following URL: https://accounts-[your_company]




Click Next.


Configure the identifiers using the same URL specified above.

This URL should appear under the identified/valid URLs.

If you need to input another URL with a different identifier, enter this URL and use the Add button.




Click Next.


Configure the Issuance Authorization rules by choosing the Permit all users to access this relying party option.




Click Next.


Review the configuration.

Browse the summary of the configuration you carried out for this relying party trust.

When you are sure that you do not need to make changes, click Next.




Create the Claim rules for this trust by selecting the Configure claims issuance policy for this application.

This way, upon trust creation you immediately create a claim rule and finish the configuration.




Click Close.


In the ADFS console tree, open the Relying Party Trust and select the client previously created. Right-click the client and select Edit Claim Issuance Policy.



Create a claim rule using the Add Rule. button.




Make sure you can send UPN, Email address and Name as information within the claim that is passed into the Customer Portal.

For instance, you can create a new claim rule by choosing the Send LDAP Attributes as Claims template:




Click Next.


Configure the rule by giving it a name, and explicitly including:

Attribute store: Attribute Directory.

Mapping of LDAP attributes to outgoing claim types, including:

oUser-Principal-Name mapped to the UPN

oEmail-Addresses mapped to the E-mail Address.



Bizagi considers the following priority in the assertions:

1. UPN

2. Email


Both UPN and Email Address must be in email format:  [name]@[provider].[domain]. For example


For the UPN claim type make sure that the email is defined as the user name.




Click Finish.

You should have a registered claim rule for your specific relying party configuration.

Once you have verified this is correct, click OK.


Set the Secure Hash Algorithm in ADFS 3

If you are using ADFS 3 make sure that the Secure Hash Algorithm is SHA-256. To change that, right-click the client created previously and select properties.  Click the Advanced tab and select SHA-256 as the Secure Hash Algorithm.


2. Configure ADFS in the Customer Portal

To configure ADFS as your Customer Portal's Identity Provider, you need to access the Customer Portal as a company administrator, select the Settings Icon, open the Protocols menu, and click Add authenticator.




Select the WS-Federation option in the protocol drop-down list, and configure these settings:

Display name: name of the authenticator displayed in the Customer Portal.

Description: Brief description of the authenticator.

Metadata Address: This is the ADFS federation metadata URL. This URL must be accessed via HTTPS while the authenticator is active. This URL must allow downloading the XML metadata file.




Define the domains

If you need to activate multiple authenticators, you can define the email domains associated with each authenticator. See Multiple authenticators for cloud-based portals.


Finally you need to activate the authenticator Before activating the new authenticator, review carefully your configuration settings. Bizagi displays a warning message when activating the protocol.




To test your configuration we recommend that all users log out and opening a new tab using incognito mode, or use a different browser. If the configuration with a new IdP fails, you can Restore the authentication protocol.