Shibboleth Developers

["Scott Cantor" <>]

> Everything you need is already part of the protocol and 
> configuration schemas. I would argue that the current C++ 
> code and the resulting configuration examples assume some 
> redundancy in items that need not be redundant. There are 
> some interesting possibilities here if we are willing to draw 
> some distinctions. Or maybe not.

I'm a little unclear on some of what you're trying to propose, particularly
anything that tries to introduce a finer-grained policy distinction
externally than "Service Provider". I think that way lies further madness.

I'm willing to believe that the target should be better able to host
"multiple service providers", and would much rather explore that directly.
And I thought I read you to be saying that Java works better if there's
potentially a single SHIRE endpoint that handles the POST for multiple
applications (be they internal distinctons or actually multiple SPs).

That's fine, but it glosses over the most important reason for multiple
SHIREs. Cookies *cannot* span arbitrary vhosts. So there are technical
reasons why it's necessary to support multiple locations and it seemed to me
that (this being the case) there wasn't a compelling reason to bother making
the whole mess NxN instead of leaving it Nx1. In other words, it seemed more
manageable to insist that a given set of endpoints map to one "thing"
(application) than to deal with multiplexing many endpoints into many
applications.

That being said, I can see the advantage in Tomcat that if the POST
implementation is a servlet, it's nice to leave it in one servlet context
and be able to use it to create sessions in other contexts. That naturally
leads to a multiplexing problem that I think you circumvented by using the
target URL to drive the configuration lookup, which seems reasonable. But
this assumes that the one context can write a cookie that all the others can
read, and that's not a perfect assumption.

As I wrote to you directly, I do think it's worth looking at a different
approach in which the target value is used only to attach the state of an
AuthnRequest (including the actual resource) to a token, and then share the
state between the filter and the SAML profile endpoint. That eliminates some
of the constraints, and allows for applications to get more control over the
request process. It's what we should have done to begin with, but we got a
little lazy.

-- Scott