Shibboleth Developers

["Scott Cantor" <>]

> Setting aside for the moment that this does not follow the new world
> order, is it possible given Shibboleth version 1.3 as we know it now?

It has, in essence, nothing to do with Shibboleth today. Shibboleth
addresses the use of SAML browser profiles and queries to authenticate and
exchange attributes between IdP and SP and a client (browser). Anything
further is outside the scope of Shibboleth. It isn't possible or not
possible, it's just something else.

The assertions produced in this process are not particularly suitable for
use in any other context. The authentication assertion is entirely unusable
because it expires in minutes. The attribute assertions tend to be context
neutral. They are generally unsigned today, making them less suitable for
forwarding. Attribute push makes things even more confusing and complex
because there are so many options in how the assertions can be built and no
standards for doing it. That's the reason we started with separate queries.

One could argue that if you're going to trust the engine to do the right
thing anyway, there's no point in making the SP do extra verification and
worry about all the complications, but I guess one school of thought is that
if the SP is part of the federation, it already knows how to evaluate a
signed assertion from the IdP. The Shibboleth core library can do this
independently of context, or at least the C++ can. There are no dependencies
on the web use case in my core code.

> Stumbling naively into what you describe as a really hard problem, does
> the metasearch scenario make a good foundation for the NISO MSE
> committee to work on the scope and potential solutions in this
> proxy/delegation area?  There is a group here that may be willing to
> throw some time/effort into the process.

Yes, but it's an open question how general any solution in this kind of
space will be. From a security standpoint, Liberty is very general, but at
the expense of tightly defining the types of interactions and services and
adding lots of WSF machinery. It doesn't mesh well with somebody with an
arbitrary SOAP service unless they adopt the framework. WS-* addresses that
by essentially letting the application define all the rules.

Most alternatives I've seen historically pick one of those paths, either
defining a tight framework for the app, or leaving so much up for grabs that
every app is a new problem to solve.

But I think somebody needs to just do something. I'm with Howard on that
point.

-- Scott