Identity Broker: How Does it Fit in the Identity Management Puzzle

Recently for a project, the need arose to seamlessly, or as seamless as possible, connect two disparate Learning Management Systems so that users from one system can access content from another without re-entering credentials. Each system is administered and managed by different organizations.

How the heck are we going to do this with technical, security, and bureaucratic constraints looming on the horizon?

It turns out bureaucracy can be satisfied by filling out a lot of paperwork, accepting most of the risk, and offering up your firstborn.

Technology and security are not as easily satiated.

Since we are dealing with user identities, it made sense to look to the world of Identity and Access Management (IAM) for our solution. The underlying concept of IAM is to:

Ensure that users have access to only the IT resources that they need and only after first being verified and authorized to do so.jumpcloud.com: SSO Isn’t Identity Management

Define the problem

Before we can talk about the potential solution, we have to understand the common issues organizations face and their many users who need access to many applications that require multiple credentials and permissions.

On average, organizations today have 51 business-critical applications, and over half of these are accessed via mobile devices.

Typically the larger the organization, the more business-critical applications which, if calculated <multiple that by...carry the one...compound the interest>, equals an incredible number of headaches for all, end-users and application administrators alike. All those applications require logins and passwords for each user, exacerbating the dissatisfaction from employees on the number of passwords they have to remember, which can lead to bad password hygiene.

Many organizations don't provide formal cyber awareness training to new and existing employees, which leads to added vulnerabilities and risks exposed by user behavior instead of technical infrastructure that could easily be reduced or mitigated through proper training.

Often, there is little to no oversight on account privileges, including accounts with the highest access levels that are the most targeted. Poor implementations or a complete lack of implementation of multi-factor authentication leads to vulnerabilities with compromised credentials.

Why IAM?

First and foremost, an IAM can improve user experience by minimizing password fatigue. Reducing the number of passwords a user has to remember helps fulfill the requirement to have a seamless user engagement.

With the move to a more distributed workforce and with the employee's physical location spread across long distances, it becomes difficult to manage access permissions for the enterprise's business application portfolio, limited visibility and control over employee work practices, and all the other things that come with onboarding and offboarding remote workers. IAM is a centrally managed solution that enables better control of access rights with minimal administration overhead and effort.

In a traditional technical infrastructure, the focus of security was on the perimeter of the organization. Protect the border and everyone within is safe. In the modern corporate environment, there are no borders, and entrance to the organization can come from many digital sources. IAM will enhance the security of this borderless environment by shifting protections from the boundary to the user and identity.

The pieces of IAM

At its core, IAM consists of Users, Identity Providers (IdP), and Service Providers (SP). One of the prime functions is to establish a single, consistent, usable identity across multiple platforms, applications, and networks called a federated identity.

A User, sometimes referred to as a browser, represents an entity initiating a request. It could be used to login into a corporate application or a commercial web portal such as a bank portal.

An Identity Provider, sometimes referred to as a Credential Service Provider (NIST), is a service that stores and manages digital identities. Its job is to maintain the federated identity by protecting registered credentials and making them available to disparate directory services through translation services. The actions of an IdP consist of:

• Authentication: are they who or what they claim to be
• Attribution: information returned about the user (name, email, unique identifier) that can be matched to local user records to federate the identity
• Authorization: documenting whether the requestor was granted access. IdPs are categorized in either social (Google, LinkedIn, Facebook) or enterprise (Azure AD, G Suite, LDAP)

A Service Provider, sometimes referred to as a Relying Party or Claims Aware/Based Application, is an entity that maintains the digital resource that a user or device is trying to access. Often it will be web-based and responsible for securing access to resources by requiring user validation (e.g., bank portal, learning management system). The SP will usually maintain a local account for the user that contains specific attributes that will be referenced against the returned attributes from the IdP. Protocols are used to facilitate communication between the Browser, SP, and IdP.

The most commonly used protocol is Security Assertion Markup Language (SAML) which exchanges XML documents between the SP and IdP, both of which must use the same configuration. By relying on the digital signature, it eliminates password use.

Other common protocols are OAuth which uses tokens that are encrypted in transit and OpenID Connect (OIDC) with both utilizing JSON.

Let's see it in practice

Where does the Identity Broker piece fit?

An Identity Broker is responsible for creating a trust relationship with an IdP in order to use its identities to access internal services exposed by SPs.

An intermediary service that connects multiple service providers with different identity providers Red Hat: Identity Brokering

The Broker provides a user-centric and centralized way to manage identities across different security domains or realms. An existing account can be linked with one or more identities from different IdPs or even created based on the identity information obtained from them.

Let's re-run the workflow

What's the benefit?

Inserting the Broker into the process enables quick and easy setup and configuration of multiple SPs and IdPs and is scalable for the future as applications and tools are added and removed from the enterprise portfolio.

The creation of the Broker identity token and its inclusion in the communication between entities decouples the SP and IdP, thereby shielding the SP and browser from knowing what protocol was used to validate the identity. This diminishes the capabilities of a malicious actor since they will never know what IdP was used and cannot adjust their attack to target any vulnerability for that specific IdP.

Broker vendors will rapidly implement support of new protocols, both authentication and federation. An end-user administrator can quickly switch between protocols with minimal effort.

What a user is authorized to do in the IdP may be different from what they are authorized to do in the SP. The Broker can map a role from one entity to a role in the other and return that in the response.

Brokers support just-in-time provisioning. After verifying the identity, the Broker can determine if the external user identity exists in an internal user store and create the user locally if not.

Including the Broker does not impact the core responsibility of IAMs of creating a seamless user experience for the end-users.

There's got to be some risk, right?

Poor implementation will negatively impact any technical infrastructure and a poorly implemented IAM is no different.

There is some concern with individual privacy. With the Broker being the centralized architecture, it has a significant position of power. It has the potential to track or profile an individual's transactions. It could also gain insight into the user data that it does not need in order to perform the operations desired by the SP. If configured properly, built-in tools such as Privacy-enhancing technologies (PETs) should reduce or eliminate adverse effects on individuals when their personal information is being collected or processed.

In a large enterprise with many SPs and IdPs, the use of a Broker can have easily calculated cost savings. However, in a smaller organization with a limited number of those entities the cost may be prohibitive and manual configuration of the SP to the IdP may be more cost-effective.

Conclusion

Ultimately our project solution was to pursue a manual configuration between the SP and IdP, due to the cost, effort, and limited scope. An Identity Broker just fits better in a larger puzzle.