WS-Federation authentication

<< Click to Display Table of Contents >>

Navigation:  » No topics above this level«

WS-Federation authentication

Overview

Bizagi supports authentication against an ADFS by means of the WS-Federated protocol.

Consider that you may also authenticate with ADFS by relying on the SAML 2.0 protocol (recommended).

To review how to rely on SAML 2.0, which is a more robust and adopted standard, refer to SAML authentication.

 

ADFS integration

The following image illustrates how Federated authentication works when using Bizagi and your own identity provider.

 

Federated Authentication

 

Notice in the above scheme:

That your Identity provider (or Identity Assertion Provider), in this case the ADFS, is responsible of providing the authentication through standard assertions and security tokens.

Bizagi is set up as a Service provider, which entrusts the authentication to the Identity provider by having a predefined trust relationship with it (Bizagi becomes in this scheme what is known as a Relying party).

While using Federated authentication, passwords are not stored in Bizagi and the system architecture relies on HTTPS secure protocols to send assertions.

For HTTPS, you need a valid certificate for your identity provider.

Certificates for this use are referred to as SSL server certificates (and from this point on as such they will be mentioned)

Valid certificates (i.e for your production environment) need to correspond to server certificates as issued/recognized by a valid Certificate Authority (CA).

You would use the same server certificates employed for the SSL/TLS protocol, to sign off assertions.

 

Sequence diagram

Federated authentication works in detail, as explained below:

 

Federated Authentication Sequence

 

1. End users access Bizagi through any given device.

2. Identity provider service is identified by having such endpoints configured in Bizagi.

3. Bizagi redirects the authentication against the identity provider.

4. The end user sees a login page and authenticates to the entrusted identity provider (when not authenticated yet).

5. Proper identification of that user for a registered domain takes place.

6. The identity provider responds with an XHTML form (sends an assertion with token).

7. The end user's request will proceed to go back to Bizagi this time with a token that certifies its authentication.

8. Bizagi redirects to the initial requested resource/page.

9. The request is processed accordingly.

10.The end user accesses that resource page.

 

Prerequisites

Before you move on, make sure:

 

1. You have a setup Identity provider which supports the WS-Federation Passive Protocol such as Microsoft ADFS.

While using the WS-Federation protocol, Bizagi will rely on a SAML 1.1 token.

 

2. Both your Identity provider and your Bizagi Work portal is setup using the HTTPS protocol.

You will need to have the corresponding valid SSL/TLS server certificate for this (up-to-date and issued by a Certificate authority).

When signing off the certificate to send it off to Bizagi, Bizagi supports using the SHA-256 algorithm.

 

note_pin

The recommended version to use Federated Authentication in Bizagi is ADFS version 3.0.

 

What you need to do

To configure federated authentication for your Bizagi project, follow these steps:

 

1.  Configure the Identity provider to work with Bizagi.

For more information about this step, refer to ADFS configuration.

2.  Configure the authentication parameters in Bizagi.

For more information about this step, refer to Parameters configuration.