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!)

I’m happy to report that we’ve fixed an issue in the percent encoding step of our OAuth signature library for the Jersey framework. The issue reported was caused by the fact that we were using Java’s URLEncoder and URLDecoder classes to compute OAuth’s signature base string. Unfortunately those classes do not perform an RFC3986 compliant encoding which is required in OAuth. The main difference is that a space character will be encoded as a + when we need it to be escaped as a %20 (more info here).

To fix this, we’ve chosen to leverage Jersey’s UriComponent class. There is one notable difference though with how one would encode a URI (see here for a very detailed explanation of URIs): OAuth says that the signature base string is built by concatenating the request method, the request URL and the normalized parameters (with & to separate them) and that those elements must be encoded (prior to concatenation). In effect we are re-encoding elements that are already encoded. As Paul noted, it’s as if we wanted to pass the signature base string in a URI… I remember this possibility was mentioned in conversations about debugging OAuth deployment but that’s the only case I remember for this.

Anyway, to illustrate this, below is the piece of code where the bulk of the action happens:


StringBuffer buf = new StringBuffer(request.getRequestMethod().toUpperCase());
URI uri = constructRequestURL(request);
String tp = uri.getScheme();
buf.append('&').append(UriComponent.encode(tp, UriComponent.Type.SCHEME));
tp = uri.getAuthority();
buf.append("%3A%2F%2F").append(UriComponent.encode(tp, UriComponent.Type.AUTHORITY));
tp = uri.getPath();
buf.append(UriComponent.encode(tp, UriComponent.Type.PATH_SEGMENT));
buf.append('&').append(UriComponent.encode(normalizeParameters(request, params), UriComponent.Type.QUERY_PARAM));

Our testing code now also includes elements with spaces to make sure we got it right (thanks to Michael Werle).

Here we are now. The European commission has officially blessed Oracle’s bid for Sun Microsystems. I do think Oracle is a great opportunity to rebound and move forward even though sadness and regrets are very much present today. Thanks to James Gosling for creating this great picture below (his blog post is here):

Sun RIP (by James Gosling)

Thanks to my colleague Hua Cui, our OAuth implementation for OpenSSO is now upgraded to the latest 1.0a revision of the spec. There is no legacy support for (now deprecated) the 1.0 version (the version field hasn’t been changed in OAuth which, to me at least, does suggest deprecation of the previous release).

Since the signature mechanism in itself is not changed, there’s no update necessary to our Jersey OAuth signature library.

Give it a try!

Many people reading my previous posts about our OpenID extension for OpenSSO asked me where is the OP (OpenID Provider) code in the OpenSSO repository. The answer is that there’s no code for it (right now) and the reason for this is that we thought deployers would likely develop their own OP with all the appropriate checks in place. But since I do get these requests and to complete the example I described in previous posts, Below is the source code for the simplest (i.e. dumbest) OP one can think of.

To refresh our memories after the holiday break, the role of the OP web application is to hand out the metadata related to the OpenID identifiers of (presumably known) users. That metadata (in the form of an html page with metadata placed in the <head> section) points to the location of the related OpenID server (for both versions 1 & 2).

In the present example, we will simply hand out that information to any appropriately formed URL (see this post). A real OP should probably verify that the OpenID identifier used corresponds to an existing user.

Please note that for the code below I chose to make my life easier and used the Jersey API to quickly create a simple web application. You can of course use servlets instead (or whatever) but REST is so easy with Jersey!

Apologies for the formatting but the string is way too long to fit in any way I tried. The key parts of that string are the two <link rel=…> elements which define the OpenID endpoints. Of course you’ll need to change those to match your deployment.


import javax.ws.rs.Path;
import javax.ws.rs.GET;
import javax.ws.rs.Produces;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.UriInfo;

/**
* REST Web Service
*
* @author Hubert A. Le Van Gong <hubert.levangong at Sun.COM>
*/

@Path("/{id}")
public class OP {
@Context
private UriInfo context;

String standard_profile = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n"
+ "<!DOCTYPE html PUBLIC\"-//W3C//DTD XHTML 1.0 Transitional//EN\"
+ \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\" >\n"
+"<html xmlns=\"http://www.w3.org/1999/xhtml\">\n"
+ " <head>\n"
+" <link rel=\"openid.server\" href=\"http://openid.example.com:49723/openid/service\"/>\n"
+" <link rel=\"openid2.provider\" href=\"http://openid.example.com:49723/openid/service\"/>\n"
+" <meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\"/>\n"
+" <title>OpenSSO OpenID provider</title>\n"
+" <link rel=\"stylesheet\" type=\"text/css\" href=\"style.css\" />\n"
+" </head>\n"
+" <body>\n"
+" <div class=\"body\">\n"
+" <h2>This OpenID provider is based upon OpenID4Java & supports the following protocols</h2>\n"
+" <UL>\n"
+" <li>OpenID Authentication 2.0</li>\n"
+" <li>OpenID Authentication 1.1 (in compatibility mode)</li>\n"
+" <li>OpenID Attribute Exchange 1.0</li>\n"
+" <li>OpenID Simple Registration 1.0 and 1.1, draft 1</li>\n"
+" </UL>\n"
+" </div>\n"
+" <h2> To see the OpenID ID, view the source of this html page (usually achieved by right-clicking on the page)</h2>"
+" <div>\n"
+" </div>\n"
+" </body>\n"
+"</html>\n";

/** Creates a new instance of OP */
public OP() {
}

/**
* Retrieves representation of an instance of OP
* @return an instance of java.lang.String
*/
@GET
@Produces("text/html")
public String gethtml() {
return standard_profile;
}

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).
         consumerKey(CONSUMER_KEY).
         signatureMethod(RSA_SIGNATURE_METHOD).timestamp(RSA_TIMESTAMP).
         nonce(RSA_NONCE).version(VERSION);

        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();
        params.readRequest(request);
        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.

Follow

Get every new post delivered to your Inbox.