OpenAM privileges delegation
Recently, I have been exploring administration delegation feature of OpenAM 11 and given that i didn’t find any detailed information about this topic, I decided to write down this blog. This article is based on existing OpenAM documentation( http://openam.forgerock.org/openam-documentation/openam-doc-source/doc/admin-guide/index.html#delegate-realm-administration ) and my investigations of this area.
OpenAM has a capability of delegating administrator privileges to certain group of users. This feature is useful in more complex deployments, where more users needs to have permissions to modify OpenAM configuration. For example, let’s imagine scenario, where you have two different realms configured, one for customers and second for internal staff. You want to delegate permissions to modify configuration of this realms to specific users/group of users.
Privileges are applied on realm where they are configured and also inherited to all child realms which can be easily used to define scope, where user will have permissions to perform configuration/administration tasks. This can be configured through OpenAM console. To configure privileges, login as amAdmin and go to Access Control -> <realm name> -> Privileges -> <group name>.
In default OpenAM configuration, you have only top level realm configured and no user group so far. Let’s then try a little example.
- Create a new user – id = poweruser
- Create new group – id = powergroup
- Add poweruser to powergroup
Now if you go to privileges tab in realm configuration, you should see something similar
Now you can delegate some privileges to users which are assigned to this group. If you click on name of the group, privileges which can be given to group are displayed.
List of privileges
Here is a short description of privileges i had a chance to explore. Note that there are few more privileges, that are not described below.
Read and write access only for policy properties
This privilege gives user permissions to create/modify/delete policies in realm and configure Policy Service. If you want to delegate this privilege into subrealm, you also have to create referral policy into subrealm, otherwise privileged user won’t be able to create policies. In addition, this privilege gives user following permissions(according to definition of this privilege in OpenAM configuration store and enabled tabs in OpenAM web console):
- Read only access to datastores
- Read only access to realm configuration
- Read only access to subjects
- Read only access to agent profiles
You can easily check if privilege is correctly applied by logging in OpenAM web console as a privileged user. You are enabled to reach /openam/console endpoint and you can create policies, read agent profiles, etc.
Read and write access to all configured Agents
This privilege gives users permissions to configure all agent profiles. User with this permission can create/modify/delete agent profiles. However user is not given any additional read only permissions on given realm like in “Read and write access for policy properties” privilege case.
You can easily check if privilege is correctly applied by logging into OpenAM web console as a privileged user and trying to create/modify/delete some agent profile(Web, J2EE, OAuth2, etc.).
Read and write access to all log files
This is very specific privilege as it’s not visible in any part of OpenAM web console. There is also no description in OpenAM guide how to tests that user is given this privilege. However i found a way how to ensure that user has write access to OpenAM logs using OpenAM REST API. Example below.
- Enable Read and write access to all log files privileges(as in the example of beginning of this post)
- Use curl to obtain a SSOToken for your privileged user:
curl --request POST --data "username=poweruser&password=password" \ "http://openam.example.com:8080/openam/identity/authenticate" token.id=AQIC5....UzEAAjAx*
- Use this obtained token to create another request which will write message to log
curl "https://openam.example.com:8443/openam/identity/log? \ appid=AQIC5....UzEAAjAx*&subjectid=AQIC5....UzEAAjAx* \ &logname=privileges.test&message=Hello%20profiqs"
- Now you can go to openam configuration folder and observe message in log file named privileges.test.
Read and write access to all federation metadata configurations
This privilege enable users to modify federation related configuration for given realm. User can create IdP and SP entities and create Circles of Trust. I won’t be giving much details on this privilege, but you can ensure if user is granted this privilege correctly by creating Circle of Trust with ssoadm. This privilege does not apply to OpenAM web console – user can’t access federation tab unless he has other privileges that enables access to OpenAM web console.
./ssoadm create-cot -e /s1 -u poweruser -f pw.txt -t sampleCoT2 Circle of trust, sampleCoT2 was created.
And list existing CoTs in realm
./ssoadm list-cots -e /s1 -u poweruser -f pw.txt Followings are the circles of trust. sampleCoT sampleCoT2
Read and write access to all realm and policy properties
This is a special privilege, which gives users same permissions as default amAdmin has, in scope of realm configuration. Also, if this privilege is given in /(top level realm), user became an OpenAM administrator, with access to almost all configuration areas. I won’t give an example for this one, but if you enable this privilege, you can try all examples mentioned above.
One thing that is worth mentioning is that in top level realm, you can also add privileges to “All authenticated users”. This will grant privileges globally to all users who are logged in. So if you for example add a LogWrite privilege to this group, every OpenAM user can write messages to logs.
As i mentioned before, privileges defined in certain realm are inherited into all child realms.
You can see how inheritance is working in scenario with more levels of realms on image above. One thing i discovered is that displaying inherited privileges into subrealms is not currently supported and to see what privileges user group in specific realm has, you need to check all parent realms to that one.