Manual Chapter :
OAuth Overview
Applies To:
Show Versions
BIG-IP APM
- 16.0.1, 16.0.0, 15.1.1, 15.1.0
OAuth Overview
APM OAuth 2.0 support
APM in OAuth roles in the
network
OAuth roles that APM supports
On a single BIG-IP system, Access Policy Manager
(APM®) can be configured to act as an OAuth 2.0 client and resource server,
or to act as an OAuth 2.0 authorization server, or to act as both.
For APM to act in both OAuth roles on one BIG-IP system requires two
virtual servers, one for each role, and two hostnames, one for each role.
OAuth 2.0 roles
OAuth 2.0 specification RFC 6749 defines the roles in this table.
OAuth role |
Description |
|---|---|
resource owner |
Can grant access to a protected resource. A resource owner
can be an end-user (person) or another entity. |
resource server |
Hosts protected resources, and can accept and respond to
requests for protected resources using access tokens. |
client |
Makes requests for protected resources on behalf of, and
with authorization from, the resource owner. The client is an application. |
authorization server |
Issues access tokens to the client after successfully
authenticating the resource owner and obtaining authorization. |
APM in OAuth resource server and client
roles
When Access Policy Manager (APM®) acts as an OAuth
resource server, users can log on using external OAuth accounts to gain access to the resources
that APM protects. External OAuth accounts can be social accounts, such as Facebook and Google,
or enterprise accounts, such as F5 (APM) and Ping Identity (PingFederate).
In this configuration, APM becomes a client application to an external OAuth authorization
server, such as F5, on another BIG-IP system, or Google.
APM in the OAuth authorization server
role
When Access Policy Manager (APM®) acts as an OAuth
authorization server, APM can grant authorization codes, access tokens, and refresh tokens, and
APM can perform token introspection.
About OAuth database backup
If the BIG-IP system on which you are running Access Policy Manager (APM) is
set up as an OAuth Server, it may also be configured for High Availability (HA). In that case,
the OAuth database on the active system is automatically synchronized with one or more redundant
systems within a device group.
HA supports real-time synchronization of the BIG-IP configuration, including
the OAuth database, and switching over seamlessly when needed. The redundant BIG-IP systems can
reside in different data centers remote to each other, as long as they can reach each other
through an IP network. No additional synchronization or switching over is required for the OAuth
database. For details on configuring High Availability, refer to
BIG-IP Device Service
Clustering: Administration
.In addition to the HA solution, you can also manually back up and restore systems using a UCS
configuration archive. To do this, refer to the knowledgebase article:
K13132: Backing up
and restoring BIG-IP configuration files with a UCS archive
on support.f5.com. The UCS
archive contains all of the files you need to restore the current system configuration onto a new
system, including all configuration files for the BIG-IP system, APM, and the OAuth database (if
in use).Configuring one
BIG-IP system for two OAuth roles
You can configure one BIG-IP system with
Access Policy Manager (APM) acting in an OAuth 2.0 client / resource server role and in
an OAuth 2.0 authorization server role.
- Configure APM to act as an OAuth client / resource server (or to act an OAuth resource server gateway).It doesn't matter whether you configure APM to act as an OAuth authorization server first or second. What's important is that you create separate virtual servers for each of the two configurations.
- Configure APM to act as an OAuth authorization server.In this step, be sure to configure a virtual server that is distinct from the one you configured for APM in the previous step.
- In your DNS configuration, configure two host names:
- Point one hostname to the virtual server configured for APM as an OAuth authorization server.
- Point the other hostname to the virtual server configured for APM in the other role (OAuth client / resource server or OAuth resource server gateway).
You have configured a BIG-IP system on which
APM can play two OAuth roles.
Do not attempt to use a single
FQDN to point to different ports on a single virtual server as an alternative; it
does not work and is not supported.
