Shibboleth Developers

["Howard Gilbert" <>]

> Regarding the form as part of the service provider (even if it is on a 
> completely different site so that the target code is completely 
> unaware of it) means that the service provider will be visited first 
> (by
> definition) but the bit of code in Shibboleth isn't being woken up as 
> it would be in a typical installation.
> 
> Is that a problem?  Apparently not in practice, but the architecture 
> document doesn't help me know this.

This is really an implementation and not an architecture issue. As you
pointed out in your original post, the architecture suggests that the ID
Provider can initiate, so that implies that implementations should not
require (and none do) that there is State between the initial access attempt
and any of the subsequent steps.

However, and this relates both to the previous and the following comment,
the "providerId" part should not be assumed to be entirely obvious. A
Service Provider can have more than one Federation, and certainly can have
more than one FederationProvider plugin. Multiple FederationProviders can be
in the same <Application>. The Request Mapper function maps the Target URL
to an Application ID that in turn decides the providerId that in turn maps
to the Metadata.

OK, so in the real world nobody today is going to get into this mess. But 20
years from now after lots of federation options, the problem is that any
particular campus may have more than one Federation, more than one
providerId in Federations. The same Service Provider can handle multiple
federations and versions of the protocol. Technically, a Service Provider
can handle Shibboleth and other forms of SAML interaction. The same SHIRE
(Authentication Assertion Consumer Service) can through Roles and Endpoints
handle multiple Federations, plus multiple versions of the protocol, plus
multiple protocols (different types of POST and forms of data). I don't
recommend it. I don't think anyone would be stupid enough to configure it.
But the spec doesn't preclude it.

If either the providerId is different in the Metadata of every Federation,
or the providerId AND the configuration of the Site is the same in the
Metadata of every Federation then you probably have no problem. Maybe it is
obvious to everybody not to do anything else.

However, at the moment, what the Architecture is implying is that
"providerId" and "target" ARE THE STATE that has to be carried from the Step
1 encounter with the Resource Manger to the Authentication Post. Given those
two pieces of information it must be possible for the Authentication
Assertion Consumer in the Service Provider to fully classify and properly
save the Authentication Assertion he is getting.

ProviderId may be implied by "target", but at minimum its presence
distinguishes between a Shibboleth 1.2 protocol request and one from earlier
versions of the spec.

> 
> > You sort of see this when your Form includes a "providerID" field.
> > The "shire" you might just know as a well known service URL, and the 
> > "target" is the URL of the Resource data that you are managing.
> > However, you don't just trip over "providerId". It has to match some 
> > magic name configured inside the Shibboleth configuration data.
> 
> Given that the shire address and provider id are both part of the 
> federation metadata, I'd have to regard them both as equally well-known.
>   I'm not sure, therefore, that I'd draw the distinction you're making 
> here.  It's not as if the provider id was only visible within 
> shibboleth.xml.