Resource Server Adapter

Overview

A Resource Server Adapter (RSA or RS Adapter) performs some of the duties on behalf of an application(s) wishing to appear as a Resource Server (RS) in an FPX network. Existing applications may wish to isolate FPX integration efforts to a separate application/service. This is applicable to third-party applications closed to modification, applications which use protocols or custom flows not supported out of the box by FPX, or data/identity stores which 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 serve as a middleware to the RS, performing some or all of its duties in the FPX network. The major duties of an RS Adapter are described in detail under the RSA Responsibilities section. An RS Adapter is dependent on the Resource Server's architecture, communication protocols, business rules and policies. This means that the RS Adapter itself will need its own set of configurations and customizations to work seamlessly with the Resource Server it is designed to integrate with. It cannot be used in its default form. Certain RSAs such as those predesigned for OIDC or LDAP protocols will be easier to set up with those respective Resource Servers. However, they will still need to undergo some basic configuration adjustments.

Although these guides use the term 'RS Adapter', it should be understood that the RS Adapter may itself be made up of modular components or microservices. An RS Adapter may also delegate some duties to the actual RS, and so only implement a subset of possible responsibilities.

This guide will refer to the existing application that requires an adapter as the 'Resource Server' for simplicity. However, on its own, the application cannot fulfill its duties to the network. Only working collectively with an adapter(s) do they together represent a single Resource Server within an FPX network. It is therefore also 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 are data/APIs they wish to protect, Resource Owners own the resources, and Requesting Parties have the Resource Server or Resource Owner's permission to grant access to resources. A Resource Owner acting as the Requesting Party is a common flow and the only one supported by standard OAuth (I grant an application access to my data vs Alice grants an application access to my data).

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, which can be used to grant access to resources that they have rights to. This representation is commonly referred to as an ROT (Resource Owner Token).

The RS Adapter can facilitate this process by vetting the requesting party through user authentication services, 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 allows the Resource Servers the ability 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