Safewhere Identify Introduction

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.

Tenants

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).