PingAM 8.0.0

AM as client and authorization server

You can set up AM as both an OAuth 2.0 authorization server and an OAuth 2.0 client to protect resources on a resource server using an AM web agent.

This example uses an authorization server, a client, and a resource server protected with a web agent.
Figure 1. Authorization server, client, and resource server

This example configuration uses three servers:

Server Example URL Role

AM1

https://authz.example.com:8443/am

OAuth 2.0 authorization server

AM2

https://client.example.com:8443/am

OAuth 2.0 client, which also handles policies

RS

https://www.example.com:8443/

OAuth 2.0 resource server protected with an AM web agent, where the protected resources are deployed in Apache Tomcat

The two AM servers communicate using OAuth 2.0. The web agent on the resource server communicates with AM using AM specific requests. The resource server in this example doesn’t need to support OAuth 2.0.

The high-level configuration steps are as follows:

  1. On the AM server that acts as an OAuth 2.0 client (AM2), configure an agent profile and the policy used to protect the resources.

  2. On the web server or application container that acts as an OAuth 2.0 resource server (RS), install and configure an AM web agent.

    Make sure that you can access the resources when you log in through an authentication tree that you know is working, such as the default ldapService tree.

    For example, if you try to access https://www.example.com:8443/examples/, the web agent redirects you to the AM login page. After you log in successfully as a user with access rights to the resource, AM redirects you back to https://www.example.com:8443/examples/ and the web agent lets you access the requested resources.

  3. Configure AM1 as an OAuth 2.0 authorization service.

  4. Configure AM2 as an OAuth 2.0 client by setting up a social identity provider service.

    Learn more in Social authentication.

  5. On AM1, register the OAuth 2.0 or OIDC identity provider as an OAuth 2.0 client.

  6. Create a social registration journey that references your social authentication provider.

  7. Log out and log in again using the social authentication journey to verify that you can access the protected resources.