--- title: Extend the policy service description: You can extend the policy service by adding custom scripted policies, and by adding policies that are applied only under certain conditions. component: pingidm version: 8.1 page_id: pingidm:objects-guide:extending-policies canonical_url: https://docs.pingidentity.com/pingidm/8.1/objects-guide/extending-policies.html keywords: ["Data Object Model", "Policy", "Scripts"] section_ids: custom-scripted-policies: Add custom scripted policies conditional-policy-definitions: Add conditional policy definitions --- # Extend the policy service You can extend the policy service by adding custom scripted policies, and by adding policies that are applied only under certain conditions. ## Add custom scripted policies If your deployment requires additional validation functionality that is not supplied by the default policies, you can add your own policy scripts to your project's `script` directory, and reference them in your project's policy configuration *(tooltip: You can edit the policy configuration over REST at the config/policy endpoint, or directly in the conf/policy.json file.)*. Do not modify the default policy script file (`openidm/bin/defaults/script/policy.js`) as doing so might result in interoperability issues in a future release. To reference additional policy scripts, set the `additionalFiles` property in you policy configuration *(tooltip: You can edit the policy configuration over REST at the config/policy endpoint, or directly in the conf/policy.json file.)*. The following example creates a custom policy that rejects properties with null values. The policy is defined in a script named `mypolicy.js`: ```javascript var policy = { "policyId" : "notNull", "policyExec" : "notNull", "policyRequirements" : ["NOT_NULL"] } addPolicy(policy); function notNull(fullObject, value, params, property) { if (value == null) { var requireNotNull = [ {"policyRequirement": "NOT_NULL"} ]; return requireNotNull; } return []; } ``` The `mypolicy.js` policy is referenced in the `policy.json` configuration file as follows: ```json { "type" : "text/javascript", "file" : "policy.js", "additionalFiles" : ["script/mypolicy.js"], "resources" : [ { ... } ] } ``` | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | | In cases where you are using the admin UI, both `policy.js` and `mypolicy.js` will be run within the client, and then again by the the server. When creating new policies, be aware that these policies may be run in both contexts. | ## Add conditional policy definitions You can extend the policy service to support policies that are applied only under specific conditions. To apply a conditional policy to managed objects, add the policy to your project's managed object configuration *(tooltip: You can edit the managed object configuration over REST at the config/managed endpoint, or directly in the conf/managed.json file.)*. To apply a conditional policy to other objects, add it to your project's policy configuration *(tooltip: You can edit the policy configuration over REST at the config/policy endpoint, or directly in the conf/policy.json file.)*. The following managed object configuration shows a sample conditional policy for the `password` property of managed user objects. The policy indicates that sys-admin users have a more lenient password policy than regular employees: ```json { "objects" : [ { "name" : "user", ... "properties" : { ... "password" : { "title" : "Password", "type" : "string", ... "conditionalPolicies" : [ { "condition" : { "type" : "text/javascript", "source" : "(fullObject.org === 'sys-admin')" }, "dependencies" : [ "org" ], "policies" : [ { "policyId" : "max-age", "params" : { "maxDays" : ["90"] } } ] }, { "condition" : { "type" : "text/javascript", "source" : "(fullObject.org === 'employees')" }, "dependencies" : [ "org" ], "policies" : [ { "policyId" : "max-age", "params" : { "maxDays" : ["30"] } } ] } ], "fallbackPolicies" : [ { "policyId" : "max-age", "params" : { "maxDays" : ["7"] } } ] } ... } ``` To understand how a conditional policy is defined, examine the components of this sample policy. For more information on the policy function, refer to [Policy Implementation Functions](configuring-default-policy.html#policy-function). There are two distinct scripted conditions (defined in the `condition` elements). The first condition asserts that the user object, contained in the `fullObject` argument, is a member of the `sys-admin` org. If that assertion is true, the `max-age` policy is applied to the `password` attribute of the user object, and the maximum number of days that a password may remain unchanged is set to `90`. The second condition asserts that the user object is a member of the `employees` org. If that assertion is true, the `max-age` policy is applied to the `password` attribute of the user object, and the maximum number of days that a password may remain unchanged is set to `30`. In the event that neither condition is met (the user object is not a member of the `sys-admin` org or the `employees` org), an optional fallback policy can be applied. In this example, the fallback policy also references the `max-age` policy and specifies that for such users, their password must be changed after 7 days. The `dependencies` field prevents the condition scripts from being run at all, if the user object does not include an `org` attribute. | | | | - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | This example assumes that a custom `max-age` policy validation function has been defined, as described in [Add Custom Scripted Policies](#custom-scripted-policies). |