Skip to main content

Access Management

What is Access Management?​

Access management is the process of ensuring that someone can only access information that they’ve been authorized to access.

IDENTOS access management gives you full control over your environment. As the administrator, you set the access policies that determine who can access the environment and what resources they are allowed to access. For example, a Client application used by a healthcare provider might be authorized to access a patient’s immunization records but not their entire medical history.

Access management is tightly linked to consent management. When a Client application requests access to a user’s protected information, the user should be prompted to provide their consent.

How Does IDENTOS Provide Access Management?​

The Federated Privacy Exchange (FPX) product provides authorization and consent management. FPX consists of several core components: the Authorization Server, Wallet and Navigator, and Resource Servers.

1. Authorization Server (AS)​

The Authorization Server’s role is to control the Client’s access to digital resources. The AS is responsible for:

  • Providing a configuration registry for the environment. This registry includes:
    • Access policy rules. These rules are used when onboarding Clients and resource servers and also to determine which resources a Client is allowed to access.
    • Knowledge of the resource servers, which resource definitions each resource server can provide, and the scopes within each of these definitions.
    • Knowledge of the Clients that are allowed to access the environment and which resource definitions each Client is allowed to access.
  • Receiving, authorizing, and routing Client requests for resources. When the AS receives a Client request, it applies access policies to determine the resources the Client is allowed to access, then issues a token to the Client. The actual API request to access the authorized resources is then sent directly from the Client to the resource server.
  • Refreshing and revoking tokens for Client applications.

The AS does not transmit or have access to personal data and views pseudonymous identifiers only.

The Authorization Server uses the following access management standards:

2. Resource Server Adapter (RSA)​

FPX uses Resource Server Adapters (RSAs) to integrate with external resource servers. The RSA, which understands the FPX authorization language and tokens, acts as a bridge between the FPX environment and the resource server.

A resource server is a protected third-party API that can grant access to the resources requested by Client applications. Examples of resource servers are identity providers (IdPs) like Amazon Origin Access Control (OAC), FHIR APIs, clinical data repositories, and financial APIs.

FPX has a core RSA that can be customized to work with any third-party API. FPX also includes prebuilt RSAs for common scenarios, such as FHIR APIs and popular IdPs.

An RSA performs the following functions:

  • Acts as middleware between FPX and the resource server, allowing FPX to integrate with external APIs.
  • Performs policy enforcement: takes the token from the Client and decides what resources to provide to the Client.
  • Onboards data sources and helps them understand FPX tokens.
  • Can be customized with additional rules and business logic. This custom information builds on the more general policies enforced by the AS.
  • Includes value-added features such as:
    • Storing additional data.
    • Enriching profiles (pulling two different data sources together into one API).
    • Providing user experiences for consent management flows (e.g. sign up flows, finding your record flows).

3. Abstraction Integration (Resource Definitions)​

FPX provides an alternate approach to point-to-point integration.

Typical point-to-point integration involves integrating directly with a specific resource server. For example, assume your environment includes five identity providers (IdPs). Point-to-point integration would require Clients to connect to each IdP separately, resulting in five different integrations.

FPX simplifies this process using abstraction integration. FPX creates abstract resource definitions on top of resource servers. This allows Clients to integrate with an abstract resource definition rather than a specific resource server.

For example, let’s say the Client needs to retrieve a user profile. Instead of integrating with a specific IdP, the Client would integrate with a user profile resource definition. This gives the Client potential access to all of the IdPs that are integrated with FPX. The user can then use their consent management to decide which IdP to use.

A resource definition includes an API schema and also applies scopes that modify the Client’s access to the API schema. Multiple scopes can be applied: each scope specifies a group of attributes that the Client can access in the API schema.

Abstract integration provides several benefits:

  • Eliminates the need for multiple integrations for the same type of resource server. The Client doesn’t have to integrate with each individual resource server, just a resource server definition. This allows the Client to access a “pool” of resource servers. Through consent management, the user chooses which resource server the Client will use.
  • Because the Client isn’t directly integrated with a resource server, it’s possible to make changes (such as onboarding additional resource servers to the environment) without impacting Client applications. For example, you could add a new IdP to the environment and gradually migrate users to the new IdP without affecting the existing Client integrations.