Scripting a Policy Condition
You can use scripts to tailor the actions AM does as part of policy evaluation to your environment.
AM includes a sample policy condition script that demonstrates how to access a user's profile information, use that information in HTTP calls, and make a policy decision based on the outcome.
To examine the contents of the sample policy condition script in the AM console, navigate to Realms > Top Level Realm > Scripts, and then select Scripted Policy Condition.
Related information:
Preparing AM to use Scripted Policy Conditions
AM requires a small amount of configuration before trying the default policy condition script. The default policy condition script requires that the subject of the policy has an address in their profile. The script compares the address to the country in the resource URL and to the country from which the request originated, as determined by an external GeoIP web service. The demo
user also requires access to evaluate policies.
Tasks:
In this procedure, add an address value to the demo
user's profile. The default policy condition script uses the address when performing policy evaluation.
Log in as an AM administrator, for example
amAdmin
.Select Realms > Top Level Realm > Identities.
On the Identities tab, select the
demo
user.In Home Address, enter a valid address. For example:
201 Mission St, Suite 2900, San Francisco, CA 94105
Select Save Changes.
In this procedure, add a user to a group and assign the privilege required to perform policy evaluations.
Log in as an AM administrator, for example
amAdmin
.Select Realms > Top Level Realm > Identities.
Select Add Identity, enter an ID for the identity, such as
restPolicyUser
, complete the required fields, and then select Create.Return to Realms > Top Level Realm > Identities. On the Groups tab, select Add Group, enter an ID for the group, such as
policyEval
, and then select Create.Return to Realms > Top Level Realm > Identities.
Select the user you created, for example,
restPolicyUser
.Select the Groups tab.
In the Name box, select the group created in step 3, for example
policyEval
.Select Save Changes.
Select Realms > Top Level Realm > Identities > Groups.
Select the group created in step 3, for example
policyEval
.On the Privileges tab, select
Policy Admin
.Select Save Changes.
In this procedure, create a policy that uses the default policy condition script. Policy evaluations can then be performed to test the script functionality.
Log in as an AM administrator, for example
amAdmin
.Select Realms > Top Level Realm > Authorization > Policy Sets.
On the Policy Sets page, select
Default Policy Set
.On the Default Policy Set page, select Add a Policy.
Define the policy as follows:
Enter a name for the policy.
Define resources to which the policy applies:
Select
URL
from the Resource Type drop down list.Select the resource pattern
*://*:*/*
from the Resources drop down list.Select Add.
The
*://*:*/*
resource appears in the Resources field.Select Add Resource to add a second resource to the policy.
Select the resource pattern
*://*:*/*?*
from the Resources drop down list.Select Add.
The
*://*:*/*?*
resource appears along with the*://*:*/*
resource in the Resources field.Select Create to create the policy.
The Resources tab appears as follows:
Specify actions to which the policy applies:
Select the Actions tab.
Select GET from the Add an Action drop down list.
The GET action appears in the list of actions. The default state for the GET action is Allow.
The Actions tab appears as follows:
Select Save Changes.
Configure identities to which the policy applies:
Select the Subjects tab.
Select the edit icon—the pencil.
Select Authenticated Users from the Type drop down list.
Select the OK icon—the check mark.
The Subjects tab appears as follows:
Select Save Changes.
Configure environments in which the policy applies:
Select the Environments tab.
Select Add an Environment Condition.
Select Script from the Type drop down list.
Select Scripted Policy Condition from the Script Name drop down list.
Select the OK icon—the check mark.
The Environments tab appears as follows:
Select Save Changes.
No additional configuration is required in the Response Attributes or Details tabs.
This procedure shows how to enable trace-level debug logging for scripted policy conditions, so that logger output from the default policy condition script is recorded.
Ensure that the script containing the debug output you want to capture has executed at least once.
This will create the required logger that can be configured in the next steps.
Log in as the AM administrator,
amAdmin
.Visit the
Logback.jsp
page, for example:https://openam.example.com:8443/openam/Logback.jsp
.In the Add logger drop-down list, select the
scripts.POLICY_CONDITION
class, and then click Add.Locate the newly added
scripts.POLICY_CONDITION
class in the Logger list, and then click Edit.From the Level drop-down list, choose the debug level required. In this example, select
Trace
.From the Appender list, choose the location for the debug output. In this example, select
Policy
.
The result will resemble the following:
At the bottom of the Logback.jsp page, click Save.
Trace-level debug logging is now enabled for scripted policy conditions, with script output appearing in the
/path/to/openam/var/debug/Policy
debug log file.Changes made in the
Logback.jsp
page are not persisted after rebooting AM or the container in which it runs. Repeat the steps above to debug scripted decision nodes.For more information on configuring debug logging, see Debug Logging.
Trying the Default Policy Condition Script
To evaluate against a policy, you must first obtain an SSO token for the subject performing the evaluation, in this case the demo
user. You can then make a call to the policies?_action=evaluate
endpoint, including some environment information, which the policy uses to make an authorization decision.
Obtain an SSO token for the
demo
user:$
curl \ --request POST \ --header "Content-Type: application/json" \ --header "X-OpenAM-Username: demo" \ --header "X-OpenAM-Password: Ch4ng31t" \ --header "Accept-API-Version: resource=2.0, protocol=1.0" \ 'https://openam.example.com:8443/openam/json/realms/root/authenticate'
{ "tokenId":"AQIC5wM...TU3OQ*", "successUrl":"/openam/console", "realm":"/" }
Obtain an SSO token for the user who has the privilege required to evaluate policies. For example,
restPolicyUser
.$
curl \ --request POST \ --header "Content-Type: application/json" \ --header "X-OpenAM-Username: restPolicyUser" \ --header "X-OpenAM-Password: myStrongPassword" \ --header "Accept-API-Version: resource=2.0, protocol=1.0" \ 'https://openam.example.com:8443/openam/json/realms/root/authenticate'
{ "tokenId":"AQIC8aF...TA1OQ*", "successUrl":"/openam/console", "realm":"/" }
Send an evaluation request to the
policies
endpoint, providing the SSO token of therestPolicyUser
user as the value of theiPlanetDirectoryPro
header.In the JSON data, set the
subject
object to the SSO token of thedemo
user. In theresources
object, include a URL that resides on a server in the same country as the address set for thedemo
user. In theenvironment
object, include an IP address that is also based in the same country as the user and the resource.The example below uses the URL of a web site and an IP address located in the United States:
$
curl \ --request POST \ --header "Content-Type: application/json" \ --header "iPlanetDirectoryPro: AQIC8aF...TA1OQ*" \ --data '{ "resources":[ "https://www.us-site.com:8443/index.html" ], "application":"iPlanetAMWebAgentService", "subject":{ "ssoToken":"AQIC5wM...TU3OQ*" }, "environment":{ "IP":[ "38.99.39.210" ] } }' \ "https://openam.example.com:8443/openam/json/realms/root/policies?_action=evaluate"
{ "advices":{}, "ttl":9223372036854775807, "resource":"https://www.us-site.com:8443/index.html", "actions":{ "POST":true, "GET":true }, "attributes":{ "countryOfOrigin":[ "United States" ] } }
If the country in the subject's profile matches the country determined from the source IP in the environment and the country determined from the resource URL, then AM returns a list of actions available. The script will also add an attribute to the response called
countryOfOrigin
with the country as the value.If the countries do not match, no actions are returned. In the following example, the resource URL is based in France, while the IP and user's address in the profile are based in the United States:
$
curl \ --request POST \ --header "Content-Type: application/json" \ --header "iPlanetDirectoryPro: AQIC8aF...TA1OQ*" \ --data '{ "resources":[ "https://www.france-site.com:8443/index.html" ], "application":"iPlanetAMWebAgentService", "subject":{ "ssoToken":"AQIC5wM...TU3OQ*" }, "environment":{ "IP":[ "38.99.39.210" ] } }' \ "https://openam.example.com:8443/openam/json/realms/root/policies?_action=evaluate"
{ "advices": {}, "ttl": 9223372036854775807, "resource": "https://www.france-site.com:8443/index.html", "actions": {}, "attributes": {} }
Policy Condition Script API Functionality
In addition to the functionality provided by "Accessing HTTP Services" and "Debug Logging", scripted policy condition scripts can access the authorization state of a request, the information pertaining a session, and the user profile's data.
This information can then be returned as needed in the response to an authorization request.
Accessing Authorization State
Server-side scripts can access the current authorization state through the following objects:
Object | Type | Description |
---|---|---|
| | Return |
| | Describe the environment passed from the client making the authorization request. For example, the following shows a simple "environment": { "IP": [ "127.0.0.1" ] } |
| | Specify the URI of the resource to which authorization is being requested. |
| | Specify the user ID of the subject that is requesting authorization. |
Accessing Profile Data
Server-side authorization scripts can access profile data of the subject of the authorization request through the methods of the identity
object.
Note
To access the profile data of the subject, they must be logged in and their SSO token must be available.
Method | Parameters | Return Type | Description |
---|---|---|---|
| | | Return the values of the named attribute for the subject of the authorization request. |
| | | Set the named attribute to the values specified by the attribute value for the subject of the authorization request. |
| | | Add an attribute value to the list of attribute values associated with the attribute name for the subject of the authorization request. |
| None | | Commit any changes to the identity repository. CautionYou must call |
Accessing Session Data
Server-side authorization scripts can access session data of the subject of the authorization request through the methods of the session
object.
Note
To access the session data of the subject, they must be logged in and their SSO token must be available.
Method | Parameters | Return Type | Description |
---|---|---|---|
| | | Retrieve properties from the session associated with the subject of the authorization request. See the table below for example properties and their values. |
The following table demonstrates some of the session properties available to the session.getProperty()
method, and example values:
Key | Sample value |
---|---|
AMCtxId | e370cca2-02d6-41f9-a244-2b107206bd2a-122934 |
amlbcookie | 01 |
authInstant | 2018-04-04T09:19:05Z |
AuthLevel | 0 |
CharSet | UTF-8 |
clientType | genericHTML |
FullLoginURL | /openam/XUI/?realm=alpha#login/ |
Host | 198.51.100.1 |
HostName | openam.example.com |
Locale | en_US |
Organization | dc=openam,dc=forgerock,dc=org |
Principal | uid=amAdmin,ou=People,dc=openam,dc=forgerock,dc=org |
Principals | amAdmin |
Service | ldapService |
successURL | /openam/console |
sun.am.UniversalIdentifier | uid=amAdmin,ou=People,dc=openam,dc=forgerock,dc=org |
UserId | amAdmin |
UserProfile | Required |
UserToken | amAdmin |
webhooks | myWebHook |
Setting Authorization Responses
Server-side authorization scripts can return information in the response to an authorization request.
Method | Parameters | Return Type | Description |
---|---|---|---|
| | | Add an attribute to the response to the authorization request. |
| | | Add advice key-value pairs to the response to a failing authorization request. |
| | | Add a time-to-live value, which is a timestamp in milliseconds to the response to a successful authorization. After the time-to-live value the decision is no longer valid. If no value is set, TTL Value defaults to |