OAuth: Beyond the Standard

OAuth is a standard granting a server authorization to access protected data on another server. As there are a myriad of places on the internet to explain ‘how’ it works or ‘how’ to set it up, we will not discuss that in this post. Rather, we will highlight how it’s commonly used by our clients as part of efforts to modernize IAM solutions. OAuth is rarely the complete picture, as clients need more than a standard ‘off the shelf’ implementation to meet business objectives.

Below, we’ll highlight three ways we’ve taken standard OAuth functionality and added value by combining it with other technology.

Client Credentials

View fullsize

Flow

A client credentials grant flow is a basic OAuth use case. In the typical client credentials case, the authorization server is allowing the client to access the resource server without any end user interaction. As such, there is no consent flow.

The client begins by requesting an access token from the authorization server using the client id (a publicly exposed string used by the service API to identify the application) and secret (the key stored on server side securely and should not be publicly available). Once granted, the client presents the access token to the resource server as part of a resource request. The resource service validates it against the authorization server, ensuring it has the scope necessary for the request. If valid, the resource server responds to the request.

Customizations

An organization wanted to use this design to authorize applications to access APIs; however, they didn’t want to place the burden of access token validation onto each application. To facilitate, we added an XML gateway to handle the resource-to-scope mapping and token validation.

Unfortunately, this wasn’t enough to meet requirements. Management of the client id, secret and scopes (a mechanism to limit an application's access to a user's account) was still done within the access manager (AM) platform and would have required a separate team from the organization to be involved in each deployment.

To remove this hurdle, a custom client plugin allowed AM to interface with an existing Lightweight Directory Access Protocol (LDAP), effectively delegating authentication and authorization administration. With this in place, AM was now part of the organization’s existing process for creating and authorizing service accounts. This removed duplicate work during deployments and provided a scalable framework for centralized service account management to APIs!

Resource Owner

Flow

In the resource owner grant flow, the client does not use its individual id and secret to connect. Instead, it uses the end user’s credentials. This flow continues like the client credentials flow (shown above) after this point. When the client receives an access token for the resource server, the access token is tied to the authenticating user (rather than the client application shown in the previous example). Typically, we do not recommend using the resource owner grant flow as it provides a user’s username and password to a client directly, which creates numerous security concerns.

Customizations

For an organization, we developed a front-end single-page application (SPA) that provides login and a self-service user interface for a cloud identity service. The cloud service rightfully required an access token for self-service operations, so we chose this rather than a public client with the implicit flow. The login application obtains the access token at the same time as the authentication event, so the SPA can securely act on behalf of the user - despite being a fully browser-based client!

Authorization Code

Flow

The authorization code grant flow is possibly the most well-known flow to end users. It builds upon client credentials grant flow by forcing the client application to gain authorization to access a user’s data. When a client application needs access to a user’s data in a resource server, it will redirect the user to the authorization server.

If the user is not already authenticated, the authorization server will prompt the user to login and, typically, give consent to the client’s request. Once authorized, the user is redirected back to a whitelisted endpoint for the client to receive the authorization code. The client application then uses this code to retrieve an access token from the authorization server, similar to how it has been used with the client id and secret. With this, it continues the OAuth transaction as before.

Customizations

An organization was looking for a combination of the implicit and authorization code grant flows. It was the user authentication (and the extra layer of OIDC) that added complexity and value to the solution. This organization needed different Levels of Assurance (the degree of confidence in the processes leading up to, and including, an authentication) based upon the access requested. This necessitated authentication using a mobile application on the user’s registered device, e.g., PIN, recovery code, biometrics, etc. The solution adds the specific authentication methods used (amr) to the id token, allowing the relying party to decide which methods were sufficient.

In each case, our solutions were implemented using the OAuth standard. While very important, it rarely meets all business or technology needs on its own. We utilized standard flows and built tailored customization around them, while keeping everything secure.

Taking a set of tools and a set of building blocks, combining them in just the right way to get exactly what we need, is what I love about these projects!

If you have any questions about how to optimize OAuth for your organization, contact us.

Professional Services - Senior Architect

TIPS AND TRICKS: Are you considering deploying ForgeRock in the cloud?

Kubernetes is an open-source system for automating deployment, scaling and management of containerized applications. Kubernetes can be deployed on popular cloud platforms, e.g. Amazon Web Services (AWS), Google Cloud Platform (GCP). At its core, it consists of a cluster of compute resources that schedule and host ForgeRock containerized applications.

Choosing a cloud provider that is the best fit for your initiative is the first step in the planning process. The decision is influenced by a variety of factors. For example, there may be unique features or services offered by a certain cloud provider or your organization may already have a relationship with one.

In addition to being able to create your own customized deployment of Kubernetes in AWS or GCP, these providers also offer options to facilitate Kubernetes as a managed service. This has the potential to reduce the complexity of establishing the Kubernetes environment, but it may also have some functional limitations. What will ultimately drive the decision on which is the best approach will depend upon specific requirements of your initiative.

Regardless of which cloud provider or deployment method you choose, certain design considerations should be kept in mind:

Choose a cloud provider region for your deployment that is geographically closest to your location to help minimize network latency.

Deploy your Kubernetes cluster nodes in at least three of your cloud provider’s availability zones in order to facilitate fault tolerance and high-availability. Availability zones represent fully isolated data centers connected by high bandwidth / low latency network connections.

Determine how your cloud based Kubernetes platform will integrate with your on-premise or other cloud based network environments, as well as the Internet. This will require proper planning of IP network address space, routing and VPN, or other network connection methods supported by the cloud provider.

Plan and implement network security controls that allow sufficient access for the applications to function, while limiting unnecessary network exposure.

