Shibboleth Developers

[(Nate Klingenstein)]

There are a few scenarios that were discussed at the Internet2 Member
Meeting which can significantly augment the Shibboleth trust
infrastructure.  While the new infrastructure may seem marginally more
complex, trying to handle the messy real-world issues which present the
need for the new infrastructure under the old one would likely be much
more difficult. Club Shib was originally intended as a temporary measure
until a further trust model was refined, and it seems likely to those
involved that the refined model proposed below better addresses
real-life scenarios.


Scenario 1, old style:  Georgia would like to implement a Shibbolized
library system which could be accessed by any school.  The colleges
among these schools will also want to be part of Club Shib so they can
share resources with other institutions, while the K-12 community will
only want to access Georgia's state libraries.  Additionally, several
districts would like to license a particular web resource for their
use.  To address this, Georgia would have to implement one club for
schools and content providers, universities would join Club Shib, and
the content provider and those particular districts would have to form
another one.  This would lead to interesting challenges surrounding the
creation of an appropriate WAYF service; for example, a Georgia State
student trying to access one of those libraries would have to choose
intelligently which WAYF to go to or which club to be represented as a
member of.  This will currently entail an entirely separate SHIRE and HS
for each site for each club agreement.

Scenario 2, old style:  All the hospitals in the greater Washington D.C.
area agree to share patient records amongst themselves using Shibboleth,
with significant privacy restrictions.  However, under emergency
circumstances, a patient arrives at one hospital with no medical record,
while the hospital needs to check for current medications.  To
facilitate this sort of emergency and bypass the typical paperwork
necessary, each hospital must implement a separate club and SHIRE/HS
able to handle this additional attribute release need.

Scenario 3, old style:  Higher education has uniformly implemented Club
Shib, and all institutions are members.  However, the Big 10 would like
to define some additional requirements for attributes and license some
additional information to Big 10 schools only.  These schools would have
to implement a separate Club Big 10, and students would have to be able
to call out which club they are authenticating under.

Scenario 4, old style:  Club Shib is up and running, and Club Boeing has
been created so that Boeing can share attributes with its suppliers.
Several of these suppliers are also Internet2 members, and are working
with a handful of Internet2 schools to develop new aeronautical
components.  To communicate securely, a new club needs to be defined
between these schools and the specific vendors.

Michael realized during the Shibboleth discussion at the Internet2
Member Meeting that what is necessary is a way to specify a context
within which a query is issued.  This would allow the query from the
SHAR to be issued under one particular trust agreement, reducing the
need for users to be able to do the qualification of a request as the
components themselves grow more intelligent.  Proliferation of
additional components and implementations would be limited, as well,
creating interoperability between very different sub-clubs with a
significantly reduced level of assurance.

The general trust architecture agreed upon between Michael, Scott, Jim
and myself last night would look like this.  Club Shib would cover many
different implementations of Shibboleth in many genres.  Many of the
restrictions that are part of Club Shib itself would be taken out, and
more emphasis would instead be placed on maintenance of the PKI
components.  Club Shib would also broadly call out the format that
attributes should have, but would not specify which attributes should be
carried.

In addition, Club Shib would now support smaller semi-lateral agreements
inside the broader Club.  This would allow, for example, all academia to
define one academic sub-club, and share the eduPerson attributes with a
potentially more restricted account management specifications, and
accepting only members without plaintext passwords.  Additionally, a
sub-sub-club could be created as a semi-lateral set of these members,
potentially including members not part of the smaller academic
sub-club.  This could include only schools which have very strong
security in place, including PKI, allowing them to qualify certain
high-risk Shibboleth assertions with a much stronger security level.
Between two schools who are both members of Club Shib, attributes could
be transferred under a particular political contract sometimes and other
the original contract at other times.

An implementation can come in the form of adding a value, preliminarily
titled "context", to the attribute query, which would be analogous to
the audience field in the response.  There is currently no appropriate
value in the attribute query in the SAML schema, but this schema is
extensible enough to support the addition of the context value.

This is a slightly more hierarchial approach, which proved challenging
in efforts to widely implement PKI systems.  However, there are still
more aspects of a more lateral trust infrastructure, as it is feasible
to have multiple requests based on multiple agreements in a single
conversation by defining different contexts.  Defining attribute sets to
be shared and providing the means to correctly choose the contract to
issue a request under will be additional problems.  This is how the
original scenarios would be implemented under the new trust
architecture:

Scenario 1, new style:  All universities, content providers, and K-12
institutions are members of Club Shib.  There is a semi-lateral
agreement in place between content providers, K-12 and the universities
which can be specified in the new field which specifies that no identity
will be sent, but other particular attributes may be sent with a given
set of privacy standards after the receipt of information.  A
sub-sub-club can be created between those specific schools and content
providers which agree to share resources which can be a composite of the
requirements of both the original club, the semi-lateral agreement, and
a set of new attributes to be shared.

Scenario 2, new style:  A hospital can specify in its request that this
is an urgent situation which necessitates the immediate release of the
medical information of a specific patient.  Under the specific
conditions defined between all D.C. area hospitals which are also a part
of Club Shib, this qualification is only placed in the request with
certain emergencies and patient data is always properly treated in those
situations.

Scenario 3, new style:  Big 10 schools can create a semi-lateral
agreement inside the main Club Shib which allows them to specify that
they are part of the special Big 10 licensing agreement.  In any request
for an attribute protected in such a way that it is Big 10-only, the
SHAR can specify that it needs a particular set of attributes under a
particular contractual agreement.

Scenario 4, new style:  All component providers, Boeing, and academic
members would be part of Club Shib, which would have only the bare
minimum requirements for joining.  Individual providers and schools can
then call out a semi-lateral agreement for the specific sharing of
information between them, while other more challenging things such as
the registry are already provided.


This also facilitates something that is not currently possible under the
Shibboleth architecture; the pulling of specific attributes, and
specifying precisesly which attributes a target needs to know, utilizing
the typical 'tell me everything I'm allowed to know' request with
specific qualifications that both the target and origin understand the
meaning of.  This is powerful, especially for user-interface reasons;
intelligent components could eventually be created which are able to
tell the AA which agreement is being used and specify which attributes
are necessary.  However, the MyAA interface may be made significantly
more complicated.

Thoughts?  Ideas?

Nate.


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

    http://archives.internet2.edu/

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