Shibboleth Developers

["Scott Cantor" <>]

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

That's incorrect. 1.2 supports client-side failover, however pointless it
may be (it's not very efficient to do it).

> Certainly they won't split a request.

That's true, but a fairly obvious limitation that needs to be fixed in the
future at some point. Don't know when.

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

Maybe yours does, but mine doesn't...the endpoint objects are separate, in
particular, allowing for multiple endpoints within a role 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.

My code does not fake all of this, I consume and expose all endpoints, but
as a single logical AA, in keeping with the fact that we don't currently
distinguish between different authorities.

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

Well, sure, those two would be the same, but it would be false to assume
that all authorities listed were necessarily going to be equivalent forever.
In most cases, one authority would be listed with multiple endpoints,
though, something the old metadata didn't support.

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

At the moment, a HS is a SingleSignOnService within the IDP role, but with a
protocol support attribute indicating we support the Shib protocol, and not
SAML 2. It could also be an AuthnAuthority, but that's not anything we
support now.

> Which type of Endpoint does a Shibboleth AA use?

A SAML 1.1 SOAP binding endpoint in an AA role with a protocol indicator of
SAML 1.1.
 
> 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?

Yes, all of that is basically correct. The ability to advertise what Name
formats are supported is new. I haven't fully decided what if anything we
would do with that, apart from just being able to double check that we're
sending a valid query subject.

Shibboleth metadata would be expressed distinctly from SAML2 metadata, with
separate role elements and a protocolSupportEnumeration attribute containing
a URI representing SAML 1.1 or Shibboleth protocol support. We need to
profile the spec for now to precisely define all this for the old stuff.

I can provide an example of how this could look.

-- Scott