Shibboleth Developers

[Scott Cantor <>]

You can peruse the latest monster I've created here:

http://usfs2.us.ohio-state.edu/CIC/Shibboleth/config.xml

I think Steven wants to go over it on Monday.

Considerations:

- use XML, to fix problems with nesting and multiple values
- as agnostic as possible with respect to C++ vs. Java vs. ??? Target
- support arbitrary mapping of vhosts and paths to configuration settings
- both inline and external site, trust, AAP commands
- keep it all reloadable
- copy origin credential loading schema
- confuse the heck out of everyone (this one's free, no need to thank me)

Basic outline:

<SHAR> defines how to connect to the SHAR component (might be a null
Listener in Java) and the session cache information.

<SHIRE> defines the web-server interface layer, which mostly is the
<ApplicationMap> that maps requests to applications. Can be inline or file.
This also supports the stuff we currently put in httpd.conf for things like
activating the filter for specific content and such. This is crucial for
IIS, which doesn't have any way to tell the filter what to do. This will
allow decent control on all platforms over when to automatically force a
session.

<Credentials> is an inline copy of Walter's format for specifying keys and
certs.

The rest of the file contains <Application> elements, each with an id. The
root element specifies the default application, which provides all required
settings. Other blocks can override pieces of the configuration.

Each application more or less has a specific "session" entry point, the
SHIRE URL. We still support "vhost-derived" behavior with a relative path.
This file outlines the fact that the SHIRE URL, the cookie name, SSL policy
are all related to controlling session scope, lifetime, etc.

In <Policy> we find the SAML and attribute related settings. We use SAML
<AttributeDesignator> elements if we want to specify what to query. AAP
policy is inline or external, same format as now.

In <Metadata> we specify the site and trust config file(s) or inline XML to
use. This is open to any implementations we plug in, via the type attribute.

Finally, <CredentialUse> specifies a default set of TLS and signing creds,
and allows override by RelyingParty, which is the name of an origin site or
federation.

In combination with the app override support, you can customize the creds to
use per URL per origin site, which is about as bad as I think we want to
get...

The default file we ship should just have the bare minimum of all this stuff
for a standard web site. The annotated example would show all the nasty
options.

-- Scott