Safewhere*Identify Introduction


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 gives some 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. That is, 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 and Service Providers.

Three Main Components of Safewhere*Identify

It might be tempting to call Safewhere*Identify an Identity Provider. But that is incorrect for two reasons. First, 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 this article, but, fundamentally, it is a more advanced version of the self-service functionalities offered in Identify*Admin.

Identify*Admin will always function as a Service Provider 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 enables token requests to be processed.

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

The second reason that we cannot see Safewhere*Identify as purely an Identity Provider is that Identify*Runtime can actually function as a Service Provider for another Identity Provider. If, for example, Identify*Admin was set up in Identify*Runtime to contact a third-party Identity Provider 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 Identity Provider. If the third-party Identity Provider granted the necessary access rights to this request, 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 to receive token requests and issue responses (tokens containing claim sets).

Was this helpful ?Good Somewhat Bad