Resource Server Adapter

Overview

In an FPX network, a Resource Server Adapter (RSA or RS Adapter) can perform some of the duties on behalf of an application(s) that wants to appear as a Resource Server (RS). This is particularly relevant for third-party applications that may be closed to modification or use custom flows not supported by FPX out of the box, or have data/identity stores that do not support some aspects required of a Resource Server, such as authentication or policy-based access management.

For example, onboarding any of the following into an FPX network directly would present challenges:

Google API Services
Open-source healthcare system with custom authentication that cannot be modified without losing government accreditation
An Active Directory that wishes to be available to share user information

In these cases, an RS Adapter can act as a middleware to the RS, performing some or all of its duties in the FPX network. The RSA responsibilities are detailed under the RSA Responsibilities section. An RS Adapter depends on the Resource Server's architecture, communication protocols, business rules, and policies. This means that the RS Adapter will require its own set of configurations and customizations to work seamlessly with the Resource Server it is intended to integrate with. Therefore, it cannot be used in its default form. Although certain RSAs such as those pre-designed for OIDC or LDAP protocols will be easier to set up with respective Resource Servers, they will still require some basic configuration adjustments.

It should be noted that although the term 'RS Adapter' is used, the RS Adapter may itself be composed of modular components or microservices. Also, an RS Adapter may delegate some duties to the actual RS, and so only implement a subset of possible responsibilities.

This guide uses the term 'Resource Server' to refer to the existing application that requires an adapter, but on its own, the application cannot fulfill its duties to the network. Only when working collectively with an adapter(s) do they represent a single Resource Server within an FPX network. It is, therefore, correct to use the term 'Resource Server' to refer to the joint entity of the application plus its adapter(s).

Primary Role of the Resource Server

Grant Control over User Data/API to a Wallet

Resource Servers have Resources, Resource Owners, and Requesting Parties. Resources refer to data/APIs that they want to protect, Resource Owners own the resources, and Requesting Parties have the Resource Server or Resource Owner's permission to grant access to resources. The Wallet acts on behalf of the Requesting Party within an FPX network. Resource Servers need to provide the Wallet with a representation of the current requesting party that can be used to grant access to resources that they have rights to. This representation is commonly referred to as a Resource Owner Token (ROT).

The RS Adapter can facilitate this process by vetting the requesting party through user authentication services, and then providing a protocol the Wallet can use to represent that vetted requesting party. When a Client later requests resources using a token issued on behalf of a requesting party, the RS Adapter can use this protocol to translate the requesting party representation back into user rights for use by a policy enforcement point (PEP). This enables Resource Servers to hide the requesting party's identity from the network and facilitate non-repudiation of the permission.

Other Responsibilities

Resource Server Main Components/Responsibilities

UMA Management
- Maintain list of trusted Authorization Servers
- Maintain registered resources at each Authorization Server
- Client PEP
  - Determine resources/scopes required for request
  - Determine union of user and client rights to resources/scopes
  - Allow requests with sufficient rights
  - Reject requests with AS location and a permission ticket if insufficient rights
- Manage PAT token with each Authorization Server
- Acquire permission ticket from AS for required resources/scopes
- Introspect Client's RPT Token with AS or internally
User Authentication Services
- Perform authentication with user
- Obtain consent to delegate user policy to Wallet
- Generate Access Tokens for Wallet to represent delegated rights
User Rights Services
- Introspect Wallet Access Tokens
- Issue Resource Owner Tokens representing resource access rights of user
- Resolve Resource Owner Tokens back to user/entity and their resource access rights
Resource Server API
- Respond to Client requests
- Further Filter data/access based on resources/scopes granted