×

IDMWORKS Blog

Secure PingAccess applications with PingFederate


Web Sessions define the policy for Web application session creation, lifetime, timeouts, and their scope. Multiple Web Sessions may be defined to scope the session to meet the needs of a target set of Application.

This post is a continuation to my previous blog Configure Tomcat Application With PingAccess For Reverse Proxy.

In this blog, I am going to explain how to secure the tomcat application reverse proxied with PingAccess. The same steps can be used to secure any PingAccess application with PingFederate. PingAccess doesn’t have capability to validate user credentials. So PingAcccess has to be integrated with PingFederate for authentication.

Components
Different components used/created for this exercise:

PingAccess: Sites, Applications, Resources, Identity Mappings

PingFederate: OAuth2.0, OpenID, Authorization settings, IDP Adapters, Access Token Manager, Access Token Mappings, Client Management.

Configuration Steps
Below are the configuration steps. Follow through the screen shots:

1. Add PingFederate cert to PingAccess trust store

910

2. Add PingFederate as Token Provider to PingAccess from “System Settings” in PingAccess Admin console.

12

3. In the PingFederate create a PCV (Password Credential Validator) and an IDP Adapter using the PCV.

17

4. In PingFederate Edit Scope settings under OAuth Settings > Scope Management. Make sure to add at least profile, openid scopes.

23

5. Create an Access Token Manager from OAuth settings > Access Token Management

26 27

6. IDP Adapter Mappings: Map the IDP Adapter created in the previous steps to persistent grant contract. Map the HTML Form IdP Adapter Username value to the USER_KEY and the USER_NAME contract attributes for the persistent grant and the user’s display name on the authorization page, respectively

35

7. Access Token Mapping: Map values into the token attribute contract by selecting Persistent Grant as the Source and USER_KEY as the value for the Username attribute. These are the attributes included or referenced in the access token.

39

8. OpenID connect policy Management: This configuration allows you to define and manage OpenID Connect policies for obtaining user attributes (“claims”) to be sent in an ID Token as well as in response to requests received at the PingFederate UserInfo endpoint. Policies defined here may be mapped to specific OAuth clients. While defining a policy, make sure to delete all the default attributes that appear in the Extend the Contract section of the Attribute Contract page. The only required attribute is sub.

45

9. OAuth client: There should be two OAuth clients for this kind integration. One for Ping Access Resource server. PingAccess uses this client to validate the access tokens with PingFederate, Allowed grant type for this client should be “Access Token Validation”. The another OAuth client is needed specific to application/site, Allowed grant type for this client should be “Authorization Code” and redirect URL should be PingAccess’s /pa/oidc/cb. i.e <PA-hostname>:<port>/pa/oidc/cb.

Below are the screenshots for PingAccess resource server OAuth client:

48 49 50

Below are the screenshots for Application’s OAuth client:

51 52 53

WebSessions
Web Sessions define the policy for Web application session creation, lifetime, timeouts, and their scope.
Multiple Web Sessions may be defined to scope the session to meet the needs of a target set of Applications. Create a websession using OAuth client created for the application.

56

Identity Mappings
Identity mappings make user Web session and OAuth attributes available as HTTP request headers.

58

Edit the Application created in the previous blog and add Websession created

61

Login screens:

64 65 66

Questions, comments or concerns? Feel free to reach out to us below, or email us at IDMWORKS to learn more about how you can protect your organization and customers.

Leave a Reply

Your email address will not be published. Required fields are marked *