shibboleth-dev - Minutes - Design Conference Call - Nov 5, 2001
Subject: Shibboleth Developers
List archive
- From:
- To:
- Subject: Minutes - Design Conference Call - Nov 5, 2001
- Date: Mon, 10 Dec 2001 09:59:02 -0500
*MACE-Shibboleth Design Conference Call*
November 5, 2001
*Participants*
Steven Carmody -- Brown(chair)
Scott Cantor -- OSU
Tom Dopirak -- CMU
Bob Morgan -- Washington
Russell Yount -- CMU
Nate Klingenstein -- Internet2(scribe)
*Discussion*
Step One
The group agreed it would likely be the best course towards
implementation to initially build a relatively hollow structure which would
be able to interoperate with the other pieces in the infrastructure before
proceeding to flesh out the back end of each body. This would allow the
group to finish much of the work which would require a good deal of
co-ordination between the individual coders before the holiday breaks,
allowing work to go on. This would also reveal some of the potentially
more difficult parts of the implementation early on before too much of the
back-end had been solidified.
Scott offered that he could likely quickly get done much of the
basics of the API's and get most of the pieces up except for signing, which
would be addressed subsequently. Steven would work on getting the
necessary machine resources from Internet2 with the proper setup. There
will also be a need to set up a CVS of some sort, which could be done
possibly using sourceforge software; Bob advised it would not be wise to
put this up on Sourceforge itself, both because there's already a
Shibboleth project and because anything there becomes instantly open
source. The goal at CMU is to have a fixed-handle and fixed-attribute
front-end for a system operational within three or four weeks. Sridhar
said that he could likely do a fixed handle package such that when he
requests attributes, the same attributes would always be returned(though
the handle would still need to always be passed) in the similar time frame.
Scott mentioned that completion of the API within this time-frame would be
helpful for guiding the development of the other pieces.
Running a testground at IBM would be fairly difficult due to
corporate firewall; there's also an OS discrepency that CMU generally runs
Solaris and IBM runs Linux. Because of this, it makes sense to ask
Internet2 or another party to run a testing service. Tom offered a Linux
box for Sridhar for his use, and they could likely provide the space for a
CVS repository or an FTP dropoff spot if it would help make things move
forward, whether the group uses dated tarballs or something a bit more
sophisticated. Scott mentioned he'd be looking at JDK 1.3.1 as a baseline
Java compiler. The signature libraries on top of this may be slightly more
contentious. JSAML is not out yet, and the licensing policies might not be
too attractive either. Scott offered to delve into this further and select
a few possible libraries.
PDP's
The question of which point the actual decision to allow or deny
access should be made at is an interesting one. The group pondered what
should be sent on to the application, because it seemed to the group like
something the application might want to be able to decide and something
that should be decided by the party. At the same time, passing down the
attributes directly to the application assumes a fairly intelligent
application which is able to perform the decision itself. It would also
have to push the origin site's name as well as pushing the attributes to
make the decision.
This makes the SHAR's role a little less clean in the chain of
processing. It's an unreasonable proposition to expect every application
to be able to handle attributes or learn how to parse a SAML assertion;
after all, the group reasoned, this sort of decision is what a security
infrastructure is for. This indicates that it's best to allow the resource
manager to decide what to do with attributes, considered to be out of scope
of the Shibboleth architecture itself which is responsible only for trusted
transport. This would separate the validation of the attribute assertion,
which is the validation of the signature and other security mechanisms by
the SHAR, with the validation of the attributes and permissions issued by
the resource manager.
--
------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at
http://archives.internet2.edu/
------------------------------------------------------mace-shib-design--
- Minutes - Design Conference Call - Nov 5, 2001, Steven_Carmody, 12/10/2001
Archive powered by MHonArc 2.6.16.