What is an Identity Management System?

Identity Management System Definition

By definition, an Identity Management System also referred to as Identity Management and Access System, is a security framework that can be implemented to provide authorized access to technology resources by authenticating users using a token-based approach.

Following the principle of separation of concern each component (or sub-system) handles a singular logical function and depends on the other components for operations that are out of scope for the component. An Identity Management System should consist of logical components for the following services:

• An Authentication Service

  Responsible for Authenticating users, providing user self-service for password resets, sign-ups etc.

• A Federation Service

  Responsible for cross domain Single Sign-on for web applications.

• A Token Service

  Responsible for security token issuance and introspection. Primarily for API access and for modern web and mobile application access.

• A User Management Service

  Responsible for user provisioning operations.

The Authentication Service

An Authentication Service should be built as a hub (or mulitplexer) for serving different identity sources such as social identities, strong identities or any other identity source. An identity source also known as an Authenticator is the entity that can answer the question of who the user is given the identity source it provides. When new authenticators are added to the system, they can be added without requiring any updates to the depending systems, such as the websites or applications utilizing these identities.

Authentication is an inherently impossible problem to standardize, since the possible ways a system can take to determine who a user is differs significantly between types. One method may authenticate the user by knowing what physical network the user is on, while another may use physical mail services to send out a letter with a pin code.

Because of this, the authentication service is needed to act as the broker between all these different authentication methods and the applications requiring a user to be authenticated. The applications rarely communicate directly with the authentication service, but use either the Token Service or the Federation Service via standard protocols to request authentication. These in turn communicate with the Authentication Service when needed.

This has the obvious benefits of separating non-standard integration out from the standard protocol functions like federation and token issuance.

The Token Service

A Token Service, or Security Token Service (STS) as it was traditionally called issues and verifies tokens. These tokens are of various kinds and profiles. An STS uses different protocols to communicate tokens to clients; some of them are standardized and some are not. The most common, standard protocols that an STS implements are OAuth and WS-Trust.

When implementing the OAuth protocol, a STS is usually referred to as a specialized type of token service known as OAuth Authorization Server (AS). An AS issues two kinds of tokens: Access Tokens (ATs) and Refresh Tokens (RTs). Tokens are typically passed to clients “by value” or “by reference”. See OAuth Token Types

The most common types of tokens that are passed by value are JSON Web Tokens (JWTs); SAML tokens are also sometimes passed by value when mobile is not the primary use case. Those passed by reference are always non-standard types of token. Despite the lack of standardization, by-ref tokens are commonly used.

OAuth, WS-Trust, and other protocols that an STS may use are all “active protocols,” meaning a client must be actively participating in the message exchange in order for a token to be issued and/or validated. The client cannot simply pass along the message. Active clients must perform actions, in order for a token to be issued and/or validated. Typical examples of active clients are mobile apps, dynamic Web apps running on a Web server, and desktop applications. Both of these protocols are used to broker trust across security realms and facilitate delegated authorization. Trust brokering is typically done by signing tokens and messages using asymmetric cryptography. The asymmetric keys used to compute these digital signatures are signed by an authority that each organization trusts. As a result, the trust is brokered through the mutual faith that each party has in an independent third-party. This outside authority is typically a root Certificate Authority (CA) like Verisign or Thawte.

Delegated authorization is achieved using a four-party trust model rather than this simpler, three-party model. In a four-party system, the STS authorizes a particular client application to act on behalf of an end user or Resource Owner (RO). The tokens that it asserts are presented to the fourth-party, the Resource Server (RS) or API. This API verifies the authenticity of the token through its mutual faith in the STS and then determines if the delegated authorization meets its own security policy.

The Federation Service

Very closely related to a Token Service is a Federation Service. A Federation Service is an application that also brokers trust across organizational boundaries. Unlike the Token Service, however, a Federation Service provides cross-domain identity propagation to “passive clients.” Unlike an active client described in the previous section which computes the inputs and outputs needed to ascertain security tokens from a Token Service, a passive client simply ushers a user along in the flow between the Federation Service and the actors that rely on it for identity federation. The classic example of such a client is a Web browser. The result of the client’s passive involvement in the message exchange is Web Single Sign-on (SSO) which allows a user to cross from one security context to another without re-authenticating themselves.

