The more I think and read about the session fixation issue (see the official announcement here and additional info there) that has been discovered in OAuth, the more I’m convinced of the benefits Identity Federation brings to the table.

Think about it, the main issue (beside securing the callback URL which is reasonably easy to achieve) is the fact that the (service) Consumer and the Service Provider can’t currently be sure that the user that has initiated the OAuth flow (and thus has logged in at the Consumer site) is the same user that logs in the Service Provider during the authorization process. If something akin to SAML‘s SSO model were in play (where identities of the principal at the consumer & SP site are federated in a privacy-preserving manner – meaning no correlation issue) then ensuring it is the same user would be a no brainer.

This also can be looked at from the token perspective and what information it conveys. Wouldn’t a SAML assertion be useful here?

Another interesting path would be to use something like Liberty’s Interaction Service to obtain confirmation from the user thus thwarting an attacker to obtain the access token in your name.

<Rant>

One of the things I dislike in the Java world is the number of moving parts I sometimes have to deal with in order to get things going. For instance, as mentioned in my previous post, I often work with XML schemas. To successfully use JAXB, you have to be aware of:

  1. The Java version you’re using (Java SE 6, or 5?)
  2. The version of JAXB (is it 2.0 or 2.1?)
  3. The version of NetBeans (try 7.0 it rocks!)
  4. The OS you’re running all the above on

Depending on the various combination you have, you may need to tune things differently…

For instance the build.xml file contains information that relates to XJC’s location. Up to recently, I was successfully using the following setting on my OS X based machines:

<taskdef name=”xjc” classname=”com.sun.tools.xjc.XJCTask”>

   <classpath>
       <fileset dir=”/Applications/NetBeans/NetBeans 6.5M1.app/Contents/Resources/NetBeans/java2/modules/ext/jaxws21″ includes=”**/*.jar”/>
   </classpath>
</taskdef>

Recently I upgraded to NetBeans 7.0 (which is great btw) and updated accordingly the build.xml for my project so that it matches the new location of jaxws21:

/Applications/NetBeans/NetBeans 7.0M1.app/Contents/Resources/NetBeans/java2/modules/ext/jaxws21

 Unfortunately, I got the following error message when building my project:

taskdef class com.sun.tools.xjc.XJCTask cannot be found

 

It turns out the proper directory is now:

/Applications/NetBeans/NetBeans 7.0M1.app/Contents/Resources/NetBeans/ide10/modules/ext/jaxb

Why the move to another location? Frankly I’m not sure but I bet it has to do with this. This site (named the unofficial JAXB guide) is a great source of information if you’re working with JAXB.

</Rant>

For most projects I’ve been working on lately, I have had to implement a library or an application starting from an XML schema file. There are several ways to generate Java classes from a schema (this process is called binding a schema to a Java representation). Of course, working at SUN, I naturally started with using JAXB

A key element of this binding process is the compiler that generates those Java classes. In JAXB, this task is dedicated to XJC. In order to call XJC you can either run it from the command line or, even better, invoke it directly from your NetBeans project. To do the latter, you will need to modify or add a few files to your project: the overall build.xml of the project and a catalog.xml and a binding.xml that relates directly to the schema(s) you have to start with.

First, you need to add a new target in your build.xml file to instruct NetBeans to generate the code and where to put those classes:

    <target name=”-pre-compile”>
        <echo message=”Compiling the schemas…”/>
        <mkdir dir=”build/gen-src”/>
        <xjc catalog=”Schemas/catalog.xml” binding=”Schemas/binding.xml” destDir=”build/gen-src”>
            <schema dir=”Schemas/”>
                <include name=”*.xsd”/>
            </schema>
            <produces dir=”build/gen-src/com/sun/myproject” includes=”**/*.java”/>
        </xjc>
    </target>

Don’t forget to explicitly declare where XJC can be found. On my Mac, it would look like:

    <taskdef name=”xjc” classname=”com.sun.tools.xjc.XJCTask”>
        <classpath>
            <fileset dir=”/Applications/NetBeans/…/ext/jaxws21″ includes=”**/*.jar”/>
        </classpath>
    </taskdef>

Once this is done, you’ll need to add a catalog.xml file in the schemas directory (or elsewhere). In a nutshell you declare where other resources (like schemas your own schema may depend upon) can be found (e.g. in a local directory or online). An example of such mapping would be:

<?xml version=”1.0″ envoding=”UTF-8″?>
<catalog xmlns=”urn:oasis:names:rc:entity:xmlns:xml:catalog” prefer=”system”>
   <system systemId=”http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd&#8221; uri=”w3-dsig/w3-2002-12-xenc-schema.xsd”/>
   <uri name=”http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd&#8221; uri=”w3-dsig/w3-2002-12-xenc-schema.xsd”/>
   <system systemId=”http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd&#8221; uri=”w3-dsig/w3-2000-09-xmldsig-core-schema.xsd”/>
   <uri name=”http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd&#8221; uri=”w3-dsig/w3-2000-09-xmldsig-core-schema.xsd”/>
</catalog>

You also need, and this is the 3rd file I mentioned, to have a binding.xml file which, among many other things, describes the mapping of the schemas to be compiled with your project structure/hierarchy. For instance, you can say that the Java classes created from the schema w3-2000-09-xmldsig-core-schema.xsd should be packaged as org.w3.xmldsig. An example of such file is below:

<jxb:bindings version=”2.1″
xmlns:jxb=”http://java.sun.com/xml/ns/jaxb&#8221;
xmlns:xs=”http://www.w3.org/2001/XMLSchema&#8221;
xmlns:xjc=”http://java.sun.com/xml/ns/jaxb/xjc”&gt;

    <jxb:bindings schemaLocation=”rest-ds.xsd” node=”//xs:schema”>
        <jxb:schemaBindings>
            <jxb:package name=”com.sun.silverlining.identity”/>
        </jxb:schemaBindings>
    </jxb:bindings>

    <jxb:bindings schemaLocation=”wssecurity-200401-secext-1.0.xsd” node=”//xs:schema”>
        <jxb:schemaBindings>
            <jxb:package name=”oasis.wss.secext”/>
        </jxb:schemaBindings>
    </jxb:bindings>

    <jxb:bindings schemaLocation=”wssecurity-200401-utility-1.0.xsd” node=”//xs:schema”>
        <jxb:schemaBindings>
            <jxb:package name=”oasis.wss.utility”/>
        </jxb:schemaBindings>
    </jxb:bindings>
 
    <jxb:bindings schemaLocation=”liberty-idwsf-utility-v2.0.xsd” node=”//xs:schema”>
        <jxb:schemaBindings>
            <jxb:package name=”liberty.util”/>
        </jxb:schemaBindings>
    </jxb:bindings>

</jxb:bindings>

Don’t forget to instruct NetBeans to look for those newly generated classes. for this, in NetBeans, go to the properties of your project and look at the Sources in the Categories tab. There you should add the folder you declared in the build.xml file (in the above example: build/gen-src).

That’s it!
Building your project should now automatically generate Java classes from the schema and then build the whole project.