Shibboleth Developers

["Tom Scavo" <>]

On 7/18/06, RL 'Bob' Morgan 
<>
 wrote:
> > - People are more likely to attempt to use the Java SP code for non-web
> > applications (web services, grids, client/server, etc.) applications
> > than the C++ code.  Thus, as much functionality as makes sense should be
> > moved into a set of core code that is divorced from things like the J2EE
> > servlet code.
>
> Hmm, what is a SAML SP other than an implementation of the SAML web
> browser signon profiles?

Well, to first order I would characterize an SP more simply as a
consumer of SAML assertions.  Those assertions *may* be the result of
a SAML AuthnRequest but this isn't necessarily so.  This is the point
I was (ineffectually) trying to make yesterday: If we continue to
think of the SP as a participant in a browser profile, and nothing
more, then we end up with an implementation that is usable in a
browser profile, and nothing more.

There are so many projects wastefully reinventing the SP right now
(because everyone wants to leverage SAML), it isn't funny.  Even
worse, much of this re-implementation is simply not correct since that
requires deep understanding of SAML, which for most of us is lacking.
This project, on the other hand, has that deep understanding, so we
lesser folk would very much like to stand on your backs.  If you would
architect an SP that could be reused and repurposed, it would be a
win-win for everybody.

> What functionality would be provided to support
> non-web applications?  WS-Sec SAML token profile?

The Java SP need not supply any of this out of box, but it sure would
be nice if one could write plugins that extended it in one or more
directions, much like it's possible to extend the IdP today.

> Seems like support for
> use of SAML in non-web scenarios would be in opensaml, or in code specific
> to those scenarios.

This hits the nail right on the head.  In OpenSAMl 1.1, there is no
way to validate an assertion according to section 2 of [SAMLCore] (or
if there is, I'm missing it).  So if OpenSAML 2.0 were able to do this
(no, I haven't looked), that would be a great first step.  Then if the
Java SP let you plug in additional profile support on top of that,
we'd be well on our way.

Tom