About Policies
    • 28 May 2024
    • 2 Minutes to read
    • Dark
    • PDF

    About Policies

    • Dark
    • PDF

    Article summary

    An Authorization Policy is responsible for deciding the "relationship" between WHO (Identity) and WHAT (Asset). When the Identity (typically defined as a user in a Dynamic Group) wishes to do something (Action) with the Asset, the Platform determines which Policies are associated to that user and what the Policy allows the user to access. The Policy can define what the user can access, or, depending on the Policy, it could be permissions for other actions (for example: view, update, delete, approve, etc.). The mechanism for this interaction between the Identity and the Asset is the Application. The Identity uses the Application to accomplish the action with the Asset.

    Policy example: A user using an online application to access their account.

    To make the Policy more fine-grained, the Platform introduces several other objects. For example, Conditions. Conditions can be set to determine when (Date and Time), the Identity might be given access (or be allowed or denied the ability to update a database, approve a loan application, view customer accounts, etc.). Or, a condition could be based on an Identity's IP address, on Identity Attributes and/or Request Attributes.

    Policies are created and managed from the Policy Catalog (in the Authorization Workspace). Before creating Policies, there are a number of "building blocks" that you need to create. See Prerequisites for Building Policies.

    Policies can be created, updated, and deleted on the Policies tab of the Authorization Workspace. The Policies tab contains the following areas:

    Policy Catalog tab: which offers access to all currently defined Policies within the Environment along with the ability to create new Policies.

    Applications tab: contains a full list of all Applications defined within the Environment, along with the ability to create new Applications.

    Policy Icons

    In the Policy Catalog, next to each listed Policy, one or more of the following icons may appear:

    Group 30.pngIndicates that the Policy State is set to Inactive and therefore is not considered in the authorization decision.
    Restricted 30 better.pngIndicates that the Policy Type is Restrictive.
    Oval 1.pngIndicates that the Policy has not been completed and therefore cannot be used in the authorization decision.

    Finally, after creating a Policy successfully, you can view the Map, offering a visual representation of the Policy and click on objects to drill down further on the elements of the Policy.

    Incomplete Policy Indication

    If you have not completed all of the required elements of the Policy, you may get a message asking if you wish to complete the Policy now or complete it later. If you choose to complete it later, a red dot will appear next to the Policy listing in the Policy Catalog and the Policy will not be active. Once you complete the required configurations, the red dot is removed and the Policy will be applied as expected.

    Active/Inactive Indication

    Active Policies are factored into the authorization decision delivered by the Platform. By default, when created or imported, all Policies are Active. You may want to deactivate a Policy by setting its status to Inactive for testing purposes, or for onboarding and offboarding of applications.

    When moving an Inactive Policy to another Environment (by exporting from one Environment and then importing it to another, the Policy will remain Inactive in the source Environment from which it was imported, but will be Active in the Environment where it was imported to. Note that updating a Policy does not affect the Policy State.

    Was this article helpful?