PingAccess Role Based Access Control (RBAC)

PingAccess version has a slew of options and features - one of which is the "Role Based Access" component for the administrative console. PingAccess is a modern Web Access Management (WAM) platform that, when combined with PingFederate, provides a best-of-breed WAM solution which can protect APIs, Web Services, and Web Sites with sophisticated access controls including RBAC, OAuth policies, Network (CIDR) and time ranges, and so on. However, before version 4.0 of the product, access control was offloaded to PingFederate in the form of Issuance Criteria. With PingAccess 4.x can now natively handle the authorization directly. This blog article will show you how to use Active Directory group membership to determine if someone should have access to the PingAccces console.

Within the new role-based access feature, there are two available roles: Administrator and Auditor (i.e., ‘Read-only’).

Ping Access Role Based Access Contorl (RBAC)

This is new from the previous PingAccess 3.x and earlier branches. In those versions, PingFederate was configured with Issuance Criteria to limit access to the console. Obviously a this is quite a paradigm shift and a milestone step in the right direction. Still, if you are used to that configuration, you will want to read carefully as things have changed quite a bit.

Taking a look at the screen, when the 'Enable Roles' checkbox is clicked, the 'Required Administrative Attributes' section becomes available for the 'Administrator' and 'Auditor' roles.

PingAccess Required Administrator Attributes

The name and value that need to populate the 'Attribute Name' and 'Attribute Value' are somewhat arbitrary. The real magic is how they get populated when an administrator logs in. The way to accomplish this is by extending the Attribute Contract of the OpenID Connect Policy on the PingFederate side to include an attribute with the same name with a the same value defined in the PingAccess side (provided the user is supposed to have access). When this occurs, the user will be granted access.

The rest of this post will walk you through the following (fairly typical) use case: Use an Active Directory group membership to determine if someone should have access to the PingAccces console. If they should then return the previously defined attribute with the previously defined value. In this configuration, the attribute shall be called paadmin and the success value shall be TRUE.

The first step of configuration is to extend the OpenID Connect Policy to include the a new attribute called "paadmin".

OpenID Connect Policy Management

From the next screen, select the default OIDC Policy (NB: this is a lab environment and your lab environment may differ). In the screenshot below, the "paadmin" attribute has been added to the contract.

PingFederate PingAccess RBAC policy contract extension

Next add the attribute source. This example relies on Active Directory (though any data source could be used). This lab configuration looks like this:

PingFederate Active Directory connection

Remember that Attribute Source ID (circled), it will be needed later

On the next screen, the 'memberOf' attribute (with Nested Groups) should be added as the following screenshot demonstrates:

PingFederate PingAccess RBAC contract fulfillment

Next the LDAP Filter must be added. In the case of this example, a simple (sAMAccountName=${Username}) will suffice.

PingFederate PingAccess RBAC Attribute Filter

Once the attribute source is finished, you will be dropped back at the 'Contract Fulfillment' section of the OpenID Connect Policy configuration screen.

PingFederate PingAccess RBAC Contract Fulfillment

You should notice that the source is "Expression". If you are following along and your dropdown doesn't say "Expression", you'll need to change it. If you don't have "Expression" as an option, then you'll need to enable it in your PingFederate configuration (see this article) and pick up the process where you left off.

Once "Expression" is selected we can write an expression that will fulfill the paadmin attribute and pass a "TRUE" or "FALSE" value back to PingAccess. The expression that works nicely for the scenario is as follows:

#memberOf = #this.get("").toString().toLowerCase(),
#idx=#memberOf.indexOf("cn=ping administrators,ou=security groups,dc=pegright,dc=lab"),
#idx >= 0 ? "TRUE": "FALSE"

(In this section the code will be lightly covered, but for an excellent OGNL tutorial, see this link).

First line: a variable is created called 'memberOf' where all groups in which the authenticating user is a member are stored, then forced to lower-case (since OGNL is case-sensitive and this makes string comparison easier).
Second line: The index of the group used for Ping Access administrators is found using the 'indexOf' method.
Last line: If the index is greater than or equal to zero then return "TRUE", otherwise return "FALSE". This is because if the group is not found (and thus the user not a member) the indexOf method will return a -1 value. A screenshot of this lab:

PingFederate PingAccess RBAC OGNL Filter

Save the configuration (and replicate if necessary) and head back to PingAccess for the final piece of configuration.

In PingAccess the "Enable" has been checked, the "Enable Roles" has been checked, and the "paadmin" and "TRUE" values have been defined. This completes the PingFederate and PingAccess configurations for Role Based Access.

PingAccess RBAC configuration

Once this has been finalized, only members of the cn=ping administrators,ou=security groups,dc=pegright,dc=lab group (defined in the OGNL above) will be allowed to log in with administrative priviledges. In the PingFederate log, the value of paadmin will be logged which is handy for debugging purposes.

PingAccess RBAC server log debugging

Technical notes: If everything seems right and authentication is still failing, you will want to make sure that you have the following scopes defined in your PingAccess -> OAuth Settings -> Authorization Server settings defined.

PingAccess Required scopes for RBAC

Final notes: As you can see, the Role Based access is an exciting new feature in PingAccess and allows for Administrator and Auditor access to the environment. The configuration in this document is relatively standard but PingAccess is hugely flexible and an infinity of other configurations could be accomplished. We at PEGRight hope that you've found this technical guide helpful and informative. If you have comments or questions, please contact us!

Rate this blog entry: