Shibboleth Developers

["Howard Gilbert" <>]

In both the Shibboleth 1.2 and the SAML 2 Metadata, an Origin Site can be
configured with more than one AttributeAuthority[Descriptor] (and nested
SAML 2 AttributeService Endpoints) with the same bindings, protocols, and
versions. I suppose anyone could put up two redundant AA's for load
balancing or recovery should one fail or be taken down for service (like
having more than one DNS server).

However, SAML 2 Metadata has an icky option. Saml:Attribute element indicate
attributes available at this Authority, suggesting that if the complete set
of attributes is partitioned across two or more AA's that you would have to
query all the AAs and merge the result to get a complete user profile.

I don't think current code at either the Origin or Target will retry a
request that fails to a second endpoint of the same type at a remote site.
Certainly they won't split a request.

So the question is: is the active use of more than one AA (or any other type
of Role/Endpoint) a possible objective in any projected future. The
immediate question is that some of our code creates a single object that
implements the Provider/EntityDescriptor, Role, and Endpoint interfaces in
one object. This implies that, for example, every OriginSite has exactly one
AA that we need to remember after processing the configuration file. If the
configuration file has more than one AA, we select one to keep and reject or
ignore the others. The Interface suggests the more general rule (a site has
an array of roles, each role has an array of endpoints) but the
implementation classes currently fake that out.

Now for the philosophical question: Is there a meaningful different between
an AA with two endpoints and two otherwise identical AAs each with one
endpoint? Obviously one Role with two Endpoint objects is more efficient
than two Roles and two Endpoints (one fewer Role object). However, it seems
that they are functionally equivalent. This implies a code design centered
on (AA,Endpoint) rather than a true hierarchy.

Now that SAML 2 is out for comment, I could certainly use a quick crib sheet
mapping Shibboleth 1.2 items to SAML 2.0 items. Which type of role does the
HS map to? Which type of Endpoint does a Shibboleth AA use? What specific
Binding names match up? The SAML standard and the Shbboleth protocol
document use slightly different notation for what I think is the same thing:

Shibboleth - The attribute authority is a SAML-defined service that supports
a SAML protocol binding and the processing of SAML <samlp:Request> messages
containing the <samlp:AttributeQuery> element.

SAML 2 Metadata - <AttributeService> [One or More] One or more elements of
type EndpointType that describe endpoints that support the profile of the
Attribute Query protocol defined in [SAMLProf].

But is this then Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
And is the NameIDFormat the same as 
<NameIdentifier Format="urn:mace:shibboleth:1.0:nameIdentifier" ...> in a
current Shibboleth assertion? Does that map to any "urn:oasis:names:..."
value?

I can guess the answers, but would rather have confirmation from one who
knows.