Shibboleth Developers

*MACE-Shibboleth Design Conference Call*
November 26, 2001

*Participants*

Steven Carmody -- Brown(chair)
Scott Cantor -- OSU
Tom Dopirak -- CMU
Barbara Jensen -- CMU
Sridhar Muppidi -- IBM/Tivoli
Bob Morgan -- Washington
Ellen Vaughan -- Internet2
Russell Yount -- CMU
Nate Klingenstein -- Internet2(scribe)

*Discussion*

Updates

        The origin site diagram has been completed by CMU, which seemed
generally reasonable to everyone on the call.  Early integration testing
should be possible soon on machines provided by CMU, which can later move
onto the Internet2 machines once they are provided and the group has a
better idea of how to organize its workspace.
        Scott has been working on the API drafts, and the new version of
the Arch Doc has been out for awhile.  He has also sent out a few feelers
about the interaction between the ISO and the handle service, and believes
that the group should design the demo handle service such that it fits with
as many different ISO's as possible without much work.  Scott will describe
what he thinks he can do with the internals of the API once he's happy with
it.  The API isn't very clean yet because it isn't clear how everything
should be layered yet.  XML binds semantic steps with syntactic steps, so
it's difficult to separate information from the format it's in at any given
time.  There isn't much that needs to be done to support further
development of these API's; the difficulty isn't the real code so much as
figuring out the interfaces and where the translation pieces are between
the wire and the components themselves.
        Sridhar has already developed some of the SHIRE functionality,
which is split into the Apache module and a servlet which sits in the
Tomcat environment.  This division was necessary because some of the
validation and runtime libraries will be in Java.  His thinking now is to
proceed with this approach and to eventually have a specific C++
implementation or even run command line from the module itself.  Not much
progress has been made on the SHAR, mostly because he doesn't believe that
there is much difficulty in the SHAR other than the caching of attributes.
        Steven expressed his belief that it was time to start working on a
Club Shibb document to supplement the arch-doc and other things under
development.  There also needs to be a more concerted effort to make
progress on other companion documents such as the implementor's guide and
some FAQ's.

SHIRE/API Interfacing

        The SHIRE currently asks the user to type in the institution before
performing a simple lookup for the binding to the handle server.  When
Scott initially designed his API, much of the state of the SHIRE runtime
component was part of the configuration information, such as mapping handle
services to origin sites, potentially including issues of key management.
He has tried to minimize as much as possible the state that the API's would
need in terms of config info because he isn't certain how standardized the
Java properties stuff is, as there are possibly many different ways to
configure this.  He pulled out some of the validation steps that the SHIRE
would do, which really just involved checking data against the preconfig
info, and left his part to only the raw validation of the syntax and SAML.
For these more static validations, Sridhar assumes he'll just make a
certificate store or a Java keyring.  There was some question about whether
a preconfigured default keyring or a keyring expressely for the SHIRE
should be used, but this isn't too important because the interface to key
management in Java is abstract enough that which keystore and type can be
easily configured.
        The API is also not responsible for creation of the package; it
only creates the assertion itself.  The rest of the form and the other
imbedded parameters have to be filled by the handle server.  He can create
a hardcoded XML document that represents an assertion for testing purposes
currently, and instead of throwing an error, Sridhar's code can just choose
to accept it, and later on, when signing is supported, this code
placeholder can be replaced with actual verification.

SHAR/RM Communication

        There was an extended thread on the Shibboleth Design list about
how Shibboleth would interact with the resource manager.  There was the
suggestion voiced on the call that a proxy-based architecture be designed
for this which would intercept communications between the client and the RM
and perform the Shibboleth functions at that point.  There needs to be more
discussion of how Shibboleth will pass attributes downstream for processing
by the resource manager.  The possibility was even suggested that
Shibboleth be able to make the decisions itself at the interception point
rather than passing attributes on as an alternate form of the architecture.
The group tried to balance the ability to accept attributes intelligently
and handle attribute scoping with giving the resource manager enough
control to make access decisions itself.
        It was believed useful to have the attribute info available in the
generic form for the applications downstream.  This would mean that
Shibboleth would provide a first-order filtering from the SAML assertion,
then pass the attributes downstream in a new format.  XML was suggested,
but the assumption that every relying application would have an XML
processer is extreme.  Supplying the ability for applications which are
savvy enough to take advantage of this seems like a good capability but a
bad necessity.
        This means that there's a desire to be able to flatten the XML
structure to plain attributes for other applications after Shibboleth
processes and validates the other parts of the SAML packaging.  The sort of
code or standards to be able to flatten an XML structure into some other
syntax might exist, but nobody in the group was certain whether it did or
not.  [AI] Steven offered to talk to a few people at Brown to see whether
there were any efforts of any quality underway to flatten this sort of
structure.  Whether the solution would be clean to implement or deploy is
still debatable.
        The attribute representation itself -- that is, the actual
characters that would need to be typed into an htaccess file to produce the
right limitations on access -- is still unclear.  Nobody on the call had
seen the use of htaccess beyond the processing of simple usernames or
groups.  Bob had a faint recollection that there was the ability to place
boolean expressions in an htaccess file which are very modest and/or
expressions.  These are little used and little documented, but [AI] he
offered to try to dig up what he could to find information on the
construction of boolean expressions in htaccess files.

*Action Items*

1.  Steven will talk to people at Brown to try to determine whether any
standards efforts were underway to flatten XML structures into more common
formats.

2.  Bob will find information on the construction of boolean expressions in
htaccess files.
--

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

   http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--