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…

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.