I've been talking with a number of people in the OpenID community  
about higher education, and am currently looking into writing a plugin  
for Shibboleth so that it can talk OpenID just as natively as it does  
SAML.  Of the few Java OpenID libraries that are out there,  
OpenID4Java certainly seemed to be the only one actively developed,  
but I ran into a number of issues when trying to use it to power a  
Shibboleth plugin.  Primarily, it seems to be written less like a  
library and more like a product in places.  By that I mean that many  
pieces are interconnected with concrete classes rather than  
interfaces, making it very difficult to replace certain components.  
Some classes also seemed to be a bit overloaded in what they are  
handling, rather than having a cleaner separation of duties within the  
library.  This isn't to say that OpenID4Java is all bad... certainly  
not.  Obviously quite a few people are using it to much success, and  
I've learned a lot by looking at the code, but it simply isn't  
flexible enough to address my use-case in its current form.

OpenID is a pretty simple protocol, so I spent the last day or so  
sketching out some interfaces for how I think an OpenID library could  
be architected.  It is modeled very heavily after OpenSAML2 because I  
am familiar with it and am incredibly impressed with its design (I can  
say that, since I didn't design it :) ).  Rather than create a new  
project, I'd much rather contribute back to an existing one like  
OpenID4Java, but am not quite sure how that would work in this  
particular case.  You can take a look at what I've done so far here[1]  
and here[2].  It's built with maven and eclipse, so `svn co` however  
you prefer.  So far, I've been focussing the separation of duties...  
keeping Messages & Message Extensions separate from Marshallers &  
Unmarshallers which are separate still from Encoders & Decoders. Take  
a look at MarshallTest in particular... it demonstrates how some of  
the different pieces work together.  It's such a drastic API change  
(and requires Java 1.5 so far) that I imagine it may not be all that  
useful to OpenID4Java, but I wanted to get in touch with you all and  
see before I keep going on this.

Thanks,
will

[0]: http://shibboleth.internet2.edu/
[1]: http://shibfaced.googlecode.com/svn/openid-java/
[2]: http://hunting.usc.edu/openid-java/javadoc/

On 1-Dec-07, at 9:04 PM, Will Norris wrote:

I agree the internal architecture can be improved; after all it's  
just design iteration #1, and our focus when building it was not  
really interoperation with other protocols, but rather the ease of  
use for a web developer trying to openid-enable their site. At times  
it did feel like certain components could use a rewrite.

OpenID-enabling Shibboleth sounds really interesting, and it would be  
nice to have this feature in openid4java, especially after we've done  
a similar thing with OpenID Infocards (using OpenID instead of SAML  
tokens).

How about your rewrite taking place in a branch under openid4java, in  
a manner similar to Debian's testing and stable releases? Once the  
new version is polished and stable, it can be packaged and released  
as "v2 stable".

The things that I would like to keep from the current implementation:
- simple to use for the web developers
- good installation and usage documentation
- same external API, if/where possible (thinking upgrade here)
- Java 1.4 (preference rather than a major issue; not sure how  
heavily you rely on Java 1.5 and how many people out there are still  
on 1.4, but if there's demand a 1.4 port should not be too hard to do).

What do you think? And thanks for your offer again!

Johnny

  - The ProtocolHandlerManager manages multiple ProtocolHandlers.  
Each handler understands some protocol that is used on the wire...  
SAML1, SAML2, ADFS, WS-Trust, OpenID whatever.
  - The RelyingPartyConfigManager deals with information about the  
entity on the other end of the wire... in SAML this is metadata, in  
OpenID this would likely be XRDS.
  - The AttributeResolver provides attributes about the current user.  
These could come from anywhere like a relational database, LDAP  
directory, or flat file.  At a later point, these attributes are  
encoded into protocol specific formats, like a SAML2 attribute, etc.
  - The AttributeFilterEngine takes attributes from the  
AttributeResolver and uses logic to decide which attributes get  
released to which relying parties under which conditions.
  - Then you have lots of internal things like a StorageService,  
MessageDecoders, SessionManagers, TrustEngine etc.

In order to properly integrate this plugin I want to write, I need to  
be able to separate the component which deals with OpenID attributes  
(SReg & AX) and plug it in as encoders to the Attribute Resolver.  I  
need to take the discovery code and plug it into the  
RelyingPartConfigManager.  I need to take the Diffie-Hellman  
validation code and plug it into the TrustEngine.  Basically, I need  
the code to be far more flexible than 99% of users will ever care about.

Shibboleth components are wired together using Spring's IoC container,  
and I'll most certainly use the same for my plugin.  However, if all  
the components are well defined, a fairly lightweight manager class  
would build everything and wire it together.  This would serve the  
same purpose as the current ConsumerManager and SessionManager, but  
would be far lighter-weight since all the heavy lifting is done within  
the individual components.  Would the manager have exactly the same  
external API as the current code?  probably not exactly... it's hard  
to say at this point, but if we minimize the points of contact that  
are required, migration should be fairly trivial.

Documentation is a given, as far as I'm concerned.

I'm relying on Java 1.5 pretty heavily right now for generics, new for  
loop, and enums.  I don't think I've done anything that can't be  
addressed with retroweaver if 1.4 is a requirement.

I don't want anyone to misinterpret what I'm saying to suggest that  
I'm wanting the design of Shibboleth to dictate the design of  
openid4java... that is certainly not the case.  I do believe however  
that Shibboleth provides a very good test case for the flexibility of  
the library.  I think if it is designed well as a whole, and a couple  
of good Manager classes are provided, openid4java could easily address  
both extremes of use cases.

-will

On 3-Dec-07, at 3:22 PM, Will Norris wrote:

Looks like a handful, but I trust a better design will buy  
flexibility and ultimately performance.

Johnny