Skip to end of metadata
Go to start of metadata

There are three different kinds of attributes (in no particular order):

  1. Profile Attributes - associated with the user and can be thought of as helping to define the "user identity"
  2. Response Attributes - returned from various endpoints... admittedly the only example I know of is the policy decision endpoint
  3. Session Properties - associated with the user's current session and can thus differ if the same user is logged in multiple times

Profile Attributes

Profile attributes are defined per user and help to define the "identity" of the user.  Examples are email address, employee id, etc.  New profile attributes can only be added by altering the system-wide LDAP schema for all users.  As customers don't like to alter their schemas, new profile attributes are rarely added and will probably be accompanied by an OpenAM restart.

Note there is no agent notification of profile attribute changes although it is actually unclear as to how often, in practise, profile attributes change.  Perhaps it isn't unreasonable to say a user has to log out and log in again (i.e. get a new session) before their attributes will be seen to have changed.

Profile attributes are retrieved from OpenAM based on the results of REST calls to the /json/users/USERID endpoints. Note that with a recent change, this endpoint is now accessible by the agents.

curl -s \
    --header "iplanetDirectoryPro: <AGENT SSO TOKEN>" \
    --header "Accept-API-Version: protocol=1.0,resource=1.0" \
    --header "Content-Type: application/json" \

which may produce output like the following:

  "username": "noggin",
  "realm": "/",
  "mail": [
  "givenName": [
  "objectClass": [
  "dn": [
  "cn": [
    "Noggin The Nog"
  "modifyTimestamp": [
  "employeeNumber": [
  "createTimestamp": [
  "uid": [
  "universalid": [
  "inetUserStatus": [
  "sn": [
    "The Nog"
  "roles": [


Response Attributes

Response attributes are returned most notably from the policy evaluation endpoints /json/policies.  So, creating a policy for access to /examples/* and adding userPassword, dn, cn and sn to the subject attributes, and staticAttributeName1 and staticAttributeValue1 to the static attributes, then evaluating the request as follows:

curl -s \
    --request POST \
    --header 'Content-Type: application/json' \
    --header 'iPlanetDirectoryPro: <AGENT SSO TOKEN>' \
    --data '{
        "resources": [ "" ],
        "application": "iPlanetAMWebAgentService", 
        "subject": { "ssoToken": "<USER SSO TOKEN>" },
        "environment": {
            "requestDnsName": [ "" ], 
            "requestIp": [ "" ] 
     }' ''

gives the response:

    "resource": "",
    "actions": {
      "POST": true,
      "GET": true
    "attributes": {
      "userPassword": [
      "staticAttributeName1": [
      "dn": [
      "cn": [
        "Noggbad The Bad"
      "sn": [
        "The Bad"
    "advices": {},
    "ttl": 9223372036854776000

Session Properties

These are values that belong in a session and may vary between two or more sessions, even if the same user is logged in.

Session properties can be obtained by invoking /json/sessions with an action of getProperty.  You don't need to specify any properties to retrieve as by default you will get all the properties you have whitelisted.  Obviously you will need to have whitelisted some properties before this will work.  This is done in the XUI "Session Property Whitelist Service".  As I couldn't find a list of available properties anywhere in any of the documentation, here is the default list:


For normal users, a session property whitelist is enforced.  For a user to be able to see the value of a particular session property, that property must be whitelisted.  For the agents, the case is different and agents are allowed to see all of the user's session properties whether whitelisted or not.

curl -s \
    -X POST \
    --header 'Content-Type: application/json' \
    --header 'Accept: application/json' \
    --header 'Accept-API-Version: resource=2.0' \
    --header 'iPlanetDirectoryPro: <INSERT TOKEN 1 HERE>' \<INSERT TOKEN 2 HERE>&_action=getProperty'

Note that "TOKEN 2" is the user's token (the one whose session properties you want to retrieve).  Note that "TOKEN 1" may be either an admin token and agent token, or the same as "TOKEN 2".

An example output might be:

  "Locale": "en_US",
  "authInstant": "2017-01-06T11:52:28Z",
  "Organization": "dc=openam,dc=forgerock,dc=org",
  "Principals": "noggin",
  "UserProfile": "Required",
  "CharSet": "UTF-8",
  "successURL": "/openam/console",
  "cookieSupport": "true",
  "SessionHandle": "shandle:AQIC5wM2LY4SfcxygijChz5L6cY9XUkFIYOFkPmeBk_bp9I.*AAJTSQACMDEAAlNLABM0ODcxMzkzNjg5MTk4Nzg2MzEzAAJTMQAA*",
  "Host": "",
  "AuthLevel": "0",
  "clientType": "genericHTML",
  "UserId": "noggin",
  "AMCtxId": "31903ddbcfa3a42301",
  "AuthType": "DataStore",
  "IndexType": "",
  "": "id=noggin,ou=user,dc=openam,dc=forgerock,dc=org",
  "amlbcookie": "01",
  "HostName": "",
  "Principal": "id=noggin,ou=user,dc=openam,dc=forgerock,dc=org",
  "UserToken": "noggin"



  • No labels