Shibboleth Developers

*MACE-Shibboleth Design Conference Call*
October 23, 2001

*Participants*

Steven Carmody -- Brown (chair)
Scott Cantor -- OSU
Tom Dopirak -- CMU
Renee Frost -- Michigan/Internet2
Barbara Jensen -- CMU
Sridhar Muppidi -- IBM/Tivoli
Russell Yount -- CMU
Nate Klingenstein -- Internet2(scribe)

*Discussion*

SAML Compliance and Interoperability

        The design group started to discuss what SAML compliance might mean
from an implementational viewpoint; much of these previous discussions on
the main Shibboleth group dealt with the more theoretical and marketing
aspects of this alignment.  The practical concern is to succeed in getting
v0.9 out on time by avoiding biting off more than is essentially needed for
success by trying to implement SAML features well which are not used in a
Shibboleth design.
        Scott's consistent strategy in his work has been to make Shibboleth
work with as little customization of SAML components as possible, while
making sure he only uses the parts of SAML that will likely be mandatory to
implement.  This both limits extraneous pieces of Shibboleth and ensures
that Shibboleth is as compatible as possible with other SAML-based systems
because it wouldn't rely on some of the less commonly supported aspects of
the protocol.  Steven said that, the more he looks at SAML, the more he
comes to believe that "it's going to need a significant amount of
'road-testing' before inter-vendor interoperability is going to work."
        It would be difficult to avoid making Shibboleth somewhat more than
SAML compliances, however, since there are entire architectural components
such as the WAYF which don't exist in the SAML architectures.  Scott
finally said he thought that the best course would be to add in tentative
changes that the Shibboleth group has continuously provided to SAML with
the expectation they may be approved, but if they are not approved, then
Shibboleth can simply say that the protocol is SAML-based+.  He will also
be watchful of any instances where SAML begins to bleed out of the runtime
piece and would cause more severe alignment problems if these weren't
initially addressed.

Attributes

        The idea emerged on the call of creating a dynamic attribute store
for Shibboleth which would consist of two different functions for each
attribute the AA could generate.  It was initially observed that attributes
for Shibboleth are just logical constructs, and their persistent location
is relatively unimportant for an architecture.  Scott expressed a desire to
keep the AA modular so that any code could be placed between the AA and the
attribute store.
        The first function would be responsible for returning an attribute
to the AA.  This could be as complex or simple as a user might want; for
one attribute, it might be a simple LDAP call, but it could also support
the application of dense boolean requirements which could call on multiple
databases, returning a value.  This would be able to support David
Holdsworth's model of deciding eligibility at the origin site by creating a
logical construct to generate a contract1234=yes value.  The other function
would be able to generate an arbitrary snippet of XML from the attribute
returned by this first function.  The attributes would then be packaged
into the SAML-based attribute assertion and passed to the target site.
This would mean that a decent API would have to be constructed for the back
end and front end of the AA; both when attributes need to be looked up, and
when attributes need to be sent.
        Russell made a suggestion to simplify the coding of the AA and
optimize the attribute generation process by storing the attributes as XML
to begin with.  Scott disagreed, citing that much of the delay that could
be expected would be from querying databases anyway and that the additional
load on the server would be relatively negligible.  He also thought it was
important to generally keep the architecture as customizable as possible so
complaints about lacking or differently-implemented functionality can be
easily answered and Shibboleth can be adopted more easily.  Attributes in
directories are also not always automatically updated, and storing
attributes such as contract1234=yes in a directory would make dynamically
updating these for fixing access denials or incorrectly entered attributes
difficult due to the slow propagation.  There could also be the desire to
make attribute generation based on time, e.g. regulating the hours someone
might be able to access the library.  With a dizzying array of possible
directories, attributes, and philosophies, all these abilities could be
important.
        User interface questions were raised at this point; if there are
attributes that are generated complexly, does the user interface need to be
able to provide users with knowledge of how these attributes are generated
and the ability to block their transfer?  The transitivity of using
attributes which users don't want released explicitly and may or may not
mind having used to generate attributes dynamically is a challenging
puzzle.

Miscellany

        Scott wanted to be able to have some good idea of what the
implementation would look like in v1.0 so that it would be mostly an
extension of the v0.9 code.  Building the ability to perform an SSL
transform at the SHAR would be useful, and would enable some of the context
based on SSL server certs help to scope attributes, in addition to the
encoded context inside value.  In Russell's experience, the end of coding
where parts are tuned to talk to each other well, co-exist with other
technologies such as NAT's, firewalls, and other devices, and other
implementational problems arise always takes longer than people expect.
Working on this part of the project in parallel with others could limit the
overall time taken, but it is difficult to address this with incomplete
code.
--

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

   http://archives.internet2.edu/

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