Shibboleth Developers

[(Nate Klingenstein)]

    This document represents my best effort to fold in the helpful comments
provided through email and conference calls into a comprehensive new
version of the Club Shib Guidelines.  I anticipate much more feedback and
discussion which will, hopefully, improve the document further.  Thanks to
everyone who has given their insights so far.

See many of you at CAMP,
Nate.



Club Shib Guidelines

draft-internet2-mace-shibboleth-club-shib-guidelines-01.txt
Nate Klingenstein
30 January, 2002
Comments should be directed to 
.


1.     Clubs

1.1    Shibboleth Clubs in General

    A Shibboleth club is a crucial part of the underlying trust required for
function of the Shibboleth architecture.  A club is a group of
organizations(universities, corporations, content providers, etc.) who agree 
to
exchange attributes using the SAML/Shibboleth protocols.  In so doing, they 
must
implicitly or explicitly agree to a common set of guidelines.

The common functions a club must provide to be operational for its community
include:

    a.  A registry to process applications and distribute club membership
        information, including the PKI components necessary for trust.
    b.  Provision of a general means to acquire information on local
        authentication and authorization practices for individual members of 
the
        club.
    c.  A set of agreements or best practices agreed upon within the group on
        policies and business rules governing the exchange, use, and 
population
        of attributes before and after transit.
    d.  Completion of and decisions on open-ended architectural options,
        including attribute semantics and definition and other
        implementation-specific choices to ensure interoperability within the
        club.
    e.  Definition of how the WAYF service will be provided within the club.
    f.  A means of establishing trust and a mechanism to communicate this 
trust
        both in and out of band.

1.2    Club Shib

    Club Shib is a particular club operated by UCAID intended to be a
