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 the scope of the component. An Identity Management System should consist of logical components for the following services:

An Authentication Service

responsible for authenticating users and providing self-service for users to reset passwords and sign up, among other things.

 A Federation Service

responsible for web application cross-domain Single Sign-On.

A Token Service

liable for the issuance of security tokens and introspection. primarily for API access and accessibility to the contemporary web and mobile applications.

A User Management Service is

accountable for user provisioning procedures.

The Authentication Service

As a hub (or multiplexer) for serving various identity sources, such as social identities, strong identities, or any other identity source, an authentication service ought to be constructed. The entity that is able to provide an answer to the question of who the user is based on the identity source it provides is referred to as an identity source or an authenticator. It is possible to add new authenticators to the system without having to update the dependent systems, such as the websites or applications that use these identities.

Because there are so many different approaches that a system can take to identify a user, authentication is an inherently difficult problem to standardize. One method may authenticate the user by determining the user's physical network, while another may send a letter with a pin code through physical mail services.

As a result, the authentication service is required to act as a broker between applications that require user authentication and these various authentication methods. Applications rarely communicate directly with the authentication service; instead, they use standard protocols to request authentication from either the Federation Service or the Token Service. When required, these, in turn, communicate with the Authentication Service.

Separating non-standard integration from standard protocol functions like federation and token issuance is a clear advantage of this.

The Token Service

Tokens are issued and verified by a Token Service, also known as a Security Token Service (STS). The types and profiles of these tokens vary. To send tokens to clients, an STS uses different protocols; Some of them are not standardized, while others are. OAuth and WS-Trust are the most frequently used standard protocols that an STS implements.

An STS is typically referred to as an OAuth Authorization Server (AS), a specialized type of token service when implementing the OAuth protocol. Two types of tokens are issued by an AS: Refresh Tokens and Access Tokens (ATs) Clients typically receive tokens "by value" or "by reference."

See OAuth Token Types The JSON Web Tokens (JWTs) are the tokens that are passed by value the most frequently. When mobile is not the primary use case, SAML tokens are sometimes passed by value as well. Any non-standard tokens are always passed by reference. By-ref tokens are widely used despite the lack of standardization.

OAuth, WS-Trust, and other protocols that an STS might use are all "active protocols," which means that for a token to be issued and/or validated, a client must actively participate in the message exchange. The customer cannot simply convey the message. A token can only be issued and/or validated if active clients perform actions. Mobile apps, dynamic Web apps running on a Web server, and desktop applications are typical examples of active clients. Both of these protocols are used to facilitate delegated authorization and broker trust between security realms. Asymmetric cryptography is typically used to sign messages and tokens in trust brokering. A trusted authority signs the asymmetric keys that are used to compute these digital signatures. Consequently, the trust is mediated by the trust that each party has in an impartial third party. Most of the time, this outside authority is a root Certificate Authority (CA) like Thawte or Verisign.

A four-party trust model is used to accomplish delegated authorization rather than the simpler three-party model. The STS grants a specific client application permission to act on behalf of an end user or Resource Owner (RO) in a four-party system. It asserts that the Resource Server (RS) or API, the fourth party, receives the tokens. This API determines whether the delegated authorization complies with its own security policy after verifying the token's authenticity through mutual faith in the STS.

The Federation Service

A Federation Service is very similar to a Token Service. An application known as a Federation Service facilitates trust between organizations. However, in contrast to the Token Service, a Federation Service provides "passive clients" with cross-domain identity propagation. A passive client simply facilitates communication between the Federation Service and the actors that rely on it for identity federation, as opposed to the active client described in the preceding section, which computes the inputs and outputs required to determine security tokens from a Token Service. A Web browser is the classic example of such a client. Web Single Sign-on (SSO) is the outcome of the client's passive participation in the message exchange. SSO lets a user move from one security context to another without having to re-authenticate.

Protocols that are tied to HTTP are used by a Federation Service to support browser clients. As with WS-Federation, a protocol that is frequently implemented by a Federation Service, these protocols may occasionally extend those utilized by an STS with active clients. SAML and old OpenID are two other typical protocols that a Federation Service will be able to support. Other less well-known protocols or proprietary protocols are supported by some Federation Services. OpenASelect is one such protocol, but it is only used in a few specific industries and geographies.

OpenID Connect layers identity atop OAuth.

OAuth is a generalization of earlier protocols like Kerberos and WS-Trust for Web service security. The Token Service is known as the OAuth Authorization Server, the KDC, and the Security Token Service (STS), respectively, in those and OAuth. Clients are actively involved in obtaining tokens in each of these protocols. However, there are times when customers are passive rather than active. WS-Federation, which built an identity on top of WS-Trust to provide identity to passive clients like Web browsers, is an example of this. OpenID Connect is currently used for this as well. As a consequence of this, the OpenID Connect Provider—an OAuth Authorization Server that is capable of supporting OpenID Connect—is an STS that is capable of supporting passive clients. A Federation Service is another name for an STS that provides support for passive clients. Consequently, the Token Service in OAuth and OpenID Connect fulfills the Neo-security Architecture's two roles.

The OpenID Connect protocol is housed in the Token Service of the Curity Identity Server because internal single sign-on (SSO) access to cloud services like Office 365 and others requires a separate Federation Service these days.

The User Management Service

User identity data is needed by many systems. Even though a Federation Service and STS can sometimes be used to send this data to those systems, the data is frequently required at points where those systems are not involved. When a user uses federated authentication, a Federation Service and STS are only involved in a transaction. Systems may need user information after or before authentication. The STS and Federation Service's endpoints cannot be used to obtain this kind of information in these situations. A User Management Service is needed to accomplish this in the Identity System.

An abstraction of one or more Identity Repositories is a User Management Service. It lets you manage users by allowing you to "Create, Retrieve, Update, and Delete" (CRUD) user data. To add user information to tokens, a Federation Service or STS can use a User Management Service; However, outside of the Identity System, its primary customers are In order to provide additional information about a user that is required to make a fine-grained authorization decision, a client, for instance, might serve as the Policy Decision Point (described below). A cloud service that requires information about a user who has not yet accessed it in order for an administrator to locate and grant permissions or a license to that user is another example.

The standards-based CRUD interface that the User Management Service exposes is necessary for this abstraction to be interoperable. A System for Cross-domain Identity Management (SCIM) or Simple Cloud Identity Management, as SCIM was originally known, is the best option out of the few that are available. A resource-oriented API is made available by this lightweight RESTful protocol for carrying out CRUD operations on groups and users. Additionally, the API allows for precision updates to specific attributes as well as bulk updates (a process known as patching). For widespread interoperability, SCIM also defines a normative set of user and group attributes. Despite the fact that this protocol is older than the others discussed in this paper, it is supported by more than a dozen open-source and commercially available products; Additionally, these have been subjected to numerous public interop tests; and the protocol has been submitted to the Internet Engineering Task Force (IETF) for approval as an Internet standard.

Service Provisioning Markup Language (SPML) is one of the available provisioning protocols in addition to SCIM. However, SPML, in particular, is not supported by any major cloud service provider and has not received much industry adoption. There are LDAP-specific bindings for SOAP, JSON, and other protocols that do not offer the advantages of interoperability or widespread reuse. A User Management Service ought to implement at least SCIM for these reasons and the opposite for SCIM.

Conclusion

Identity management is a complicated process. It is easier to map requirements onto functions when the various aspects of identity are broken down into separate logical components. The IMS covers all of the use cases that come up when building large-scale mobile, web, and API-driven applications architecturally.