Computer science

Since last week, I have officially become a Neustar employee (I had been consulting for a while). I really owe this opportunity to none other than =PeterD (Peter you really need to update your blog!).

Although I’m primarily involved in spec writing for the UltraViolet project (bringing some additional perspective from the federated identity angle), I also expect to have a cross-organization role in providing support for questions that pertain to identity management, web security or RESTful architecture.

Lots of work (strike that: tons of work!) and lots of smart people in the company (we hire!)

In previous posts, I mentioned we have implemented an OAuth signature library for Jersey (the JAX-RS reference implementation). This signature library sports client and server filters to insulate the application from most of the OAuth signature process (signing on the client side and verifying the signature on the server). Our main goal is to allow Jersey developers to adopt OAuth to secure their messages. Our initial need though, was for our OpenSSO project which now includes an OAuth Token Service.

In doing some testing on the OpenSSO use of OAuth, we noted there’s was a bug in the server verification code of an RSA signature. I’m happy to announce that the fix is in so you can now happily use RSA-SHA1 to secure OAuth messages (in OpenSSO or simply using Jersey). Similarly to HMAC-SHA1, we have created a comprehensive test for the RSA-SHA1, reusing the same test case used here. If you want to use the library, you should take a look at the test source code.

One thing to note is that all signature algorithm implementations (HMAC-SHA1, RSA-SHA1, more could be added.) use the same interface object class OAuthSignature method. The challenge with that is that those algorithm require different types of secrets (as reflected in the OAuth spec). It is especially true for key-based algorithms like RSA-SHA1 where the sign() method requires a different secret (the private key) than the verify() method (called by the server, using the client’s public key).

In our implementation both methods take an OAuthSecrets object in argument. In the case of a public/private key-based algorithm, this object is expected to contain the private key (or public key in the verification case) within the consumerSecret field. This is indicated in the library’s Javadoc.

On the client side, signing (with RSA-SHA1) a message is quite simple. All you need to sign your message is three elements: the request, the OAuth parameters and your public key. The code below shows how you’d do that with Jersey:

        OAuthParameters params = new OAuthParameters().realm(REALM).

        OAuthSecrets secrets = new OAuthSecrets().consumerSecret(RSA_PRIVKEY);

        OAuthSignature.sign(request, params, secrets);

On the server side, we retrieve the parameters from the request and use the public key (obtained from the client’s X509 certificate). A short example would be:

        params = new OAuthParameters();
        secrets = new OAuthSecrets().consumerSecret(RSA_CERTIFICATE);
        assertTrue(OAuthSignature.verify(request, params, secrets));

A little tip: deploying a war file on different containers / application servers can lead to different results. Although their scope widely differs, Sun has 2 offerings when it comes to deploying a war file: Sun Java System Web Server (SJWS) and Glassfish.

Well, it turns out that Glassfish replaces the entire content of the directory where the application is deployed while Sun JSWS will simply overwrite the existing files, thus leaving all other files in place. In a recent case, I had copied some properties file in that directory (after a first deployment) and was surprised to find them there after a re-deploy.

Now, I know that I’m not really supposed to mess around with files of a deployed war but I find it to be a good reminder of the sometimes not so subtle differences between containers.

When it comes to software, I like to try all available features (even the most obscure ones) and sometimes I end up in a situation where my chances of recovery seem pretty slim. I recently managed just that by setting my OpenSSO top realm (/) to inactive
Why would I do such thing I hear you say? Well I was trying to solve some issues related to our OpenID 2.0 extension and was experimenting with various realms, so there you have it…

The result of this great inspiration of mine is that I could not log anymore to the admin console; a tad annoying…
The solution (thanks to Shivaram!) is to edit the LDAP configuration tree and change the value of ou=services,dc=opensso,dc=java,dc=net and set it back to active. That’s it, you’re in!

Now me thinks we should change the console so as to prevent this from being possible…

The great thing about being involved in a community like OpenSSO is that you get to meet people (virtually at least) with all kinds of background and knowledge. In my last blog entry I described the standard way of deploying DSEE on Solaris (using DSCC and Java Web Console). While discussing just that on the OpenSSO IRC channel, nettezzaumana described a DSCC-free process to install DSEE. He’s posted it as a comment to my previous entry, check it out!

Today we just added support in our OpenID extension (note to myself: this page needs a serious update…) for another OpenID 2.0 feature: realm & RP validation.

As described in the OpenID 2.0 specification, it is important for an IdP (sorry I mean an OP in OpenID parlance) to verify that the Relying Party (RP) return_to URL (that is the endpoint the browser will be redirected to once authentication has happened at the OP) is indeed an OpenID endpoint. The OP should also verify that this return_to URL is within the realm of the RP. This validation is done by having the OP perform a Yadis-based discovery of the RP (see here for more details).

The OpenID4java library, upon which is built our extension, already supports this validation. To leverage this feature in your OpenSSO deployment, you’ll have to do the following (I’m assuming you already have deployed the OpenID extension; if not, see this post):

  1. Create an XRDS document that you’ll host at the RP site.This file describes the RP endpoint and will be retrieved by the OP. At a minimum the file contains one service description with one endpoint (your return_to URL). To folllow up on the deployment I described in previous posts, my XRDS document (I named it yadis.xml) contains the following information:
    <?xml version="1.0" encoding="UTF-8"?>
       <xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)"
          <Service xlmns="xri://$xrd*($v*2.0)">
  2. In the file (see previous post) add the following property: openid.provider.enforcerpid=true (or false if you don’t want it…)

That’s it; now when your RP makes an authentication request, the OP will validate the RP’s endpoint.

In my previous blog on deploying the OpenID extension with OpenSSO, there is a step (step #3 for OpenSSO) in which you have to add the OpenID attribute you created to OpenSSO’s embedded OpenDS directory.
To be more explicit, a way to achieve this is to connect to you OpenSSO DS store and run the following ldif fragment:

dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( 2.16.840.1.113730.3.1.9990 NAME ‘openid-attributes’ DESC ‘Persisted attributes (OpenID)’ SYNTAX SINGLE-VALUE X-ORIGIN ‘
Attributes (OpenID)’ )

add: objectClasses
objectClasses: ( 2.16.840.1.113730.3.2.9999 NAME ‘openiduser’ DESC ‘Class to hold the OpenID related attributes’ SUP top AUXILIARY MAY ( uid $
openid-attributes ) X-ORIGIN ‘OpenID Attributes object class’ )

To connect to the OpenSSO embedded store, I recommend you use a tool (e.g. Apache Directory Studio). Feed it with the relevant information: hostname (i.e., port (usually 50389) and possibly your encryption method.

Of course, tune the ldif example above to the same name (here openid-attributes) you used in amUser.xml

Next Page »