A typical login flow of Safewhere*Identify is Service Provider (SP) -> Identify -> Identity Provider (IdP). When user tries to access to a SP likes a website that requires login, the website will direct user to Identify, which will redirect user to the selected Identity Provider such as Facebook to login.

When someone has logon to an IdP, the IdP will return an information package of user to Safewhere*Identify. Safewhere*Identify uses that blueprint to build up a Principle accordingly. A Principle might comprise of many Claims, which are statements that 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 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 admin to customize and control the Principle’s “content”.

The following use-case will better demystify preceded concepts.

Jack picks Facebook as his IdP. After logon, Facebook issues his identity as 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 makes 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