A quick summary of the OAuth support we’ve recently added in a couple of key projects.

If you’re into RESTful web services and OAuth, we have implemented an extension to the Jersey project (the JAX-RS Reference Implementation). This extension allows for the signing and/or the verification of OAuth 1.0 based requests. It is based on a digital signature library accessed by server and client filters. Detailed information can be found here.

For people interested in a more integrated solution, we have also implemented a module for the open source project OpenSSO to supports OAuth as an authentication module. This module handles the Service Provider side, that is: token issuance, token & message verification as well as SSO session handling (to bridge with other protocols). This module is, for now, an extension to OpenSSO. In other words it is not yet part of the core OpenSSO and should be considered as more experimental. Beside the Java doc, a good source of information on this can be found in this article. There’s also Pat’s demo at Community One this year.

If you’re so inclined, give it a try – any feedback is more than welcome!

As mentioned before, during this last JavaOne, my colleague Pat Patterson has been showing a demo that leverages JavaFX and our OpenSSO’s OAuth module (preview for now). Daniel Raskin (our OpenSSO marketing guru at Sun) and him have created a video about the demo here. Check it out, it’s informative and very funny.

Yesterday, I attended the OAuth BOF that took place during the IETF meeting in San Francisco. My participation was virtual though, since I was not physically there but thanks to live mp3 coverage and a chat room it was actually possible to follow the discussions and ask questions – very nice.
There were lots of discussions addressing several areas; here’s my recollection on the main points that were discussed:

  • Interoperability: what elements do people think are must-haves to ensure interoperable implementations of the IETF OAuth specification? Mandating a minimum set of signature algorithms (yes!).
  • Backward compatibility: although very important, we should not prevent ourselves from changing key aspects of the specification for the sake of backward compatibility. This is especially true for security issues. Of course, when not essential, changes that would break compatibility will be discarded.
  • Items to be worked on: via the chat room (see log here), I asked if the 2-legged scenario¬†could be considered as relevant to this specification¬†(the 2-legged case is when the service consumer is equivalent to the principal. In other words, we only have 2 parties involved in the transaction). To my satisfaction, many people agreed and so, after a hum in the room passed, it was agreed to include that use case in this work.
  • Charter: although the goal was to not change it, 2 important modifications will be made: integrate the 2-legged scenario and water down the compatibility constraints.

Overall I think this was a good meeting and we now have an official OAuth working group at IETF (well, once the normal process is completed).

While deploying OpenSSO on Glassfish (I used v2ur2), I ran in an interesting situatation:
Although deployment goes well, OpenSSO’s configurator (that is the process OpenSSO goes through the very first time you launch it after deployment) failed with a rather laconic LDAP operation failed message. Searching into the Glassfish server log, I could see that indeed LDAP had a problem:

Message:The LDAP operation failed.
The lower level exception message
error result
The lower level exception:
netscape.ldap.LDAPException: error result (68); The entry
dc=net cannot be added because an entry with that name already exists
at netscape.ldap.LDAPConnection.checkMsg(LDAPConnection.java:4866)
at netscape.ldap.LDAPConnection.add(LDAPConnection.java:2864)
at netscape.ldap.LDAPConnection.add(LDAPConnection.java:2879)
at netscape.ldap.LDAPConnection.add(LDAPConnection.java:2829)

After consulting experts on the matter, I had the solution to my issue:
Modify Glassfish’s domain.xml configuration file of the domain OpenSSO is deployed in (most of the time it will be the default: domain1).
The change is fairly simple:

Good to know…