Identify and plan where critical functionality required to operate a Kubernetes cluster will be located within the environment, e.g. image and code repositories, DNS zones, certificate management and logging. Cloud providers often offer their own services that can address these requirements or these can be customized. Specific implementation details, requirements, approaches and service offerings will vary between providers; however, design considerations are going to be quite similar. 

If there is a desire for an additional layer of high-availability and fault tolerance, a cluster federation approach can be considered. In this model, a cluster is deployed in each region and linked together using a federation control plane.

It is highly recommended to use an “infrastructure as code” approach wherever possible to deploy your cloud infrastructure. This provides a more reliable and repeatable deployment process and is especially useful in the early stages of testing, as environments can be easily built and rebuilt when necessary. Parameterizing your deployment code can also make it much easier to deploy similar isolated environments to host Development, User Acceptance Testing and Production environments.

---

PROFESSIONAL SERVICES - ARCHITECT

Delegated Administration: A Vital Part of the Modern IAM Platform

One of the key capabilities of modern Identity Management platforms is the ability to configure Delegated Administration for daily operations. Let’s take a look at why Delegated Administration plays an important role in today’s world.

First, we need to define what we mean by the term ‘Delegated Administration’. To delegate refers to ‘a person sent with power to act for another’. Administration means ‘the performance of supervisory duties’. When we put this in an Identity specific context, we are looking at in terms of: 

• decentralization of role-based access control systems

• ability to assign limited authority (i.e. administrative privileges) to a user, or subset of users, permitting performance of actions on a specific object or group objects (i.e. scope)

Now that we’ve set a baseline for understanding what Delegated Administration is, we can use common scenarios or, as we refer to them from a system integration perspective, Client Use Cases to illustrate the business problem, how Delegated Administration addresses it and the corresponding business value.

Scenario 1: Provisioning, Profile Management and Access Requests

Context: 

The advent of information technology ushered in a number of important new job functions to the marketplace, one of the most common and important being the role of ‘Administrator’. Administrators are technologists who understand how to operate these complex systems and applications. Administrators have several key tasks performed on a daily basis, including: Provisioning (the creation of new user accounts), Profile Management (which includes password resets and access request fulfillment) or granting of new rights and / or privileges to existing user accounts.

Business challenge:

Businesses have seen an exponential growth in both the number of IT systems and users. The essential nature of these systems and applications to daily operations and revenue, coupled with the sheer scale of administering them in a small, centralized fashion, creates bottlenecks that significantly impact company profitability - for better or for worse. Users need access to these systems to perform their daily job function and forgotten passwords and account lockouts can severely inhibit productivity. 

Solution: 

So, we now have three main problems - Provisioning, Profile Management and Access Requests. How do we effectively manage these tasks in an ever expanding and complex IT ecosystem without overburdening or continuously increasing support staff? The answer is through Delegated Administration. 

Provisioning happens through two basic means today: automated (i.e. ‘birthright’) provisioning (typically governed by feeds from Human Resources coupled with logic based upon job functions) and request based (generally through human interaction). The latter, request based provisioning or new access, can handle large-scale efficiency in varying degrees, limited by the choice of what types of users can be assigned these roles. 

In our initial example, we discussed the limiting factor of a small, centralized group of administrators handling a large volume of tasks. Delegated Administration can increase optimization by allowing another level of administration, e.g. Department Managers, to perform limited administrative tasks for their direct reports OR allowing a Help Desk Representative to reset passwords.

Taking it to the largest scale, enabling end-users to self administer, can completely offload the burden of certain, specialized tasks from central administrators and empower end-users to manage their own profile data (e.g. name, address, contact information), as well as reset a forgotten password.

Scenario 2: Consumer-scale Identity and Internet of Things

Context: 

The next wave in information technology is upon us - a combination of smartphones, connected devices and mobile applications - leading to a literal explosion of identities. With that exponential growth, of course, comes more administration.

Business challenge: 

In the face of increasing user demand for ubiquitous access (24x7) anywhere from any device, organizations struggle to provide end-users with the ability to manage multiple identities and the devices with which they can be accessed. In addition, modern smartphones and mobile applications often rely on back-end systems, secured with account credentials, to provide services to the end-user. As a byproduct of this array of devices, applications and identities, end-users face an ever increasing number of personal accounts to manage. Providing a top-notch user experience is paramount to maintaining and growing a loyal user base.

Solution: 

As highlighted, Delegated Administration is leveraged to address modern Identity and Access Management challenges many organizations face. Some examples of common uses of Delegated Administration that we encounter daily are:

1. Consumer registration of a new IoT device to access required services

2. End-user self-service password reset on almost any website

3. Adding a child to a “family share” plan for mobile application stores

4. Adding a spouse as an “authorized” agent on a credit or bank account

5. Allowing a manager to request access on behalf of direct reports

6. Allowing a Customer Service Representative to see and modify specific information for clients they support

From an individual perspective, these are empowering capabilities that we have come to expect as part of our overall user experience. 

From a business perspective, it drives customer satisfaction and retention while reducing operational costs and resources. Truly a “win-win” for all parties!

While each business or entity may have variations on business process and governance in how this is implemented, the fact remains that by leveraging Delegated Administration in the current user population, we gain economies of scale much greater than through a centralized model. This allows retaining system integrity through limiting functions to an approved set of well-known Client Use Cases.

Related links: Delegated Administration for ForgeRock (Product), Delegated Administration and ForgeRock Identity Management (Blog by Anders Askåsen - Sr. Technical Product Manager at ForgeRock)

---

SENIOR SALES CONSULTANT