Shibboleth Developers

["Howard Gilbert" <>]

Per the request to explain what was decided:

[The Shibboleth Metadata programming interface anticipates the SAML 2.0
Metadata file format. Support for SAML 2.0 format is on the list of things
to do in the next release. In order to test the plug-in capability, I needed
to write at least one alternate implementation of something. Metadata seemed
like a good idea, and SAML 2.0 file format seemed like a good test. At least
that is why this came bubbling up to the top this week.]

To parse the old style:
<FederationProvider
 type="edu.internet2.middleware.shibboleth.common.provider.XMLMetadata"
 uri="/conf/testsites.xml"/>

Change the type to parse the SAML 2.0 file format:                      
<FederationProvider
 type="edu.internet2.middleware.shibboleth.target.SAML2MetadataImpl"
 uri="/conf/SAML2Metadata.xml" />       

In the current Shibboleth configuration file, every site is a Shibboleth
site and every HS or AA is a Shibboleth component.

<OriginSite Name="urn:mace:inqueue:example.edu">
        <AttributeAuthority 
                Location="https://wayf.internet2.edu/shibboleth-1.2/AA";
Name="wayf.internet2.edu"/>

However, in the SAML 2.0 Metadata, Sites become EntityDescriptors. The
Attribute Authority is a Role. It responds to particular protocol bindings
at particular URLs (and maybe other non-Shibboleth SAML protocol bindings at
other URLs. 

<EntityDescriptor entityID="urn:mace:inqueue:example.edu">
  <AttributeAuthorityDescriptor
protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.0:protocol">
    <AttributeService 
      Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"
      Location=" https://wayf.internet2.edu/shibboleth-1.2/AA "/>

Support for the original file format and the new SAML 2 file format is
hidden inside a plugin (the <FederationProvider>). Either plugin produces an
object that exposes a common interface. 

Through this interface, other Shibboleth code can ask for the
EntityDescriptor/Provider for "urn:mace:inqueue:example.edu" and find
objects created from either of the two forms of XML listed above.

The HS, AA, and what were called SHIRE and SHAR are Roles. SAML 2 doesn't
distinguish Origin and Target sites. Every site is an Entity, and the HS is
one Role (an Origin role) and the SHIRE is a different role (a Target role,
although it is now called the SPSSO).

Roles have Endpoints that bind to a particular protocol. The AA is the best
example here. An AA might very well respond to Shibboleth request for
attributes, but in this case it is accepting a Handle generated by the HS.
The same AA might respond to other SAML requests for attributes in which the
Subject was identified in some other way (by a DN, or a netid), and using
various other SAML profiles.

We should not assume that the Federation will supply us with Shibboleth-only
information. Assuming that we might get a SAML 2.0 file in which there is a
mixture of Shibboleth and non-Shibboleth Roles and URLs, where do we filter
out the non-Shibboleth stuff.

The first question I asked was: should we filter out all the non-Shibboleth
roles and endpoints as we read the XML in, so that only Shibboleth stuff is
kept in memory and presented across the program interface. Scott suggested
that this would not be the best long term approach. We might want to see
more of the data later on. So we decided to parse everything and hold it in
memory.

This means that the Shibboleth code that consumes information from the
interface has to look for Roles that implement the right protocols and
Endpoints that declare the right binding strings. So the second question
was, should the plugin that handles the old Shibboleth configuration file
return an identified legacy response (getBinding() returns null, "", or
"legacy-Shibboleth") or do we generate a fake response that is exactly what
will be explicitly coded in a new SAML 2.0 file
("urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding"). Scott suggests that I
code the plugin for old Shibboleth 1.2 metadata to return exactly the same
binding string as is explicitly coded in the SAML 2.0 configuration file.

This is a little more work, because the Binding to return from an HS
Endpoint is different ("urn:mace:shibboleth:1.0") from the binding to return
from an AA Endpoint ("urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding").
Plus, these SAML 2.0 to Shibboleth protocol and binding strings are just
something we are proposing new today and they may change with changes in the
SAML 2.0 spec, subsequent feedback on usage patterns, or just a change of
mind by Scott. That's OK because they are just constants in a class and we
can change them at any time.

The main decision here is that the part of Shibboleth that deals with
"Metadata" per se deals with all metadata, not just Shibboleth Metadata. Now
it might be convenient to gather the filtering code together in one place
where it can be used, but that place will not be hidden behind the current
Metadata interface.

Thus you won't be able to ask Metadata for "the Yale AA" because there may
be more than one of them and some may not respond to Shibboleth. We will
also discourage anyone from thinking about "the Yale Shibboleth AA" because,
as Shibboleth expands its set of protocols, it may use different URLs
(probably different Servlets on the same server) to support current Browser
based requests and future Web Services based requests (I am not saying it
can't all be done in one place, but we don't require it). 

You could build convenience functions to get "the SAML 1.0 SOAP-Binding AA"
for a given institution, but there is generally only one place in the
current code that needs to find any particular type of endpoint and it makes
more sense to just add the logic that loops through the Roles and Endpoints
examining the properties till a usable one shows up.

Although it was not part of the phone call, Scott and I has a previous
"philosophical" discussion on the meaning of Metadata (a discussion of
Meta-Metadata I suppose). The conclusion was that Metadata might contain
more than one Role-Endpoint that a particular Shibboleth
function+version+binding+profile might use. For example, Yale might choose
to put up two redundant AA's at different URL's for either backup/failover
or load balancing purposes. The Shibboleth code under development must
tolerate this, but it need not take advantage of it. While it might be
useful in the future, there is no immediate requirement that failing
requests be retried to a second Endpoint URL if one is present, nor that
requests round-robin through two URL's to spread load. That would be for
some future release.