Shibboleth Developers

[Nate Klingenstein <>]

*Shibboleth-Dev Conference Call*
November 3, 2003

*Participants*

Steven Carmody -- Brown(chair)
Derek Atkins -- MIT
Tom Barton -- Chicago
Scott Cantor -- OSU
Walter Hoehn -- Columbia
Howard Gilbert -- Yale
Bob Morgan -- Washington
Nate Klingenstein -- Internet2(scribe)

*Discussion*

Apache 2

	Derek has successfully gotten the Apache 2 target module working.  He 
wants to continue to refine the code, but this model interoperates 
successfully with 1.1 origins, loads in RedHat 9, and gives full 
Shibboleth functionality.  It's built on top of an unreleased version 
of Apache's libapreq2 module, which needs to be installed using apxs, 
and therefore is unlikely to successfully build unless compiled under 
root.  The code and modified configuration files are reflected in the 
CVS, but won't compile due to the aforementioned module.  There is no 
tarball yet.
	The Apache 2 module doesn't differ significantly from the current 
Apache 1.3.x module, other than a number of directives moved from the 
Apache configuration.  Codewise, the entire target side has been merged 
in the Apache 2 version into a single module named mod_shib.

Target Certificate Handling

	Scott's checked in the new client-side SSL implementation for the 
target library which is successfully functioning under Linux and 
Windows, and is being tested against Solaris.  This is only used by the 
SHAR, so it doesn't affect the Apache modules at all.
	There is a new creds.xml configuration file for the target which is an 
additional metadata type used to specify all kinds of credentials.  The 
schema resembles that used by trust.xml, but has elements called keyUse 
instead of keyAuthority.
	Specified URI's are pulled in as PEM's, although the more general 
problem of pulling keys out of various types of repositories is not yet 
described.  "If you can get a key and cert in a format OpenSSL 
understands in memory, everything else just works."  Scott noted a 
certain irony to using passwords to protect keys on server machines, 
where file permissions generally provide protection.  Certificate 
chains can also be specified in-band using the keyInfo element, so the 
certificate itself can be stored in creds.xml if preferred.
	This allows the target configuration to specify a key and credential 
to use based on the matrix of the identifier of the resource making the 
request and the name of the origin site the attributes are coming from. 
 The intersection gives control over the credentials used for any given 
request.  This hooks into the trust.xml file, which allows 
specification of the CA's used to validate the server certs presented.
	The net effect of this is to completely unify the trust handling in 
the target to a set of three metadata files(sites.xml, trust.xml, and 
creds.xml) and does away with the old ca_bundle.crt file and its 
dependencies.  All trust handling is now XML-based, allowing for 
complete customization of the rules for certificate and trust handling 
across all transactions.
	It remains to be done to make the origin similar, allowing 
specification of which keys and certificates the HS should use based on 
the accessed application domain.  There's also a need to start shifting 
gears to the Java target and this will need to be re-implemented there 
anyway.  Scott also mentioned a need to modify the SOAP server used to 
allow for things like client-side certificate validation in a 
customized way based on these factors.  The group agreed it would be 
nice to see parts of this architecture eventually represented in a dsig 
library.

Distributed Java Targets & Load Balancing

	There has been an ongoing discussion about the best way to make the 
Java target work across load-balanced servers given the need to 
maintain sessions which may have individual transactions farmed off to 
different servers.  The challenge is making information generated 
within the session initiation part of the Shibboleth protocol and 
therefore created within a Java VM available to potentially any 
consumer necessary.
	The use of JAAS for this has been previously suggested and was raised 
again on the call, leading to some confusion over the scope of what 
JAAS was able to do and whether it were applicable to this problem.  
There may be issues surrounding the type of information JAAS can handle 
or pass, and whether the information in a SAML assertion would have to 
be relegated to a set of role strings, which may be impossible for 
certain types of more complex attributes.
	Another approach suggested would be implementing the SHIRE/SHAR as an 
EJB, which is the ideal J2EE way of creating global, stateful 
information using what amounts to an entity.  However, there isn't an 
open-source, widely accepted EJB container out there that Shibboleth 
could be built on top of.