Shibboleth Developers

["Howard Gilbert" <>]

> > This produces a proposal, just kicked out so you get a better idea of my
> > thinking, that the shireURL sent to the IdP might end in
> > ".../Shibboleth.sso/*". This tells the IdP to use any of the URLs
> configured
> > as AssertionConsumerService/@Location in the Metadata for the SP Entity
> that
> > begin with a prefix specified in the shireURL parameter of the query
> string.
> 
> We really can't. We're not changing the old profile anymore (right?), and
> this wouldn't be legal now. It's also not possible to do this in SAML 2.0,
> as a specific ACS must be identified by location or index, or the default
> is
> used.

OK, now for Plan B (which may restate in more specific language one of the
options you proposed). My AssertionConsumer (and all the logic I can find)
doesn't really trigger on the URL extra path information to decide which
protocol binding is being used. If there is a POST with a FORM it uses the
POST profile and if there is a GET with Artifacts it uses the Artifact
protocol (and actually it doesn't even distinguish based on GET or POST, but
I include them as detail). So maybe there should be two
AssertionConsumerService elements with the same Location but different
Bindings. This doesn't change the protocol, which has a specific URL. An old
IdP could simply chose the first one that matches the shire=, and an
optimized IdP could choose the "best" binding from the set of elements whose
Location matches the shire=. This only depends on a reading of the Metadata
that does not require Location to be unique per element.

After thinking about it, the RM doesn't know the IdP yet, and the WAYF is
not the place to do this sort of thing. So really what I am saying is that
the 2.0 IdP is the first place where code can exist that unambiguously knows
the Metadata for the IdP and SP and can make an optimization decision.

Rather than depending on the shire= to carry new information (the protocol),
I believe that in 2.0 we should seek to relegate it to a deprecated 1.x
compatibility interface. A 1.x IdP may require it to figure out where to
send the Assertion, but a 2.x IdP should be able to figure this out from the
Metadata with some as yet to be decided bit of extra hints and nuances.
Certainly right now if an SP only had one AssertionConsumerService and an
IdP got a request without a shire= parameter, it might be out of spec but
would not be unreasonable for it to guess that the right URL is the only
endpoint available.

> The absolute/relative URL question is more of an implementation choice. I
> could force SP deployers to do the same thing you're proposing if we
> wanted
> to be consistent, although now we have software in the field that uses
> relative, and I'd have to add code to support absolute and change the way
> I
> determine how to dispatch to the handler functions.
> 
> In my case, I didn't implement a way for a "vhost" to have ACS endpoints
> on
> another vhost, so the factoring was already in place to paramterize the
> hostname in most cases (or in most cases the scheme/host/port), and in all
> cases within a Sessions element, all the hostnames had to be the same.

Let's walk through this one.

The SP and a resource, "/secure" in the typical example, initialize in
Tomcat. Tomcat is configured to support one or more host names on one or
more IP addresses and use some ports with SSL and some without. Since Tomcat
doesn't have any fixed prefix that maps to either application, during
initialization it is effectively impossible to specify http or https,
hostname, or port number.

The next thing that happens is that the "/secure" application RM (Filter)
gets a request on some IP address and some hostname and some port that
Tomcat is listening to, and it selects the secure.war context. The request
could be for http://sp.example.org:8080/secure but just as easily it could
be https://sp.example.org:9443/secure. Only the second one gives me a usable
SSL socket, and neither tells me that the SP context is /shibboleth-sp. The
RM can handle the Assertions, but then
https://sp.example.org:9443/secure/Shibboleth.sso/SAML/POST would have to be
in the metadata along with or instead of .../shibboleth-sp/SAML/POST as an
AssertionConsumer location. So somewhere I need to pull
"https://sp.example.org:9443/shibboleth-sp"; out from under a rock. It is in
the Metadata, but so is a lot of useless stuff and it is hard to find which
is the right one to use there. Currently it is not in the SPConfig, and you
say it would make things incompatible if I tried to add it there. To
maintain the relative URL syntax of the C++ configuration, but fill in the
indeterminacy of the Java environment, I can solve this problem by making an
init-param of WEB-INF/web.xml in secure.war the rock from under which the
needed server prefix is extracted.

In the old code (which is still in the HEAD until I check in my changes)
there was a more extreme version that specified the entire SHIRE= url. That
was one solution, but it did not guarantee that the URL provided would match
anything in the Metadata or SPConfig. Creating a parameter which is just the
prefix up to the context, and then adding the "/Shibboleth.sso" from the
handlerURL and the "/SAML/POST" from the
md:AssertionConsumerService/@Location would provide complete compatibility
in the two SPConfigs, but produces a rather odd parameter to document. I
propose calling the init-param the "ServiceProviderURL".