combining development efforts
Will Norris
and address it to the whole community. I know a few people on the
list from elsewhere in the OpenID community, but for everyone else...
a brief intro. My name is Will Norris and I'm a middleware developer
at the University of Southern California. I'm a member of the core
development team for Shibboleth[0], a SAML-based single sign-on
product used primarily in higher education. I've also contributed in
a lesser degree to OpenSAML, the open source library that does all of
the SAML heavy-lifting for Shibboleth.
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/
Johnny Bufu
On 1-Dec-07, at 9:04 PM, Will Norris wrote:
> I guess this is more directed at Johnny, but I figured I'd go ahead
> and address it to the whole community.
On the contrary, the list is the best place to post an offer like
this! I'm doing my best to look over this project and steer it, but
everybody that is involved to some degree should know what's going
on, so thanks for doing this.
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
Will Norris
> 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).
This might not mean what you think. This would be a plugin for
Shibboleth that would use openid4java to handle all of the OpenID
specific stuff. It would use the library just like any other web
application. It wouldn't directly add any functionality to the
library, but would simply require that it be a bit more flexible.
> 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".
sounds good.
> 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).
I'll initially address these by describing the use-case I'm currently
working with. The Shibboleth 2.0 IdP is currently designed such that
every major component is a separate entity with little to no direct
dependence on any others...
- 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
Johnny Bufu
On 3-Dec-07, at 3:22 PM, Will Norris wrote:
>> 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).
>
> This might not mean what you think. This would be a plugin for
> Shibboleth that would use openid4java to handle all of the OpenID
> specific stuff. It would use the library just like any other web
> application. It wouldn't directly add any functionality to the
> library, but would simply require that it be a bit more flexible.
That's fine; from the high-level it will still be OpenID-enabling
Shibboleth, regardless of where the actual plugin code resides.
>> 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".
>
> sounds good.
Ok; I have added your gmail account to the openid4java committers list.
> - 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.
>
[...]
Looks like a handful, but I trust a better design will buy
flexibility and ultimately performance.
Johnny