Shibboleth Developers

["Scott Cantor" <>]

>  1. In a <KeyAuthority> the <ds:KeyName> must correspond
>     to a providerId. Putting a DN or a CN in there never got
>     it to match anything for me.

No, it will match KeyNames in metadata, which can be several different
things, basically anything that's in a Name attribute in the sites file
(SiteGroup, Site, HandleService, AttributeAuthority). As you note,
providerId (which is a Site Name) is one of them, but not the only one.

We commonly use SiteGroup for this, so it certainly works with that. I have
tested the other cases as well.

>  2. Putting a cert in a <ds:KeyInfo> and outside a
>     <KeyAuthority> does not make the shar trust anything.
>     (What is the purpose of <ds:KeyInfo> outside of
>     <KeyAuthority>?)

A bare KeyInfo is a direct binding between a KeyName and a public key (you
have to put a KeyName inside the KeyInfo for it to do anything, though). It
doesn't work for SSL, but you can do signed token verification by telling it
that a particular HandleSerbice signs with Key "Foo" and then tell it the
public key for "Foo" in the trust file. That bypasses path validation and
just verifies the signature with the public key. It's for direct key
exchange, basically.

>  3. The most specific providerId for a given relying party
>     that matches a <ds:KeyName> is the only KeyAuthority
>     tried when matching a cert. So if relying party has its
>     own <KeyAuthority>, but there is also another
>     <KeyAuthority> for the federation of which the IdP is a
>     member, only the former will be used. Also, if the same
>     <ds:KeyName> appears in multiple <KeyAuthority>s, only
>     the first match will be used, others will be ignored. 

Roughly true. The trust plugin builds a list of key names that would apply
to a transaction, based on metadata for that IdP. They are somewhat ordered,
in the sense that a KeyName in metadata comes first, then the providerId,
then any groups.

Then it looks for a KeyAuthority that matches, checking each possibility.
First match wins, as you said. And yes, the KeyName in the trust file is
like a unique mapping value, so duplicates don't work.

> Perhaps these things, or the relevant correct information if
> this stuff is wrong, could be documented?

Yes, it's bubbled up to roughly item 3 or 4 on my list. If you'd like to
come help deploy this for me here at OSU, I can bump it a couple of spots...

-- Scott