co-operative environment for higher education and its information providers'
use.  Members can be registered with Club Shib as origins(IdSP's) or
targets(content providers, student loan services, etc.), but may be registered
as both(institutions, museums, etc.).

Club Shib will provide the following functions to its members:

    a.  Club Shib will arrange for UCAID to operate the club's registry.
    b.  eduOrg pointers will be maintained to campus account management
        practices.
    c.  Targets will be required to not cache attributes excessively, not
        accumulate data about any particular individual, should not accept
        attributes from attribute authorities not associated with the scope of
        the attributes within(e.g. one institution asserting faculty member
        from another), and not pass on individuals' attributes unnecessarily.
        Origins must provide a reasonable degree of accuracy in exchanged
        attributes.
    d.  Decisions about some open-ended implementation options have been made 
to
        ensure compatibility between Club Shib sites.  To further ensure
        interoperability, Club Shib has defined a list of several attributes 
all
        organizations must support.
    e.  A WAYF will be provided by Club Shib's Wayfarer service.  This 
utilizes
        a membership list which will include certificates of SHIRE's and HS's
        within the club and will be distributed as a flat file.
    f.  Trust is provided in Club Shib utilizing a set of trusted roots and
        trusted services.

2.     Club Shib Application Process

2.1    Initial Application

    An application to join Club Shib should be sent to Renee Frost of 
Internet2
at 
.
  An authorized party for this submission for
universities is the certified EDUCAUSE representative; other organizations
should contact Renee directly.

2.1.1  All applicant organizations will agree to:

    a.  Use an implementation of Shibboleth that:
            i.   Complies with everything in the Shibboleth Architecture v4
            ii.  Complies with the Club Shib Member Obligations
            iii. Uses SSL for interrealm interactions between Shibboleth
                 components, including the user.
    b.  Provide certificates that comply with Club Shib PKI certificate 
profile
        detailed in the appendix.
    c.  Provide technical and administrative contacts.
    d.  Agree to follow all obligations based on membership type once
accepted to
        Club Shib.

2.1.2  An applicant origin will agree to:

    a.  Account Management Practices

            i.   State and make available account management information to 
Club
                 Shib and its members.
            ii.  Identify I&A procedures for campus accounts.
            iii. Identify authentication procedures for account use.
            iv.  Identify policy for EPPN assignment and re-assignment.
            v.   Identify policy on LCM of user objects and attributes.

    b.  Directory and Attribute Practices

            i.   Define local policy for populating the eduPersonAffiliation
                 attribute with standard vocabulary.
            ii.  Implement all attributes required by Club Shib.
            iii. State that all assertions issued will be populated as
accurately
                 as would be done if the assertion were intended for an
                 intra-realm application.
            iv.  Ensure that the scope of all attributes issued by the AA
matches
                 one of the domains for which Club Shib recognizes the AA as
                 authoritative for.

    c.  Provided Information

            i.   Supply the DNS and certificate of the HS.
            ii.  Supply the list of domains for which the AA should be
considered
                 authoritative.

2.1.3  An applicant target will agree to:

    a.  Provide URL trees associated with resources and appropriate
corresponding
        names for user interfaces if necessary.

3.     Club Shib Functions and Obligations

    Once an organization has been admitted to Club Shib, there is a number of
things which must also be done to ensure the continued smooth functioning of 
the
club.  These mostly include maintenance of the information submitted when the
organization first applies and implementation of new members.

3.1    Club Shib Obligations

3.1.1  Organizations Already in Club Shib:

    a.  Must update any changes to the DNS information and server certificates
        provided for initial registration to the Club Shib registry.
    b.  Must accept and implement reasonably quickly new distributed flat 
files
        of keys and names.
    c.  Must support and implement XML signatures, but use is optional.
    d.  Should perform all redirections through HTTP, not HTML.
    e.  Must reference URI xxxxx in the audience field of all assertions.
    f.  Should use common namespaces and attributes as defined and implemented
        by Club Shib.

3.1.2  Origins Already in Club Shib:

    a.  Should provide a means for users to regulate attribute release.
    b.  Should be listed in the WAYF service.
    c.  Should provide a reasonable response time on attribute request and
        lookup.
    d.  Must use opaque handles to protect anonymity.
    e.  Should set a basic default ARP to release whether a user is a member 
of
        the community to all Club Shib member targets.
    f.  Must meaningfully populate the authenticationMethod field in 
assertions.
    g.  Must continue to provide a reasonable degree of accuracy for 
attributes.

3.1.3  Targets Already in Club Shib:

    a.  Must support a WAYF functionality.
    b.  Should not accept attributes from domains not associated with the
        security domain of the associated attributes
    c.  Must not send on, use, or cache attributes inappropriately.

3.1.4  Club Shib Administration:

    a.  Will receive and process applications for membership and withdrawal.
    b.  Will maintain the registry of keys and domain names and regularly
        distribute this file to Club Shib members.
    c.  Will ensure uniqueness of key identifiers among community members.
    d.  Will house PKI components of Club Shib.
    e.  Will operate Wayfarer, which will list HS's for SHIRE's.
    f.  Will respond to notifications of member non-adherance to rules.

4.     Trust in Club Shib

    Trust in Club Shib is provided using a signed package of data that
associates
names, organizations, and public keys in a searchable way.  These data are
signed and distributed by Club Shib in a format that is easily useful for
SHIRE's and SHAR's.  The SHIRE, SHAR, and AA must be configured with a set of
trusted CA certificates to use in validating the certificates exchanged in SSL
or signed XML messages.  Trust in the origin side of the Shibboleth 
architecture
flows from the SHIRE's trust and familiarity with the HS, and the HS is
responsible for pointing only to appropriate attribute authorities for
appropriate handles.  Trust of the target side flows from the SHAR
authenticating itself to the HS with a certificate signed by a trusted 
authority
indicating the SHAR's name.  The HS can then correspond this name with one 
that
is a known member of Club Shib.  AA's can use a distributed list to 
preconfigure
mappings between SHAR names and target URL trees to allow users a simple means
to evaluate and change ARP's.  SHAR's should only accept attributes for which
the AA is recognized authoritative for by Club Shib.

Appendix A - "Club Shib's" Implementation of Trust Between Various Entities
- Naming, and Verifying Identities

Appendix B - Shibboleth Glossary

Appendix C - Club Shib Certificate Profile

Appendix D - Club Shib Attribute Recommendations


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

    http://archives.internet2.edu/

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