Thursday, 12 December 2013

Getting OAuth2 Access Tokens Using SAML2 Assertion

A use case which I've seen been brought up in proof of concepts and client workshops, has been that of using an existing SAML2 IDP assertion as part of an authorization grant for an OAuth2 access/refresh token.  OpenAM v11 provides support for the IETF Draft for SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants as documented in the Admin guide in chapter 13.

This sort of dance is becoming of more interest, as organisations look to leverage not only REST based services (which the OAuth2 endpoints provide), but also the increased use of mobile and non-browser based content delivery.  SAML2 (whether that is dead or not is another blog...) is still pretty much omnipresent in federated landscapes, so being able to make use of existing investments in this area, whilst being able to build out REST based modular services is a very powerful concept.

OpenAM v11 can act as both the SAML2 service provider and OAuth2 authorization server in a single instance, making use of an assertion processing adapter class at org.forgerock.restlet.ext.oauth2.flow.OAuth2Saml2GrantSPAdapter which takes the IDP's SAML2 assertion and passes it across to the /access_token OAuth2 endpoint to respond with a JSON object containing the access token.

A few important steps - although these are documented - is to make sure the SP requests that the assertion is signed and also that the OAuth2 client name matches the SAML2 service provider entity name (ideally a URL, as a non-URL based name seems to cause issue).

Once the token has been retrieved, the /token_info could be called to verify validity or to retrieve associated scopes.  It's also worth noting that the access_token lifetime is not related to the session lifetime at the IDP or SP side.

Monday, 4 November 2013

OpenIDM Shell REST Client

I have recently updated the OpenIDM shell REST client to include pulling back access, activity and recon logs over REST.  The client helps with command line management of an OpenIDM environment by performing admin tasks over the REST interface simply via a menu system.  The set of scripts is just built on curl.

Download the .zip via Github or simply clone the repo.  To run, use ./ (which just acts as menu driven front end) or you can still call the scripts individually.  Make sure you configure your OpenIDM server settings and port.

User management is based on simple create-read-update-delete tasks, as well as doing specific attribute/value searches.

The recon menu allows you to run specific recon tasks, just by adding in the mapping name from the conf/sync.json file.  You can then drill down into the specific recon log entries to check for orphans or missing objects.

I will add more scripts as the endpoints develop.  For further information on the OpenIDM REST API take a look at the OpenIDM Integrators Guide.

OpenAM Shell REST Client

Last week I updated my OpenAM Shell REST client to not only use the newer REST endpoints of v11, but also added an interactive menu, similar to what I had added to the OpenIDM client and OpenDJ one too.

The client was to really test the new API and see what endpoints had been added.  The biggest difference in v11 is the ability to use callbacks within the authentication module response, allowing other attribute values to be passed back to OpenAM, instead of the traditional username and password values.

The client is just a collection of individual shell scripts that call curl and jq for additional JSON parsing.

JQ isn't really needed as OpenAM now offers a
_prettyPrint=true parameter that can do some basic JSON parsing before the response is delivered.  JQ is just useful if you want to iterate over object that comes back and pull out specific attributes.

I then added a simple menu system, just using case, with each menu having it's own file, just to keep the management easy.  A bit of OO in bash :)

To use, simply either download via Github as a zip or clone the repo.  Run ./ to get started (albeit you can still run each script individually).  Add in your OpenAM server settings via option 'C'.  Away you go.  You need to authenticate to do anything.  Authenticating via any method, will create a .token file in the shell client directory which is then reused during subsequent calls to OpenAM as a header value.

You can authenticate to any realm, module or service and then check that your current token is valid.

You then retrieve the attributes associated with that token, before going onto managing objects within then OpenAM repo such as realms, agents, users and so policies.

There are basic create-read-update-delete menus for users, realms and agents, that are simply based on the HTTP verbs GET and PUT.  Creating objects I've simplified by allowing the new object to be added to a JSON file and simply pulled up via a PUT using the _action=create parameter.

For further details on the OpenAM REST client endpoints, take a look at chapter 3 of the Developers guide available at ForgeRock documentation site.