Federated Authentication

<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio > Security definition > Work Portal Security > Authentication > Advanced Authentication >

Federated Authentication

Overview

Bizagi supports integration with an Identity provider featuring federation services.

This way, in Bizagi you may rely on Single Sign-On capabilities and entrust the authentication to your corporate Identity provider (i.e Active Directory Federation Services, Ping Federate).

 

When using Federated authentication, outstanding benefits for your organization are:

1. Presenting a single and unified login screen to your end users, when these access any application of your corporate domain (avoiding multiple login screens of different applications).

Similarly, end users will need to remember a single login account and its password (avoiding multiple login accounts and multiple corresponding passwords).

 

2. Centralizing your users repository and its authentication system.

This automatically reduces the administration overhead produced when you have multiple authentication systems due to the periodical tasks needed (handle idle accounts, reset passwords, etc).

 

3. Enforcing security policies.

By having a central user repository and authentication system, you may enhance security measures in it and strict security policies (i.e for passwords, account characteristics and profiles, etc), and rely on the secure protocols such as HTTPS for the communication between your corporate domain applications.

 

 

 

Federated authentication architecture

The following image illustrates the  system architecture involved when using federated authentication..

 

Federated Authentication

 

Notice in the above scheme:

That your Identity provider (or Identity Assertion Provider) 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 at least 2 valid certificates (one for your identity provider and one for your service provider).

Certificates for this use are known as SSL Server certificates (from this point on this is how we will address them).

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

You may use the same pair of SSL Server certificates to sign off assertions.

Or, you may also choose to use a different pair of additional certificates for signing and encryption purposes (one for your identity provider and one for your service provider).

What you need to consider for this choice is that your certificates should specify the exact name of your server and its domain.

 

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.

For WS-Federation, a discovery of the service takes place.

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

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 -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 or the SAML 2.0 standard (i.e Active Directory Federation Services, Ping Federate).

 

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 server certificates (up-to-date and issued by a certificate authority).

 

 

note_pin

Certified and recommended versions to use Federated Authentication in Bizagi are:

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 Configure the Identity provider to work with Bizagi.

 

2.  Configure the authentication parameters in Bizagi.

For more information about this step, refer to Configure the authentication parameters in Bizagi.

 

 

Important

For any type of authentication, you will need to ensure that users are created at Bizagi Work portal.

Disregarding the selected Authentication type for your Work Portal login, you may choose to configure a schedule in Bizagi to import and synchronize users from your LDAP Server into Bizagi.

For more information about this option, refer to Importing LDAP Users.