Marker
Syntax
(*type)${SOURCE.pathToProperty}
Definition
Consider markers as a means to introduce dynamic values into access policies. They can be placed anywhere within your policy, and during evaluation, AAM will recursively replace them.
A marker is denoted by a leading dollar sign $
and enclosed in curly brackets {...}
. Within the curly brackets, you specify the source of data and the property path, separated by a dot .
. Optionally, you can include a typecast (*type)
.
We provide a comprehensive list of supported marker sources in the Markers section of this documentation. However, you have the flexibility to manage custom sources by utilizing the aam_policy_token_value_filter filter.
FYI!
To learn how to define a custom marker, refer to the How to declare an use a custom marker?
The property path can be intricate, offering flexibility to define its precise nature. For example, you can use square brackets []
to access an array element by index or retrieve a deeply nested property within a multi-level object. Here are some examples of valid paths:
${CONTEXT.Players[0].profile.name}
${USER.address["physical"].zip}
${MAP.Country[USA][NC][Charlotte]}
${PURCHASE.0929431.amount}
Common placements for markers include the Conditions section. In the following policy example, access to the WordPress backend is restricted to users with email domains ending in @gmail.com.
The common place for markers is the Conditions section. In the example policy below, we restrict access to the WordPress backend for all users with the email's domain @gmail.com
.
{
"Statement": [
{
"Effect": "deny",
"Resource": [
"Capability:aam_access_dashboard"
],
"Condition": {
"Like": {
"${USER.user_email}": "*@gmail.com"
}
}
}
]
}
Starting from AAM version 5.8.2, you can typecast the value of a marker. For instance, if ${USER.ID}
returns a numeric value, you can cast it to an integer type.
{
"Statement": [
{
"Effect": "deny",
"Resource": ["Capability:aam_access_dashboard"],
"Condition": {
"Equals": {
"(*int)${USER.ID}": 5
}
}
}
]
}