To accommodate browser clients, a Federation Service uses protocols that are bound to HTTP. Sometimes these protocols will extend those used by an STS with active clients, as with WS-Federation, a protocol often implemented by a Federation Service. Other typical protocols that a Federation Service will support include SAML and legacy OpenID. Some Federation Services support other, less-known protocols or proprietary ones. An example of such a protocol is OpenASelect, which has very limited use outside certain geographies and verticals.

OpenID Connect layers identity atop OAuth.

OAuth is a Web service security protocol — a generalization of past protocols like Kerberos and WS-Trust. In those as well as in OAuth, the Token Service is a fairly obvious entity — it’s the OAuth Authorization Server, the KDC and the Security Token Service (STS), respectively. In all of these protocols, clients are actively involved in obtaining tokens. Sometimes, however, clients are not active, they are passive. Historically, this can be seen in WS-Federation which also built identity atop WS-Trust to provide identity to passive clients like Web browsers. Today, this is done in OpenID Connect as well. As a result, the OpenID Connect Provider (an OAuth Authorization Server that supports OpenID Connect), is an STS that supports passive clients. An STS that supports passive clients is also called a Federation Service. As a result, the Token Service in OAuth and OpenID Connect fulfills both roles defined by the Neo-security Architecture.

These days a separate and distinct Federation Service is mostly needed when the organization desired internal SSO to access cloud services such as Office 365 and others using a single IdP, so in the Curity Identity Server the OpenID Connect protocol is placed in the Token Service.

The User Management Service

Many systems need user identity data. While this data can be communicated to those systems using a Federation Service and STS in some cases, the data is often needed at points where they are not involved. A Federation Service and STS are only involved in a transaction when a user is performing federated authentication. Post- or pre-authentication, systems may need information about a user. Obtaining such information in these cases is outside of the scope of the endpoints that are provided by the STS and Federation Service. For this, the Identity System needs to include a User Management Service.

A User Management Service is an abstraction of one or more Identity Repositories. It provides user management capabilities, such as the ability to Create, Retrieve, Update, and Delete (CRUD) user data. A User Management Service can be used by a Federation Service or STS to populate tokens with user info; however, its primary consumers are outside of the Identity System. A client, for example, may be the Policy Decision Point (described below) to provide more information about a user that is necessary to make a fine-grained authorization decision. Another example might be a cloud service that needs data about a user that has not yet accessed it, so that an administrator can find and furnish a user with a license or permissions.

For this abstraction to be interoperable, the CRUD interface that the User Management Service exposes must be standards-based. There are very few choices, and the best one is System for Cross- domain Identity Management (SCIM) or Simple Cloud Identity Management as SCIM originally stood for. This lightweight RESTful protocol exposes a resource-oriented API to perform CRUD operations on users and groups. The API also supports bulk updates and precision updates to just certain attributes (an operation known as patching). SCIM also defines a normative set of user attributes and group attributes, necessary for widespread interoperability. Though this protocol is newer than others discussed in this paper, there are over a dozen open-source and commercially available products that support it; there have also been numerous public interop tests of these; and the protocol has been submitted to the IETF for ratification as an internet standard.

Other protocols besides SCIM exist for provisioning, such as Service Provisioning Markup Language (SPML). However, SPML, in particular, has not retrieved much adoption in the industry and is not supported by any major cloud service provider. SOAP, JSON and other bespoke bindings exists for LDAP, but these do not provide the benefit of interoperability or broad reuse. For these reasons and because of the opposite is the case for SCIM, a User Management Service should implement at least SCIM.

Conclusion

Managing identity is an involved process. By separating the different aspects of identity into discrete logical components it becomes easier to map requirements onto functions. The IMS has complete coverage architecturally of the use-cases that arise when building large scale mobile, web and API driven applications.