About federated authentication

Overview

Blueprint's federated authentication provides on-premise and cloud customers with the ability to leverage their existing identity provider to authenticate users in Blueprint. In other words, after a user has authenticated with your identity provider, Blueprint does not require a username and password to access the system.

What is federated authentication and SAML?

Federated authentication is the practice of allowing an external system to provide authentication services for another application. This goes beyond acting as a repository for credentials, but actually acting as the system which validates authentication attempts. One example of a federated authentication technology includes SAML.

SAML (Security Assertion Markup Language) is a technology used to implement federated authentication and single sign on (SSO). SAML provides a secure, XML-based solution for exchanging user security information between an identity provider (your company) and a service provider (Blueprint).

How it works

With federated authentication, no direct connection is required between Blueprint and the identity provider:

When the client accesses the service provider (that is, Blueprint), Blueprint requests that the client identifies itself through SAML. The user authenticates with the identity provider, which in turn returns an assertion (that is, a token). This token is then sent to Blueprint as proof of successful authentication and identity.

System requirements

This section outlines technology requirements and variables that are needed in order to configure federated authentication.

Federated authentication technology requirements

Blueprint supports the following federated authentication technologies:

• SAML 2.0 Token and Protocol
• Service Provider Initiated Login (Required)
• Identity Provider Initiated Login (Optional)
• SHA1 and SHA256 Signature Digests

Required variables

Identity provider requirements

• The Entity ID must be set to:

  <Blueprint_URL>/Login/SAMLHandler.ashx

  where <Blueprint_URL> is your main Blueprint URL.

  Example

  For Blueprint cloud customers, the Entity ID will look something like this:

  https://acme.blueprintcloud.com/Login/SAMLHandler.ashx

  For Blueprint on-premise customers, the Entity ID will look something like this:

  https://blueprint.acme.com/Login/SAMLHandler.ashx

• The POST Endpoint must be set to:

  <Blueprint_URL>/Login/SAMLHandler.ashx

  where <Blueprint_URL> is your main Blueprint URL.

• A Username attribute must be included in the SAML response (that is, the token).

  Blueprint reads the username from the Username attribute in the token (not the Subject). The name of this attribute must be Username. The username can be in the format you want, but must match the usernames as created in Blueprint. Valid options are regular usernames, Windows/AD account names (DOMAIN\user), e-mail addresses, Distinguished Names, or x509 Subjects.

• The SAML response must contain the identity provider certificate (x509).

Federated authentication settings requirements

After configuring your identity provider to work with Blueprint, you must enable federated authentication in Blueprint.

You must provide information for the following fields:

• Login URL: Defines your Identity Provider Login Service URL. This is the URL that Blueprint navigates to when the user clicks the Go button on the login screen. At this time, the Identity Provider returns a authentication token to Blueprint to authenticate the user.

  Example: https://idp.domain.com/adfs/ls/

• Logout URL: Defines the URL to navigate to after a user clicks the Logout button in Blueprint. This behavior is not applicable if a user is logged in with fallback authentication.

• Error URL (optional): If a token error occurs, the user is redirected to the specified URL. The specific error is included as a GET parameter in the URL.

  If an Error URL is not provided, Blueprint displays the token errors in the popup window.

• Login Prompt (optional): Defines the login text that appears on the login screen when Federated Authentication is enabled:

  

  The default text is:

  Login with Corporate Credentials

• Customize electronic signature prompt (optional): Defines the text that appears on the electronic signature message when Federated Authentication is enabled. If you require signatures for the review process, users are asked to confirm their identity in order to approve or reject an artifact. When federated authentication is enabled, users will be able to use this federated identity to sign off.

Example setup

Jamal, an IT administrator, is setting up federated authentication for a company (called BP Airlines) using the Blueprint cloud instance.

First, Jamal makes sure the identity provider is configured properly, like so:

Next, Jamal configures the Federated Authentication Settings in Blueprint (Instance Administration Console, Configure Settings section). He selects Enable Federated Authentication and uploads a new certificate. Jamal also specifies values for the Login URL (defines the identity provider service URL) and the Logout URL (the URL users navigate to after clicking the Logout button):

After the setup is complete, Jamal's chosen implementation allows cloud customers to forgo the default log-on process with the click of a link.

User flows

Service provider initiated login

1. User navigates to the Blueprint login screen.

2. User clicks the Go button.

3. User logs in with corporate identity (if not already authenticated)

The user is authenticated and can begin using Blueprint.

Identity provider initiated login

Identity provider initiated login is very flexible and may vary drastically depending on your chosen implementation. For demonstration purposes, here is a common implementation of identity provider initiated login:

1. User navigates to a company Intranet webpage.

2. User clicks a Blueprint link.

3. Blueprint is loaded and authenticated automatically.

The user is authenticated and can begin using Blueprint.

Expired session

Expired sessions can happen for both service provider initiated login and identity provider initiated login.

An expired session can happen for a variety of reasons:

• session timeout: the session has timed out due to inactivity

• session override: the user has overridden the session by logging in at a different location

Here is the typical user flow when a user encounters an expired session:

1. User is presented with a dialog explaining the session has expired

2. User clicks OK.

3. User is re-authenticated automatically, assuming the user is still authenticated with the identity provider. If the user is not still authenticated with the identity provider, the user is prompted to re-authenticate with the identity provider.

The user is re-authenticated and can continue using Blueprint.

Configuration

Setting up Blueprint federated authentication is a two step process:

• Step 1: Configuring your identity provider for Blueprint federated authentication
• Step 2: Enabling Blueprint federated authentication

Tasks

Configuring your identity provider for Blueprint federated authentication

Enabling Blueprint federated authentication

Learn More

Instance Administration

Managing Active Directory settings

Blueprint Documentation|Blueprint eLearning|About Blueprint ©2018 Blueprint Software Systems Inc. All rights reserved Last updated: 4/18/2018