Shibboleth Developers

["Scott Cantor" <>]

> I have now coded every interface except Revocations. [Revocations Chapter
> 5 Verse 7: "And I beheld a certificate. Its name was 
> "CN=Legion", and its serial number was 666."]

That sounds more fun than the actual Revocation work, so you should do that
instead.

> I am now to the point where I need to answer the questions I swept under
> the rug. What exactly is the "audience" collection? When exactly should a
> request for an unknown applicationId return an error instead 
> of "default"?

My best stab at this...

Prior to 1.2, Audience was used in its old SAML sense as a logical "policy"
URI, kind of like a policy OID, and each end had to share a value in its
configuration to interop. An InQueue origin would include urn:mace:inqueue,
and the target would configure that into it's "policy" set to work with
InQueue.

With 1.2, we dumped this to prepare for the more Liberty-like usage that I'm
expecting to see in SAML 2.0, where Audience normally is used as a way of
identifying the relying party (or parties) who can use an assertion, which
in the browser SSO profile, generally means you name the SP in an Audience.

But we had to interop with 1.1, so we kind of do both. The target code in
1.2 builds the Audience list for a particular request by adding the
providerId for the <Application> to the list of <Audience> elements in that
<Application>. With a 1.2 origin, all you'll get usually is the SP's
providerId in the assertion (the one passed to the HS in the providerId
parameter). That matches the value we add implicitly in the target and it
just works. For 1.1 origins, you'll get some value like urn:mace:inqueue,
and you have to have an <Audience> matching that in shibboleth.xml.

(Yes, this is a mess.)

As to the second question, I think the way to answer this is that it depends
which config API is involved. When you interact with the IRequestMap API,
you MUST always get back an applicationId, and if one isn't specified for a
request, the mapper returns "default" as a reserved value in the PropertySet
that it sends back for the request.

Whereas when you use the IConfig interface (the root interface I supplied to
bootstrap things) and call getApplication (which takes an applicationId),
you're always passing in *something*. Either a specific value or "default".
In that case, you may get back NULL if the id/key you pass in doesn't exist,
and that's an error.

So the former returns *something* ("default" being the last resort) while
the latter just matches what you give it to the set it knows about, and the
<Applications> element that is the root of the config tree is registered in
the hash table as "default". This was sort of a hack too, since the
RequestMap and the Application "map" have to be a little "in cahoots".

-- Scott