Identify supports a feature called Interceptor, which allows it to map one login to multiple user accounts stored in the same user store – this works equally well in regard to authentication (IdP) and applications (RP).

We believe this feature to be unique among existing federation solutions, and possibly also in terms of identity management solutions, which is quite surprising given that – in our experience – virtually all directory services include at least a few physical users that use more than one user account.

While most Identity and Access Management solutions are built on the notion that each physical user is represented by just one user account, the reality will more often than not prove much more complex. There are many cases in which the management of data, access and rights, demands that the same user needs to be represented by multiple user accounts. A commonly occurring example is when a physical user is represented by multiple Active Directory accounts for security and/or compliance reasons.

The new feature in Safewhere*Identify makes it possible to work seamlessly with e.g. Active Directory (that is, being able to authenticate using the same set of credentials) even when the user has multiple Active Directory accounts. When a user has been successfully authenticated, Safewhere*Identify will look up all the accounts that belong to the user. In case more than one account exists, Safewhere*Identify will interactively offer the user to choose the correct account for the given context. This makes it possible to maintain single sign on between multiple user identities even when these exist in the same stores.

But the interactive user profiles selection applies to much more than just Active Directory. It applies to all types of authentication and protocol connections and represents a unique and important capability for supporting an easy transition to the world of federation

The general settings are:

• Intercept login flow: tick to enable interceptor for the connection.
• Name of the main view which the interceptor should use: fill in the view to show, if empty, Identify will use the default viewProfileList.cshtml.
• Interceptor type name: the external DLL name used for interceptor.
• Interceptor’s dependency type: a dependency type depends on the customer DLL.
• Additional settings: a pair of key and values depends on the customer DLL.

An example of configuring interceptor for the Facebook plugin and the AD Provider user can be found here. The sample external DLL needs to be put to runtime/bin of tested tenant.