Manage policies over REST
Manage the policy service over the REST interface at the openidm/policy
endpoint.
List the defined policies
The following REST call displays a list of all the policies defined in policy.json
(policies for objects other than managed objects). The policy objects are returned in JSON format, with one object for each defined policy ID:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=1.0" \ --request GET \ "http://localhost:8080/openidm/policy" { "_id": "", "resources": [ ... { "resource": "internal/user/*", "properties": [ { "name": "_id", "policies": [ { "policyId": "cannot-contain-characters", "params": { "forbiddenChars": [ "/" ] }, "policyFunction": "\nfunction (fullObject, value, params, property) {\n ...", "policyRequirements": [ "CANNOT_CONTAIN_CHARACTERS" ] } ], "policyRequirements": [ "CANNOT_CONTAIN_CHARACTERS" ] } ... ] ... } ] }
To display the policies that apply to a specific resource, include the resource name in the URL. For example, the following REST call displays the policies that apply to managed users:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=1.0" \ --request GET \ "http://localhost:8080/openidm/policy/managed/user/*" { "_id": "*", "resource": "managed/user/*", "properties": [ { "policyRequirements": [ "VALID_TYPE", "CANNOT_CONTAIN_CHARACTERS" ], "fallbackPolicies": null, "name": "_id", "policies": [ { "policyRequirements": [ "VALID_TYPE" ], "policyId": "valid-type", "params": { "types": [ "string" ] } }, { "policyId": "cannot-contain-characters", "params": { "forbiddenChars": [ "/" ] }, "policyFunction": "...", "policyRequirements": [ "CANNOT_CONTAIN_CHARACTERS" ] } ], "conditionalPolicies": null } ... ] }
Validate objects and properties over REST
To verify that an object adheres to the requirements of all applied policies, include the validateObject
action in the request.
The following example verifies that a new managed user object is acceptable, in terms of the policy requirements. Note that the ID in the URL (test
in this example) is ignored—the action simply validates the object in the JSON payload:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=1.0" \ --header "Content-Type: application/json" \ --request POST \ --data '{ "sn": "Jones", "givenName": "Bob", "telephoneNumber": "0827878921", "passPhrase": null, "mail": "bjones@example.com", "accountStatus": "active", "userName": "bjones@example.com", "password": "123" }' \ "http://localhost:8080/openidm/policy/managed/user/test?_action=validateObject" { "result": false, "failedPolicyRequirements": [ { "policyRequirements": [ { "policyRequirement": "MIN_LENGTH", "params": { "minLength": 8 } } ], "property": "password" }, { "policyRequirements": [ { "policyRequirement": "AT_LEAST_X_CAPITAL_LETTERS", "params": { "numCaps": 1 } } ], "property": "password" } ] }
The result (false
) indicates that the object is not valid. The unfulfilled policy requirements are provided as part of the response - in this case, the user password does not meet the validation requirements.
Use the validateProperty
action to verify that a specific property adheres to the requirements of a policy.
The following example checks whether a user’s new password (12345
) is acceptable:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=1.0" \ --header "Content-Type: application/json" \ --request POST \ --data '{ "password": "12345" }' \ "http://localhost:8080/openidm/policy/managed/user/9dce06d4-2fc1-4830-a92b-bd35c2f6bcbb?_action=validateProperty" { "result": false, "failedPolicyRequirements": [ { "policyRequirements": [ { "policyRequirement": "MIN_LENGTH", "params": { "minLength": 8 } } ], "property": "password" }, { "policyRequirements": [ { "policyRequirement": "AT_LEAST_X_CAPITAL_LETTERS", "params": { "numCaps": 1 } } ], "property": "password" } ] }
The result (false
) indicates that the password is not valid. The unfulfilled policy requirements are provided as part of the response - in this case, the minimum length and the minimum number of capital letters.
Validating a property that fulfills the policy requirements returns a true
result, for example:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=1.0" \ --header "Content-Type: application/json" \ --request POST \ --data '{ "password": "1NewPassword" }' \ "http://localhost:8080/openidm/policy/managed/user/9dce06d4-2fc1-4830-a92b-bd35c2f6bcbb?_action=validateProperty" { "result": true, "failedPolicyRequirements": [] }
Validate field removal
To validate field removal, specify the fields to remove when calling the policy validateProperty
action. You cannot remove fields that:
-
Are required in the
required
schema array. -
Have a
required
policy. -
Have a default value.
The following example validates the removal of the fields description
and givenName
:
curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=1.0" \ --header "Content-Type: application/json" \ --request POST \ --data '{ "_remove": [ "description", "givenName" ] }' \ "http://localhost:8080/openidm/policy/managed/user/ca5a3196-2ed3-4a76-8881-30403dee70e9?_action=validateProperty"
Because givenName
is a required field, IDM returns a failed policy validation:
{
"result": false,
"failedPolicyRequirements": [
{
"policyRequirements": [
{
"policyRequirement": "REQUIRED"
}
],
"property": "givenName"
}
]
}
Force validation of default values
IDM does not perform policy validation for default values specified in the managed objects schema. It may be necessary to force validation when validating properties for an object that does not yet exist. To force validation, include forceValidate=true
in the request URL.
Validate properties to unknown resource paths
To perform a validateProperty
action to a path that is unknown (*
), such as managed/user/*
or managed/user/userDoesntExistYet
, the payload must include:
-
An
object
field that contains the object details. -
A
properties
field that contains the properties to be evaluated.
Pre-registration validation example
A common use case for validating properties for unknown resources is prior to object creation, such as during pre-registration.
-
Always pass the object and properties content in the POST body because IDM has no object to look up.
-
Use any placeholder id in the request URL, as
*
has no special meaning in the API.This example uses a conditional policy for any object with the description
test1
:"password" : { ... "conditionalPolicies" : [ { "condition" : { "type" : "text/javascript", "source" : "(fullObject.description === 'test1')" }, "dependencies" : [ "description" ], "policies" : [ { "policyId" : "at-least-X-capitals", "params" : { "numCaps" : 1 } } ] } ],
-
Using the above conditional policy, you could perform a
validateProperty
action tomanaged/user/*
with the request:curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=1.0" \ --header "Content-Type: application/json" \ --request POST \ --data '{ "object": { "description": "test1" }, "properties": { "password": "passw0rd" } }' \ "http://localhost:8080/openidm/policy/managed/user/*?_action=validateProperty" { "result": false, "failedPolicyRequirements": [ { "policyRequirements": [ { "params": { "numCaps": 1 }, "policyRequirement": "AT_LEAST_X_CAPITAL_LETTERS" } ], "property": "password" } ] }