Google Apps and Sun Access Manager

I did some work on trying to configure Google Apps Education with Sun Access Manager. Both apps supports SAML 2.0, and should in theory work smooth together.

The general challenge with SAML 2.0 is that the standard is wide, leaving alot of options for the apps, and apps tends to support a subset of all possible configurations.

Some examples of things that may differ: NameID formats, SSO and SLO bindings (Browser/POST, Artifact, HTTP-REDIRECT etc), attribute push versus attribute profile, kind of PKI (POST simple bind versus xmldsig), management of PKI (selfsigned, own root, trusted root, revocation, etc), use of PKI (what to sign, response or assertion, require signed requests, etc), storage of certs (keystores versus metadata) and last but not less important attribute namespaces, syntax and semantics.

First challenge was to figure out the SP Meta data for Google Apps. I could not find it on their pages, could be me fault. So I kind of reversed engineered the meta data instead. By decoding the AuthNRequest in the HTTP-REDIRECT using my home-made SAML 2.0 debuggin tool, I got AssertionConsumerURL and NameID format and so on.

I had some problems with nullpointer exception because Google Apps did not set the optional SAML 2.0 attribute AuthNRequest@ForceAuthN. I am not sure that was because of a local patch I have applied or because I had a outdated patchlevel on the SAML 2.0 module, at least it is working OK now with SAML 2.0 plugin patchlevel 2 and 3.

Next was the real challenge, and what will cause troubles for you if you try to do the same: the NameID format. In the AuthNRequest, Goole Apps will ask for this NameID format: urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified. Translated to english this means "I don't want to tell you what NameID format I want, do what you want and see if it works". Digging in Google Apps documentation I found a reference which indicated that Google Apps only support getting back the NameID format urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress. Sun Access Manager does not support this NameID format out of the box, so what you should do is then to write your own custom IdPAccountMapper, using the IdPAccountMapper SPI in Sun Access Manager. I was told by some friend at Sun that there was a bug in patchlevel 2 that would not let you write such a plugin properly. This bug is fixed but will not be out until patchlevel 4 (probably). Therefore I put this integration on hold for a while. I will probably come back with an article when I have the integration in place, making available an open source GoogleFriendlyIdPAccountMapper.

Andreas Ã…kre Solberg -

Andreas Åkre Solberg - Feide/UNINETT � Google Apps and Sun Access Manager [IMG [Technorati links]]

Hi Andreas, i wish I could

Hi Andreas,

i wish I could have some more time to work together with you in this area. It is a very interesting topic. I will try to make something in my very scarce free time, but if you make some progress, let me know. I will investigate on the plugin. I recently worte an IdpAttribute Mapper, but not an account mapper.

Great work you have done here !

Victor

Andreas Ã…kre Solberg -

Andreas Åkre Solberg - Feide/UNINETT � Google Apps and Sun Access Manager [IMG [Technorati links]]

Hi Tom -

Hi Tom - urn:oasis:names:tc:SAML:2.0:nameidformat:unspecified is fine - check out the SAML 2.0 core specification - line 2133. Same for urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress.

The NameID

The NameID formats

urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified

urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress

are bogus. They should be

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

Looks like a Google App bug.

Tom