Federated authentication

<< Click to Display Table of Contents >>

Navigation:  » No topics above this level«

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.

 

Benefits

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 corporate application (avoiding multiple login screens of different applications).

Similarly, end users will need to remember a unique 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 with your applications.

When using Federated authentication, passwords are not stored in Bizagi and Identity and access management is done by customers themselves at the identity provider system.

 

4. Providing a best user experience for end users that access your applications from any location or device.

Through federated authentication in Bizagi, desktop, tablets and mobile devices rely on standard web-based protocols that enable a Single Sign-On experience.

 

 

Federated authentication architecture

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

 

Federated Authentication_generic

 

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

 

 

Supported protocols

When using Federated authentication, the SAML 2.0 protocol is supported and highly recommended.

Alternatively, you may choose to use WS-Federation.

 

For more information about how to use Federated authentication along with the SAML 2.0 protocol, refer to SAML authentication.

For more information about how to use Federated authentication along with the WS-Federation protocol, refer to WS-Federation authentication.