Shibboleth Developers

Phone #:  (800) 541-1710
Pin #:  0142203

Agenda:

1) Current programming issues/questions
        apache 2 status
        usc problem with SSL
        others?

2) New config file syntax; see Scott's note; pasted in down below

        Date: Fri, 23 Jan 2004 18:51:31 -0500
        From: Scott Cantor 
<>
        Subject: Draft of new target configuration file


3) Review of items  to be included in the next release. We discussed 
this last week; my latest draft is available here:

http://stc.cis.brown.edu/~stc/Projects/Shibboleth/Version-2/Shib-next-features.html

Please review -- I still have some questions, and I'm sure I'm 
misstating things in some cases.

4) status check, and continue the discussion of non-web browser use 
cases (grid, lionshare, XMPP) (please review the two long email 
threads that have occurred over the last few weeks).

I'd like to defer until next week discussion of:

- use cases, requirements for a web based GUI for editing ARPs

-------- Scott's note on new config file -------------------

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.