Shibboleth Developers

["Howard Gilbert" <>]

The Idp and SP now support both POST and Artifact protocols. I have
discovered that the IdP chooses the protocol by lookup up the URL of the
AssertionConsumer in the SP Entity definition in the Metadata to determine
which protocol it supports.

<AssertionConsumerService index="1" isDefault="true"
        Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
        Location="https://sp.example.org/Shibboleth.sso/SAML/POST"/>
<AssertionConsumerService index="2"
        Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
        Location="https://sp.example.org/Shibboleth.sso/SAML/Artifact"/>

Thus, if the IdP receives a redirected Browser with a "return address" of
.../POST it does the POST Profile and if it ends in .../Artifact it does the
Artifact profile.

The IdP appears to be configured to do Attribute Push or not. I believe
based on my own code that if the IdP does Attribute Push to an SP that
doesn't support it the attributes will be ignored and the AA will receive a
query anyway.

The IdP gets its URL parameters, including the return consumer URL, from the
Resource Manager. The C++ RMs are Web Server Filters (ISAPI, mod_shib, etc.)
and in turn peer into the SPConfig in the SP configuration file. The Java SP
duplicates this capability to keep the configurations in line.

The SPConfig now specifies the AssertionConsumer url in the Sessions object.
Although the old shireURL is still supported for compatibility, it is
deprecated. The new choice has two pieces. A prefix, that might be called
the pseudo-CGI part, is specified in the handlerURL

<Sessions lifetime="7200" timeout="3600" checkAddress="false"
  handlerURL="/Shibboleth.sso" handlerSSL="false" 
  idpHistory="true" idpHistoryDays="7">

Then a suffix is added by embedding a modified subset of the metadata
elements:

<md:AssertionConsumerService Location="/SAML/POST" 
        isDefault="true" index="1"
        Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"/>
<md:AssertionConsumerService Location="/SAML/Artifact" index="2"
        Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"/>

OK, now there are several problems:

If you compare the AssertionConsumerService/@Location in the SPConfig with
the one in the Metadata, you see that the Metadata has a complete URL while
the SPConfig only has a suffix that is used to select the protocol. To build
a full URL you have to add the schema, hostname, port, and context, then add
the pseudo-CGI from Sessions/@handlerURL, and then add @Location. In
general, there is no obvious or reliable source for the server part. The
Resource Manager knows its own URL, but there is no reason to believe that
the AssertionConsumer is on the same schema or port, and may not even be on
the same host. For example, the RM may use http because the data is not
sensitive enough to require encryption, but the AssertionConsumer would run
on an SSL port number. In Java, it is possible for either the SP or the RM
to provide the context to which the Assertions are presented.

I do not find that the duplication of elements, with varied semantics, has
been helpful here. I am inclined in the Java SP to revert back to the
original Metadata semantics and use a fully qualified URL for the
AssertionConsumerService/@Location rather than a suffix. This means I will
ignore the Sessions/@handlerURL because it will be embedded.

More broadly, I think we need to take a long term view of Session protocol
selection. The IdP and SP may be at different levels and reflect different
capabilities, especially when one or the other is foreign code. Rather than
putting in hard coded options (the force-push IdP option, or the
default="yes", it makes sense for some code, probably duplicated at both
ends and maybe even in the WAYF as well, to compare the Meatadata of the two
Entities and choose an optimal protocol from the ones available. Attribute
Push seems better if both support it. If not, then Artifact, if it is
supported, might be marginally better than POST followed by the AA query.
Maybe this is an Entity or Federation decision. 

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.
When there are more than one such elements, the IdP is free to choose a
binding based on the best performance or function. Thus in the current
Metadata, the IdP would be free to choose POST or Artifact rather than
having to accept a choice made by the RM, who because he is the one
component that doesn't have access to the Metadata is the one least capable
of making an optimal decision. If this were accepted, then it would reverse
my previous model in that the md:AssertionConsumerService in SPConfig would
be ignore (and would no longer serve a purpose) because the
Sessions/@handlerURL would be all that is required.