Persistence API – Issue Resolved

I had mentioned in a previous blog an issue I was seeing with my web application and its use of JPA. It turns out (thanks to people on the Glassfish users mailing list) that, after a refactoring, my JPQL query was rendered wrong up by using the name of the table instead of the name of the Java entity.
So
@NamedQueries(name = "Acctoken.findAll", query = "SELECT a FROM Acctoken a")
should have been:
@NamedQuery(name = "AccessToken.findAll", query = "SELECT a FROM AccessToken a")
Simple enough but, as I had written before, the fact that it somehow was working for subsequent calls remains a mystery to me…

Java One 2009 – BOF-4903 Slides

JavaOne’09 is now over. Lots of interesting sessions & great discussions. I loved the demo Pat Patterson made using our OAuth implementation. Marc Hadley and I had our BOF session and were pleasantly surprised to see more people than expected since it was late and in direct competition with JavaOne’s big party. Here are the slides we presented – hopefully this will encourage people to participate and help us in our quest for the ultimate identity framework!

Java Persistence API and Glassfish

Here’s an interesting problem I’m facing.
I have been working on a web application that I’m deploying using Glassfish. The web app leverages the Jersey framework (I really recommend it to anyone interested in RESTful development in Java). I also use the Java Persistence API to store objects in a DB. For all this, I’m using NetBeans tools to create a Persistence Unit and the entities I have to manage (from a DB schema). NetBeans also creates the appropriate mapping of the entities and their Java classes. So far so good…
For each entity, I end up with java classes that look something like this:

@Entity
@Table(name = "ACCTOKEN")
@NamedQueries({@NamedQuery(name = "Acctoken.findAll", query = "SELECT a FROM Acctoken a"),
@NamedQuery(name = "Acctoken.findById", query = "SELECT a FROM Acctoken a WHERE a.id = :id"),
@NamedQuery(name = "Acctoken.findByAcctUri", query = "SELECT a FROM Acctoken a WHERE a.acctUri = :acctUri")
/... more queries .../ })

public class AccessToken implements Serializable { /.../ }

The code above compiles fine and I can deploy the generated war file with Glassfish. However, and this is where I could use suggestions from anyone, I see a weird behaviour upon hitting one of the exposed endpoints:
The very first time I do a POST (or GET), the web application throws an exception that looks like:

Exception [TOPLINK-8034] (Oracle TopLink Essentials - 2.0.1 (Build b04-fcs (04/11/2008))):
oracle.toplink.essentials.exceptions.EJBQLException Exception Description: Error compiling
the query [Acctoken.findByAcctVal: SELECT a FROM Acctoken a WHERE a.acctVal = :acctVal].
Unknown abstract schema type [Acctoken]. at oracle.toplink.essentials.exceptions.
EJBQLException.unknownAbstractSchemaType (EJBQLException.java:494)

What’s funny is that this does not happen in any subsequent access to those URLs, the web app behaves properly. Because subsequent calls are fine I know the mapping does happen and is correct. I thus don’t really have to explicitly list the classes in the persistence.xml file and instead I have the <exclude-unlisted-classes>false</exclude-unlisted-classes> tag. However listing the classes will not help. I have verified this in both Glassfish 2.2 and Glassfish 3: same behaviour.

It really looks like Glassfish (what else?) adopts a “lazy” approach for the mapping to happen and is basically not ready for the 1st call. I already have the <load-on-startup /> tag set in my web.xml and this didn’t help.

So there it is, anyone has an idea?

OAuth Security Issue

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.

OAuth BOF at IETF

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

A tip on configuring OpenSSO with Glassfish-v2ur2

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
ou=BasicUser,ou=CreationTemplates,ou=templates,ou=default,
ou=GlobalConfig,ou=1.0,ou=DAI,ou=services,dc=opensso,dc=java,
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:
Replace
<jvm-options>-client</jvm-options>
with
<jvm-options>-server</jvm-options>

Good to know…

Open Source Starts to Pay Off

OK, this post will sound a bit like a sales pitch (or is it the Coué method?) but I enjoyed reading this article about our latest quarterly report. Yes, our open source strategy seems to finally yield some results and drives concrete (and significant!) revenues.

About time…

Sun’s OpenID Deployment – Supporting Whitelisting

We have published an article on OpenID in this month’s BigAdmin newsletter. The article describes the OpenID deployment we have done here at Sun.

One of the feature we were first to demonstrate with OpenID was to increase the trust a Relying Party can have in the principal’s identity by asserting the fact that this principal is also a Sun employee (in addition to the fact that he owns the OpenID URL). This basically supports the approach of whitelisting “acceptable” OpenID OPs (identity providers) from the standpoint of a Relying Party.

Although its usage is far from satisfying (did you say lack of OpenID Relying Parties?), it has been a great way to leverage  OpenSSO and demonstrate its extension mechanism.

Achieving Privacy in a Federated Identity Management System

As mentioned before, I’m one of the coauthors for an article that is to be published in the proceedings of Financial Cryptography and Data Security 2009. The article is available here:

• Achieving Privacy in a Federated Identity Management System

Any comment is more than welcome of course!

 

©2009 Springer. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the publisher, Springer.

Where is XJC?

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