Claim Pipeline Process

A typical login flow of Safewhere Identify is Service Provider (SP) -> Identify -> Identity Provider (IdP). When a user tries to access an SP, for example a website that requires login, the website directs the user to Identify, which redirects the user to the selected Identity Provider, such as Facebook, to log in.

When a user logs in to an IdP, the IdP returns an information package for the user to Safewhere Identify. Safewhere Identify uses that blueprint to build up a Principle accordingly. A Principle might be composed of many claims, which are statements that the user makes about himself to an IdP. A user can claim about many things, such as first name, last name, email address, or his role in an organization, for example.

To satisfy all of the SP's requirements, a Principle might need to go through a claim pipeline that is a set of Claim Transformations-which function as rules. The procedure allows administrators to customize and control the Principle's "content".

The following use case better demystifies the preceding concepts.

Jack picks Facebook as his IdP. After login, Facebook issues his identity as the following:

Based on that information, Safewhere Identify creates a Principle of Jack-Principle 1:

The SP-in our specific case-requires Principle 1 to go through a claim pipeline that contains two Claim Transformations.

Claim transformation 1: Use email to search details of organization and different business roles in the local Active Directory, thus creating Identity 2 of Principle 1:

First Name: Jack
Last Name: Pham
Email: jack@identify.com
DOB: 15-04
Organization: Safewhere
Role: Business Analyst + Project Manager

Claim transformation 2: SP only needs some figures. The output-Principle 2-will therefore be:

Last Name: Pham
Email: jack@identify.com
Organization: Safewhere
Role: Business Analyst + Project Manager