PingAccess role-based access control (RBAC)

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

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.

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”.

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.

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

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:

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

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

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:

1
2
3

#memberOf = #this.get("ds.ad.memberOf").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:

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.

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.

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.

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!