OpenAM as an OAuth 2.0 authorization server – part 1

par | Nov 6, 2014 | Gestion des Identités

I recently wrote a few scripts to test OpenAM REST and OAuth 2.0 endpoints, in a somewhat usual environment where OpenAM is hidden behind a reverse proxy where an OpenAM agent enforces some URL policies.  Some details are worth noticing so I decided to start this article …

The first thing when working with OAuth 2.0 and OpenAM is to obtain a valid OpenAM token, as a resource owner:

./get_OpenAM_token.sh user password

{ « tokenId »: « AQI….. gx* », « successUrl »: « /auth/idm/EndUser » }

One can make sure at any time that the token is valid :

 ./isTokenValid.sh AQI….. gx*

boolean=true

Then, we can request an OAuth2 code, to later use it to request an access token:

./get_OAuth2_code.sh AQI….. gx*

Location:
302

In the latest script above, I use a public URL to connect to the OAuth 2.0 authorization server, and ask for a redirection to an internal URL, with the OAuth2 redirect_uri parameter. I also display:

– the authorization server HTTP return code (302)

– the location where I’m redirected (https://openam.myinternaldomain:…)

– the URL initially requested …)

 

The points of interest here are that:

 

1- The request must be HTTPS. Otherwise, the OAuth 2.0 client (curl actually) will see this :

Location:https://openam.myinternaldomain:8443/auth/oauth2c/OAuthProxy.jsp?error=access_denied&error_description=The%20authorization%20server%20can%20not%20authorize%20the%20resource%20owner.&state=myState

302

And also, the OpenAM debug log will contain this error:

ERROR: The authorization server can not authorize the resource owner.

 

2- The requested URL and the URL where I want to be redirected can of course be totally different.

 

3- A couple of policies must be defined in OpenAM:

– one policy to allow requests across the reverse proxy. This policy will be enforced by the OpenAM agent, as usual.

– one policy to allow requests from the reverse proxy to the OpenAM OAuth 2.0 authorization endpoint. This policy will be enforced by the OpenAM server itself, which thus acts here both as a PDP and PEP.

 

4- The policies can be defined in any realm, which can be different from the OAuth 2.0 agent realm.

 

5- The redirection URI must be known from the OAuth 2.0 authorization server, that is, defined in an OpenAM OAuth 2.0 agent profile. Otherwise, the OAuth 2.0 will get this error:

The redirection URI provided does not match a pre-registered value.

This particular behaviour does not look compliant with the OAuth 2.0 RFC (https://tools.ietf.org/html/rfc6749#section-4.1.1), where the redirect_uri parameter is supposed to be optional. So I made a comment in the OpenAM bugtracker to notice that.

 

6- When using the realm parameter to access the OAuth 2.0 authorization endpoint, it has to match both:

– the realm where the OAuth 2.0 provider service is defined

– the realm from which the OpenAM token was obtained by the resource owner

But it doesn’t necessarily have to match neither the OAuth 2.0 agent realm nor the realm where the policies are defined.

janua
Les derniers articles par janua (tout voir)