Self-governance
Self-governance enables you to regulate who can view or change your authorization controls within the Policy Editor.
Just as you build application policies to manage access to your API resources and functions, you build self-governance policies to manage access to your Policy Editor entities and operations. This allows you to protect against unauthorized or accidental application policy changes.
When you install the Policy Editor with self-governance enabled, the application automatically creates the Admin Point Governance branch, which contains the System Policy Set and several self-governance Trust Framework definitions.
|
While self-governance controls are no different than standard Policy Editor controls, all of your self-governance controls must be contained within the Admin Point Governance branch. By default, this branch is only visible to the self-governance administrator. Any policy sets, policies, and rules you build must be children of the System Policy Set. |
How does self-governance manage access?
When self-governance is enabled and a user attempts to perform an action within the Policy Editor, this action is subject to the authorization policies defined in the System Policy Set of the Admin Point Governance branch. These access controls are applied at the level of the Policy Editor REST API and are therefore applicable to users of the Policy Editor web application and clients of the REST API.
The Policy Editor automatically turns the attempted action into an internal decision request against these self-governance policies. This request includes:
-
A service, which indicates the type of entity the user is interacting with (for example, policy set, policy, attribute, or branch)
-
An action, which indicates what the user is trying to do (for example, read, update, or delete)
-
Attributes that describe the existing state of the object being acted upon and the intended state of the object after the user’s action
-
Attributes that describe the current branch upon which the user is performing the action
-
Attributes that describe the Policy Editor user performing the action
You can find more information about Self-governance Trust Framework for all of the relevant services, actions, attributes, and conditions that you can use to build policies for your Self-governance use cases.
Enable self-governance
Self-governance is not part of the baseline configuration for the Policy Editor and must be enabled during installation. Use the non-interactive setup for self-governance in either demo mode or OIDC mode, supplying the appropriate arguments. You can find more information about enabling self-governance in Installing the PingAuthorize Policy Editor non-interactively.
|
Best Practice: Self-governance is intended for use with a single Policy Editor instance. In an environment with multiple Policy Editor instances connected to a single database, restart each instance after committing your self-governance policy updates. |
As part of setup, the Policy Editor creates a self-governance administrator account. This is a special user who is never subject to self-governance policies and always has full control over the entire Policy Editor.
|
It is possible, through misconfiguration of self-governance policies, to completely lock regular users out of the Policy Editor. To address this scenario, the self-governance administrator can update or roll back self-governance policy updates to restore Policy Editor access. |
HTTP caching
HTTP caching is enabled by default as part of a standard Policy Editor configuration, but can be permanently disabled. When using HTTP caching in combination with self-governance, the time-to-live value of the cache plays an important role in self-governance decisions. After the cache expires, the Policy Editor verifies that the user still has access to the resource, even if the resource is unchanged. You can find more information in HTTP caching.
Logging
Self-governance logging is enabled by default and all related logs are stored in the logs directory. Self-governance information is written to the following logs:
decision-audit.log-
This log contains a list of policy decisions made by the policy decision point (PDP).
management-audit.log-
The log contains a list of any actionable self-governance requests.
debug.log-
This is the Policy Editor application log. You can use it to debug any application-related issues.