Shibboleth Developers

[Nate Klingenstein <>]

*Shib Design Conference Call*
November 24, 2003

*Participants*

Steven Carmody -- Brown(chair)
Derek Atkins -- MIT
Scott Cantor -- OSU
Howard Gilbert -- Yale
Keith Hazelton -- Wisconsin
Bob Morgan -- Washington
Von Welch -- NCSA
Nate Klingenstein -- Internet2(scribe)

*Discussion*

Target Configuration

	Derek has extensively modified the configuration of the target, moving  
virtually all information out of the Apache configuration and into the  
shibboleth.ini file.  The only information that must remain in the  
Apache configuration is a pointer to a shibboleth.ini, which may be  
defined on a directory-by-directory basis.
	These configurations may now vary based on the virtual host that is  
handling the request by looking up the SHIRE URL, the WAYF URL, and  
other information based on the hostname it's running under.  This could  
be extended to vary based on the accessed URL, but Derek was concerned  
that this doesn't work well with the SHIRE post mechanism; it was  
unclear to him whether the information in the post itself would need to  
be examined to determine whether it matches the target URL.  There's a  
layer in the code that is a placeholder for an eventual class to map  
URL's to application domains.
	Scott wants to move the target configuration towards the next  
generation of the application domain by sectioning configuration into  
application config sections, where most of the configuration is driven  
not only off the application the URL maps to -- which is partly the  
virtual host -- but also the relying party.  This would allow for  
different configuration policies based on which origin site a user is  
coming from.  The processing for incoming requests would be analogous  
to the way the origin works, Scott reasoned, except that the first  
discriminator is the application, whereas for the origin, the target is  
the first consideration in determining attribute release.
	Work on an XML-based target configuration file to replace the flat  
text shibboleth.ini has been underway, and Scott now has a working  
implementation to get some ideas down in code.  The underlying design  
of the credential resolver in particular is difficult because the way  
Shibboleth and SAML have always been designed to work is to allow the  
origin to send a user to a target without any prior communication,  
useful in a number of scenarios.
	The file is expected to be relatively simple for most sites, with the  
configuration more likely to be modified at the top referenced by  
provider ID.  For flat targets with one application domain, there could  
be a single provider ID presented to any number of federations if this  
is in keeping with the trust model.

Non-Browser Use Cases

	SAML only has established bindings using the artifact and the POST  
mechanism of the HTTP protocol, and the working group, as far as Steven  
can tell, "is only concerned with browser-based situations."  The  
Shibboleth project has received a number of interesting scenarios and  
requests from other applications and working groups to utilize  
Shibboleth's attribute transport abilities outside of the browser  
model, such as video authn/z.
	Steven has developed a draft profile for discussion's sake at  
http://stc.cis.brown.edu/~stc/Projects/Shibboleth/Version-2/Profile- 
Non-Browser/draft-carmody-non-browser-profile-00.html.  It seemed to  
Von that this document was focused on "getting a SAML authentication  
assertion and running with it."  There are also very deep policy  
aspects that need to be explored; the application domain, federations,  
and attribute release policies will need to be revisited in a  
non-browser light.
	Von was also curious about how Shibboleth exposes the attribute  
authority, and whether, given an identity assertion, there can be  
direct communication with the attribute authority.  This can indeed be  
done with the current implementation, but there's a lot of security  
exposer, potential compromises, and information leakage that would  
occur in practice.  Regarding the need to scope Shibboleth's role in  
that sort of exchange, Scott pointed out that "you can have an AA that  
will send all the attributes regarding a Kerberos principal, but then  
it's just an LDAP directory."

Non-Browser Authentication

	Something to consider in developing these use cases is whether  
Shibboleth will allow the authentication to happen at any time in the  
flows or whether it will have to happen prior.  Derek expressed  
concerns about multi-step authentication because, especially in HTTP,  
it's very difficult to thread together multiple exchanges into a  
coherent and secure authentication process.
	A framework that Bob thought might be useful for the authentication  
process on the front end of these applications is SASL.  An immediate,  
unanswered question was whether the target would inadvertently process  
SASL as another XML element because there is no XML expression of some  
SASL components.  Derek also asked whether SASL utilizes its own  
framing or TCP, which it doesn't, but it specifies that how its  
information should be carried.  Bob explained that "SASL is not a  
protocol; it's a framework woven into your app protocol."
	SAML's working group has discussed the concept of credential  
collection in various ways, but it seems to Scott that if there's an  
authority that is protected by Kerberos which then sends back an  
assertion, "you've essentially just done a credential conversion."   
This implies that there really is no need to define a credential  
collection protocol because there are other means to translate forms of  
authentication.  In the above case, this would imply an authority that  
could unwrap some assertion and hand the service ticket off to existing  
code that handles them.