System concepts


Safewhere*Identify is a web-based system for handling user identification and administration centrally and external to all web applications and web services of an organization or federation. The following article assumes that you already have a general idea of the purpose of federated user and security management and will try to give some more specific ideas of how Safewhere*Identify manages this area by introducing some of the most central concepts of the system.



Safewhere*Identify offers the running of multiple tenants. I.e. the system makes it possible to have separate installations of Safewhere*Identify that can run simultaneously on the same servers. These tenants can interact with each other in both roles as Identity Providers (IdPs) and Relying Parties (RPs).

3 main components of Safewhere*Identify

It may be tempting to call Safewhere*Identify an Identity Provider. But that is incorrect for two reasons. First of all, Safewhere*Identify actually consists of three applications that all use the same database; these three applications are called Identify*Admin, Identify*Runtime, and Identify*UserProv. The latter is not described in the this article, but fundamentally it is a more advanced version of the self-service functionalities offered in Identify*Admin.

Identify*Admin will in fact always function as a Relying Party using Identify*Runtime as an Identity Provider. This relationship is both confusing and obvious at the same time. In order to set up information for Identify*Runtime to support its identity management purposes, we have created the application called Identify*Admin. They both use the same database, but with two different objectives in mind. Identify*Runtime contacts the database to process token requests whereas Identify*Admin contacts it to update the information that enable token requests to be processed.

This abstraction can be a bit tricky, but try to see Identify*Admin as a system that does in fact not itself have access management. When a user wants to get access to handle data in Identify*Admin, then the system must ask Identify*Runtime for authentication of the user. Identify*Runtime will then inform Identify*Admin whether or not the user has access and with what roles he has access. Once he is logged into Identify*Admin, then the access rights that he received from Identify*Runtime will decide his access rights in Identify*Admin. The tricky abstraction is then that the data which we are managing via Identify*Admin, is in fact the data which has decided our access rights to the system via Identify*Runtime as IdP.

The second reason that we cannot see Safewhere*Identify as purely an IdP, is that Identify*Runtime can actually function as a Relying Party for another IdP. If e.g. Identify*Admin was set up in Identify*Runtime to contact a third party IdP for authenticating a user’s access to Identify*Admin, then this request would actually be sent from the related Identity*Runtime application to the third party IdP. If the third party IdP granted the necessary access rights to this request, then this response would be returned to Identify*Runtime, which in turn would grant the user access to Identify*Admin.

Except for a few login, consent and error pages, Identify*Runtime does not have much UI to show. Its essential function is receive token requests and issue responses (tokens containing claim sets).

Claims Pipeline

When a request is received by Identify*Runtime, the first thing the system does is establish who the requestor is. The requestor must exist as a Protocol Connection in Safewhere*Identify to be processed. If requestor is identified then the request is sent to the authentication step. In the authentication step, the user must choose an authentication method (an Authentication Connection). The Authentication Connection (if of the type Username & Password or NemId) will either request credentials or (if of the type SAML 2.0, WS-Federation, OCES, Facebook, LinkedIn, etc.) forward the request to a third-party IdP for authentication.

For a token request to be processed and responded, it must thus pass through both an Authentication Connection and a Protocol Connection. On both of them, there are a number of Transformation objects that the request can pass through and which will influence the final returned claim set. These Transformation objects make up the Claims Pipeline of Safewhere*Identify and will be explained in more detail in the chapters Add Authentication Connections, Add Protocol Connections and Claim Transformations.

Claims Pipeline will better explain the concept.

Was this helpful ?Good Somewhat Bad