This blog post was first published @ http://blogs.forgerock.org/petermajor/, included here with permission.
The ssoadm command line tool is a quite powerful ally if you want to set up your OpenAM environment without performing any operation through the user interface, i.e. when you just want to script everything.
Whilst the tool itself allows you to do almost anything with the OpenAM configuration, finding the right set of commands for performing a certain task, is not always that straightforward… In today’s example we will try to figure out which commands to use to set up an OAuth2 provider.
When using the Common Tasks wizard to set up an OAuth2 Provider we can see that there are essentially two things that the wizard does for us:
- Configure a realm level service for the OAuth2 Provider
- Set up a policy to control access to the /oauth2/authorize endpoint
Setting up a realm level service
Well, we know that we are looking for something that sets up a service, so let’s see what command could help us:
$ openam/bin/ssoadm | grep -i service -B 1
...
--
add-svc-realm
Add service to a realm.
--
...
Well, we want to add a service to a realm, so add-svc-realm sounds like a good fit. Let’s see what parameters it has:
$ openam/bin/ssoadm add-svc-realm
...
Options:
--realm, -e
Name of realm.
--servicename, -s
Service Name.
--attributevalues, -a
Attribute values e.g. homeaddress=here.
--datafile, -D
Name of file that contains attribute values data.
Alright, so the realm is straightforward, but what should we use for servicename and datafile?
Each service in OpenAM has a service schema that describes what kind of attributes can that service contain and with what syntaxes/formats/etc. Since all the default service definitions can be found in ~/openam/config/xml directory, let’s have a look around and see if there is anything OAuth2 related:
$ ls ~/openam/config/xml
... OAuth2Provider.xml ...
After opening up OAuth2Provider.xml we can find the service name under the name attribute of the Service element (happens to be OAuth2Provider).
So the next question is what attributes should you use to populate the service? All the attributes are defined in the very same service definition XML file, so it’s not too difficult to figure out what to do now:
$ echo "forgerock-oauth2-provider-authorization-code-lifetime=60
forgerock-oauth2-provider-refresh-token-lifetime=600
forgerock-oauth2-provider-access-token-lifetime=600" > attrs.txt
$ openam/bin/ssoadm add-svc-realm -e / -s OAuth2Provider -u amadmin -f .pass -D attrs.txt
Creating a policy
Creating a policy is a bit more complex since 12.0.0 and the introduction of XACML policies, but let’s see what we can do about that.
Using ssoadm create-xacml
The XACML XML format is not really pleasant for the eyes, so I would say that you better create that policy using the policy editor first, and then export that policy in XACML format, so that you can automate this flow.
Once you have the policy in XACML format, the ssoadm command itself would look something like this:
$ openam/bin/ssoadm create-xacml -e / -X oauth2-policy.xml -u amadmin -f .pass
Using the REST API
The policy REST endpoints introduced with 12.0.0 are probably a lot more friendly for creating policies, so let’s see how to do that:
$ echo '{
"resources" : [
"http://openam.example.com:8080/openam/oauth2/authorize?*"
],
"subject" : {
"type" : "AuthenticatedUsers"
},
"active" : true,
"name" : "OAuth2ProviderPolicy",
"description" : "",
"applicationName" : "iPlanetAMWebAgentService",
"actionValues" : {
"POST" : true,
"GET" : true
}
}' > policy.json
$ curl -v -H "iplanetdirectorypro: AQIC5wM...*" -H "Content-Type: application/json" -d @policy.json http://openam.example.com:8080/openam/json/policies?_action=create
Hope you found this useful.
Last week, ForgeRock hosted its first european Open Identity Summit, in the “Chateau de Béhoust” just outside Paris. For two and half days, our 110+ visitors, a mix of customers, prospect customers, partners and consultants, could attend presentations, meet and greet with ForgeRock employees, have lengthy discussions with peers, exchanging experience or use case scenarios around the ForgeRock Open Identity Stack. All of this in a very relaxed and friendly atmosphere.
