Shibboleth Developers

[Tom Scavo <>]

On 11/3/05, RL 'Bob' Morgan 
<>
 wrote:
>
> So this doesn't make the case for mapping.

I wasn't implying that of course.  I was suggesting that "classic"
SAML/Shib doesn't necessarily apply in grid space, so a different set
of AuthnRequest options are required in this case.  I was simply
offering a different perspective.

> > Instead of mapping the AuthnRequest schema onto yet another API, why not
> > simply pass the SAML itself and leave it to the SSO provider to parse.
> > In the end, everyone will consume and produce SAML, right? ;-)
>
> Sure, I should have mentioned this as an option, but I assumed it was
> unattractive by definition.

Not necessarily.  Looking forward, we see SAML consumption/production
in the strangest places.  Globus Toolkit already consumes SAML
attribute assertions and will soon consume SAML authentication
assertions as well.  MyProxy will soon produce authentication
assertions, and shortly thereafter consume both authentication
assertions and attribute assertions.  And of course, everything
produces and consumes SAML metadata.

> If I were faced with this requirement, I
> would look around for existing code that parsed the AuthnRequest, and
> voila, there's some right inside Shib!

Exactly.  So an alternative approach is to write SAML interfaces and
implementations in Shib (or OpenSAML, rather) and let others build on
those interfaces as needed or use the provided implementations
straightaway.  I think this is where OpenSAML is headed right now, so
I guess I'm questioning this "other API" approach in light of a
modular, extensible version of OpenSAML.  If I have to integrate my
middleware with Shib, why not layer in SAML interfaces as required?

Tom