Skip to main content

Configuring the Authorization Server

Once the Authorization Server and the Authorization Server Admin API is set up, the next step involves configuring the Authorization Server to function correctly with the other partners of the FPX ecosystem. The applications allowed in the network, as well as the resources they are allowed to request and share, are controlled by the network administrators. The primary tool for configuring and governing the network is the Authorization Server's Admin API.

Partners need to be established as trusted entities in the network through the Admin API. Some partners, such as Resource Servers and Clients, have extra steps to configure what resources and scopes they are allowed to request/provide.

For more information on the different Partners within the FPX ecosystem, refer to Who are FPX Partners?

Prerequisites​

Before you begin, obtain and make note of the following parameters:

To make requests to the Authorization Server Admin API:

  1. The Authorization Server database must be accessible.
    • The Authorization Server server should have been run at least once to initialize the database.
  2. The Authorization Server Admin API server must be accessible at some AS_ADMIN_URI.
    • The server should have access to the application database.
  3. The administrator must have an appropriate authorization token.
  4. The request must include the desired API version in a ApiVersion header. The default is v1.0.
  5. The request should include an Accept-Language header.
  6. The request should include a Content-Type header with a value of application/vnd.api+json or application/vnd.api+json; ext=jsonpatch, depending on the format of that request. See the configuration section sample requests.

Localization​

The Authorization Server Admin API includes localization support, and it is recommended to configure a new deployment with localization support from the beginning unless you know that you won't need it. For that reason, this guide includes the Accept-Language header in all API requests where it is appropriate to include it. The language value set in that header is English, so be sure to change that in the sample API requests if you know you want to configure a different language to begin with.

The localization feature is covered in more detail here.

Disabling/Re-enabling an entity via API​

The Authorization Server Admin API allows disabling and re-enabling of specific functionalities, for example, disabling a resource that a resource server no longer provides.

The Disable API functionality puts the disabled entity in a hibernate state, where it remains until access is granted again, or in other words, the entity is re-enabled.

The disabledOn attribute is the date and time value at which the related entity was, or will be, disabled. By default, the value of the disabledOn attribute is set to null.

In order to disable an entity, an admin must use the admin api to update the default value in the disabledOn field by adding date and time in the following format "yyyy-MM-dd'T'HH:mm:ss'Z".

To re-enable an entity, the admin must reset the disabledOn value to null.

An Admin can disable the following components using the Admin API:

  1. Service Provider (UMA client)
  2. Capability Ticket
  3. Resource Server
  4. Resource
  5. Wallet

JSON-API Spec​

The AS 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:

This section of the guide will cover the following topics: