OpenAM / Neo4j Policy Condition
Updated: Feb 19
Contributors: Dave Bennett
The Nulli Neo4j Universal Policy Condition plugin for OpenAM is available at https://github.com/nullibrew/openamneouniversalcondition.
The Policy Condition allows a Neo4j graph database to easily be used in an authorization decision.
The code is implemented for OpenAM 12.x, but supports the newly released OpenAM 13 as well. To add the plugin to OpenAM, one can follow ForgeRock documentation at: https://backstage.forgerock.com/#!/docs/openam/12.0.0/dev-guide/chap-policy-spi
Once the plugin is introduced to OpenAM, it can be configured via the OpenAM policy (aka authorization) interface as an “environmental condition”, which looks like:
The “Neo Universal Condition” plugin requires the following parameters:
When the condition plugin is invoked as a result of an authenticated user accessing a protected resource, it proceeds with the following steps:
Evaluates the dynamic valued query parameters based on the authentication system information available to the environment condition interface.
Combines the Cypher query and parameters; and sends the parameterized query to the Neo4j transaction endpoint.
Registers the returned result and provides a policy decision advice (access or deny) based on string values for “Allow-Access” and “Deny-Access” variables.
Query parameters can take static or dynamic values, which are distinguished with the reserved “__” prefix delimiter. Currently, the following dynamic-value patterns are supported by the plugin implementation.
__userId: The identity of the authenticated user.
__resourceName: The protected resource complete URL.
__env__[NAME]: An environment parameter called [NAME].
__req__[NAME]: An HTTP request parameter called [NAME].
The sample Cypher query in that table above takes advantage of the two dynamic values of “__userid” and “__resourceName” that are available in the policy interface. The policy plugin allows the requester access to the requested resource (target node) if and only if there is a path along :MEMBER_OF or :CAN_ACCESS relationships within four (4) hops of the authenticated user (source node). This single Cypher statement allows for the user to directly have access to the resource or be a member of a one or more nested groups that have access to the resource.