Shibboleth Developers

["Scott Cantor" <>]

> 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).

This is how I started as well, but then I added the lazy session handler
(which is a GET), and a local Logout (also a GET), and SAML 2.0 includes
POST, Redirect (GET), and Artifact (GET or POST), and multiple protocols
that use the same bindings and parameters. All in all, I decided to retreat
from "auto-detecting" things and being explicit during deployment. This is
purely an implementation decision, there's no requirement to do it this way.

> So maybe there should be two
> AssertionConsumerService elements with the same Location but different
> Bindings.

That's perfectly legal, and is how you do it in metadata if you multiplex a
single endpoint. Liberty metadata in fact had a single SOAPEndpoint element,
so all protocol traffic using SOAP shared an endpoint. I carved things out
in SAML so that each protocol/profile has a distinct element and people
could multiplex or not as they choose.

> 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.

That's what the IdP does now. There's a flag that favors POST or Artifact
based on which one you want to prefer for a RelyingParty, if the shire value
doesn't tell you outright. I think it's called "defaultToPOST" or something
like that.

> 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.

More or less, although my SessionInitiator code does have some of this
stuff. I also added a requireSessionWith option, which is like
requireSession but allows the RM to trigger an AuthnRequest with a specific
shire value by using the index value in the md:AssertionConsumerService
element in SPConfig. A bit of a hack, but it seemed useful.

> 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.

I'm not sure what you mean exactly. I don't think we'd expect to maintain
the old protocol in 2.0 except for compatibility with older Shib versions.
We'd use SAML 2.0 for requests. In that sense, it's deprecated, I guess.

> 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.

SAML 2.0 requests can specify an index into metadata, or an actual location
and binding to use, or leave it to the default.

> 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.

It could do that, but ours does not at the moment.

> Let's walk through this one.

I want to note before I go any farther that I wasn't trying to insist that
the Java code use exactly the same approach that I did. I said up front "if
we wanted things to work the same", but I don't think we have to do that if
it doesn't make sense. If we can support roughly the same configuration,
that might be enough compatibility, even if there are some small differences
in how some of the config is used.

Also, I don't object to adding C++ code to support absolute URLs in those
Location attributes. I don't think it would be a problem to just create a
hashtable of the complete URLs and match against that instead of the path
info trick I use now. We could even release a new SP in conjunction with the
Java version that implements that feature, so that as of that release, both
versions can support absolute locations.

I think the issue is whether anybody has the concerns I had about
duplicating the hostname all over, so we'd have to get some feedback.

> 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.

In other words, there's a very loose coupling between that information and
the resources being served up, which is typically not the case in other
servers. Most servers let you specify particular document roots for each
vhost.

That said, doesn't the HttpServletRequest object include methods like
getPort, getScheme, etc? And aren't those values *supposed* to be determined
not by the actual request but by settings in the connector? I think that's
how proxying and load balancing work, just like Apache.

The getHost or getServerName call, if it exists, probably has the same flaw
as IIS has when you access the SERVER_NAME value...it's not the "canonical"
name of the vhost, but the client's request hostname. This creates problems
since metaata and other information usually refers to the canonical DNS
name, regardless of what the client sends.

> 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.

That seems like a consequence of using a servlet (in its own context) to do
the work instead of just embedding that functionality in the filter itself.
I never fully understood why that was a good idea.

To put it another way, the C++ SP *does* require that
https://sp.example.org:9443/secure/Shibboleth.sso/SAML/POST be in the
metadata, but I don't see that as a problem. There's a limited set either
way, at most maybe one set per servlet context.

> Currently it is not in the SPConfig, and you
> say it would make things incompatible if I tried to add it there.

It would be different, but that's not necessarily a problem. I don't think
we have required that the exact same configuration file work completely
identically between them. If they share the same general syntax, I think
that's a big win, but if a few small changes are needed, I don't think
that's fatal.

> 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.

I'm not sure if you need the whole prefix. You may need the hostname, or
more likely, a set of "legal" hostnames with a default one that you can
compare to what the client supplied, much like I do for IIS. Then you can
"canonicalize" the URL as Apache does so that a predictable path into the
server exists. I think you can get the scheme and port from the servlet
interface.

Note that you could do this in shibboleth.xml as well, not just web.xml.
There could be a <Java> element in the <Implementation> section that is
similar to the <ISAPI> element. That section was created to support
platform-specific extensions that might be required. Each Java filter
instance could be defined in that section with the legal hostnames defined
for it. Just something to consider, admittedly using web.xml might make
sense too.

> 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.

That's not something I guarantee either (at least not the Metadata). The
default handlerURL is relative, so that the prefix comes from the request,
but I have no way to promise that that's the "right" thing to send. If the
metadata's wrong, the IdP will complain.

> 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".

The C++ handlerURL is not just /Shibboleth.sso. It's one of three possible
syntaxes:

/Shibboleth.sso
        Relative path, so the scheme, host, port come from resource

https:///Shibboleth.sso
        Special syntax, scheme is fixed, but host/port come from resource

https://host:port/Shibboleth.sso
        Absolute URL, everything is predetermined

This accomodates a lot of different cases. If the Java code wanted to, it
could perhaps only support the absolute handlerURL syntax, or it could
support all of them, but have the hostname determined by matching the
client's request against something in web.xml or shibboleth.xml.

I don't think it would be that unusual to have to deal with the hostname
this way. This has been an issue on every server, really, but not a major
problem at deploy time in most cases.

-- Scott