Skip to main content

Resource Server Adapter for OIDC

The OIDC version of the Resource Server Adapter (RSA) is built on top of RSA-SDK/RSA-core and enables an access- and identity- conscious gateway relationship to a true Resource Server that must be an OIDC Provider.

The RSA-OIDC Admin API is used to administer the application's database.

Overview of steps to configure RSA-OIDC​

  1. Configure an OAuth relationship with a federated OIDC provider (serving as the real Resource Server) using static and dynamic database configuration. Refer to Configure Federated OIDC Provider.

  2. Configure an OAuth relationship with a Wallet (as a Provider to the Wallet) and select a Resource Owner Token (ROT) issuance and creation strategy. Refer to Configure OAuth Relationship with a Wallet.

  3. Configure an Authorization Server (as a client to the Authorization Server). Refer to Configure an Authorization Server.

    Note: Wallet must be registered as an OAuth Client and Provider to the same Authorization Server to which the RSA-OIDC Adapter is being registered against.

  4. Configure Protected Resources using static and dynamic database configuration. Refer to Configure a Protected Resource.

Prerequisites and Assumptions​

This section of the guide is meant for the people who will be operating and administering the RSA-OIDC. It assumes the reader is familiar with the FPX solution and its components.

To use the RSA-OIDC Admin API:

  1. The RSA-OIDC's database must be accessible.
    • The RSA-OIDC application should have been run at least once to initialize the database.
  2. The RSA-OIDC Admin API server must be accessible at some URI, represented in this guide as {{RSA_ADMIN_URI}}.
    • The Admin API should also have access to the application database.
  3. The administrator must have a valid authorization token.
  4. Requests to the Admin API should include the desired API version in a ApiVersion header. The default is v1.0, and this value is represented in this guide as {{RSA_ADMIN_VERSION}}.
  5. Requests to the Admin API should include a Content-Type header with the value application/vnd.api+json. The requests shown in this guide provide all required headers.

Additionally, both the Wallet Server and Authorization Server should have been configured as shown in previous sections of this guide, and their respective Admin APIs should be running and accessible.

How to define and use the Authorization Token​

All Admin API endpoints require the use of the Authorization HTTP header. The RSA-OIDC Admin API currently uses a static access token to authorize all requests.

The value of the Authorization Token can be defined in application config section of the Helm chart, using the property rsa-admin.staticToken. The value of this token will be represented in the following pages as {{RSA_ADMIN_STATIC_TOKEN}}.

Environment variables​

For a given FPX deployment, there will be a number of values that are common across components and across API calls. The API calls shown in the following sections represent these values as variables surround by two pairs of curly braces. These variables should be defined beforehand and recorded for easy reference as you go through this guide.

The variables are as follows:

  • {{RSA_ADMIN_STATIC_TOKEN}} - as explained above
  • {{RSA_ADMIN_VERSION}} - this is the version of the API to make a request to, which defaults to "v1.0"
  • {{RSA_ADMIN_URI}} - this is the URI of the RSA-OIDC Admin API, and should match the host name of the RSA-OIDC Admin API defined in the RSA-OIDC Admin Helm chart, but with “/json-api” appended
  • {{RSA_URI}} - this is the URI of the RSA-OIDC itself, and should match the host name of the RSA-OIDC defined in the RSA-OIDC Helm chart

Additionally, there are requests used to register the RSA at the Wallet and Authorization Server. Therefore, there is a similar set of variables for each of these components.

For the Authorization Server:

  • {{AS_ADMIN_STATIC_TOKEN}} - Defined in the application config of the Authorization Server using the property as-admin.staticToken
  • {{AS_ADMIN_VERSION}} - this is the version of the API to make a request to, which defaults to "v1.0"
  • {{AS_ADMIN_URI}} - this is the URI of the AS Admin API, and should match the host name of the AS Admin API defined in the AS Admin Helm chart, but with “/json-api” appended
  • {{AUTH_SERVER_URI}} - this is the URI of the Authorization Server, and should match the host name of the Authorization Server in its respective Helm chart

For the Wallet:

  • {{WS_ADMIN_STATIC_TOKEN}} - Defined in the application config of the Wallet using the property wallet-admin.staticToken
  • {{WS_ADMIN_VERSION}} - this is the version of the API to make a request to, which defaults to "v1.0"
  • {{WALLET_ADMIN_URI}} - this is the URI of the Wallet Admin API, and should match the host name of the Wallet Admin API defined in the Wallet Admin Helm chart, but with “/json-api” appended
  • {{WALLET_SERVER_URI}} - this is the URI of the Wallet Server, and should match the host name of the Wallet Server in its respective Helm chart

Testing a Successful Configuration​

When using the RSA-OIDC Admin API, there are a few ways to check if the attempted operation was successful:

  • A 2XX http response. All APIs return a 2XX type http status code on success. The response body should be checked against the openapi specification.
  • A subsequent GET request can be used to confirm what was stored by the API.
  • If the application server is not running, this can also be verified by inspecting the appropriate table in the application database.
  • Test the front-end application. If successfully configured, the front-end client should be able to see and interact with the configured RSA.

RSA-OIDC Admin API - Supporting Features​

OpenAPI Spec​

The API described below has a companion openAPI specification. This YAML file is best viewed using a tool such as http://editor.swagger.io/.

JSON-API Spec​

The RSA-OIDC Admin API makes use of a framework called Elide, and specifically its implementation of the JSON-API specification. The format of the API calls shown in this guide are representative of this specification. While it can be verbose, it is also provides for many useful features. For further information, see the following links: