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
}
}
}
]
}