Operating Agreement Llc Add Member Wisconsin

							           Shibboleth:
Building Tools for Inter-institutional
        Resource Sharing
      Renee Woodten Frost
      Internet2 Middleware and Security
                         24 Jun 2004
           Topics

   Middleware Background
   What is Shibboleth?
   What is its Current Status?
   Why Shibboleth?
   Who is Using Shibboleth?
   Federations
      • InQueue
      • InCommon

 For more information




                                  24 Jun 2004
          What is Middleware?

 Specialized networked services that are shared by
  applications and users
 A set of core software components that permit scaling of
  applications and networks
 Tools that take the complexity out of application
  integration
 A second layer of the IT infrastructure, sitting above the
  network
 A land where technology meets policy
 The intersection of what networks designers and
  applications developers each do not want to do
                                                      24 Jun 2004
           Core Middleware Scope
 Identity and Identifiers – namespaces, identifier
  crosswalks, real world levels of assurance, etc.
 Authentication – campus technologies and policies,
  interrealm interoperability via PKI, Kerberos, etc.
 Directories – enterprise directory services architectures
  and tools, standard objectclasses, interrealm and registry
  services
 Authorization – permissions and access controls,
  delegation, privacy management, etc.
 Integration Activities – open management tools, use of
  virtual, federated and hierarchical organizations, enabling
  common applications with core middleware             24 Jun 2004
A Map of Campus Middleware Land




                           24 Jun 2004
            MACE (Middleware Architecture
            Committee for Education)
 Purpose - to provide advice, create experiments, foster standards, etc.
  on key technical issues for core middleware within higher education
 Membership - Bob Morgan (UW) Chair, Tom Barton (Chicago), Scott
  Cantor (Ohio State), Steven Carmody (Brown), Michael Gettes (Duke),
  Keith Hazelton (Wisconsin), Paul Hill (MIT), Jim Jokl (Virginia), Mark
  Poepping (CMU), Bruce Vincent (Stanford), David Wasley (California),
  Von Welch (Grid)
 European members - Brian Gilmore (Edinburgh), Ton Verschuren
  (Netherlands), Diego Lopez (Spain)
 Creates working groups in major areas, including directories, interrealm
  access control, PKI, video, P2P, etc.
 Works via conference calls, emails, occasional serendipitous in-person
  meetings...

                                                                  24 Jun 2004
        Internet2 Middleware and
        the NSF Middleware Initiative (NMI)
 Internet2 Middleware a major theme for the last five years, drawing
  support from 206 university members, 75+ corporate members, and
  government grants and interactions
 Internet2 has an integrator role within NMI, the key NSF Program to
  develop and deploy common middleware infrastructures
 NMI has two major themes
   • Scientific computing and data environments (ala Grids)
   • Common campus and inter-institutional middleware infrastructure (ala
     Internet2/EDUCAUSE/SURA work)
 Issues periodic NMI releases of software, services, architectures,
  objectclasses and best practices – R5 most current release


                                                                            24 Jun 2004
             The Model:
             Enterprises and Federation
Given the strong collaborations within the academic
community, there is an urgent need to create inter-realm
tools, so
 Build consistent campus and enterprise middleware
infrastructure deployments, with outward facing
objectclasses, service points, etc. and then
 Federate those enterprise deployments, using the
outward facing campus infrastructure, with inter-realm attribute
transports, trust services, etc. and then
 Leverage that federation to enable a variety of applications
from network authentication to instant messaging, from video
to web services, and then, going forward
 Create tools and templates that support the management
and collaboration of virtual organizations by building on the
federated campus infrastructures.                            24 Jun 2004
            Middleware Axioms
 Work the core areas
 Focus on support for collaboration
 Use federated administration as the lever; have the enterprise
  broker most services (authentication, authorization, resource
  discovery, etc.) in inter-realm interactions
 Develop a consistent directory infrastructure within R&E
 Provide security while not degrading privacy.
 Foster inter-realm trust fabrics: federations and virtual
  organizations
 Leverage campus expertise and build rough consensus
 Support for heterogeneity and open standards
 Influence the marketplace; develop where necessary          24 Jun 2004
          What is Shibboleth? (Biblical)
 A word which was made the criterion by which to
  distinguish the Ephraimites from the Gileadites. The
  Ephraimites, not being able to pronounce “sh”, called the
  word sibboleth. See --Judges xii.
 Hence, the criterion, test, or watchword of a party; a party
  cry or pet phrase.
                        Webster's Revised Unabridged Dictionary (1913)




                                                             24 Jun 2004
                What is Shibboleth?
 An initiative to develop an architecture and policy framework
  supporting the sharing – between domains -- of secured web
  resources and services

 A framework built on a “Federated” model

 A project delivering an open source implementation of the
  architecture and framework

 Deliverables:
    • Software for Origins (credential providers = campuses)
    • Software for Targets (service providers)
    • Operational Federations (scalable trust)

                                                               24 Jun 2004
               Shibboleth Goals
 Use federated administration as the lever; have the enterprise
  broker most services (authentication, authorization, resource
  discovery, etc.) in inter-realm interactions
 Provide security while not degrading privacy
    • Using Attribute-based Access Control
 Foster inter-realm trust fabrics: federations and virtual
  organizations
 Leverage campus expertise and build rough consensus
 Influence the marketplace; develop where necessary
 Support heterogeneity and open standards


                                                         24 Jun 2004
          Attribute-based Authorization
 Identity-based approach
   • The identity of a prospective user is passed to the controlled
     resource and is used to determine (perhaps with requests for
     additional attributes about the user) whether to permit access.
   • This approach requires the user to trust the target to protect
     privacy.
 Attribute-based approach
   • Attributes are exchanged about a prospective user until the
     controlled resource has sufficient information to make a decision.
   • This approach does not degrade privacy.




                                                                24 Jun 2004
                    Typical Attributes in the
                    Higher Ed Community
Affiliation                “active member of community” member@washington.edu



EPPN                       Identity                    gettes@duke.edu
(eduPersonPrincipalName)

Entitlement                An agreed upon opaque URI   urn:mace:vendor:contract1234



OrgUnit                    Department                  Economics Department



EnrolledCourse             Opaque course identifier    urn:mace:osu.edu:Physics201



                                                                      24 Jun 2004
          Addressing Four Scenarios
 Member of campus community accessing licensed resource
   • Anonymity required
 Member of a course accessing remotely controlled resource
   • Anonymity required
 Member of a workgroup accessing controlled resources
   • Controlled by unique identifiers (e.g. name)
 Intra-university information access
   • Controlled by a variety of identifiers


Taken individually, each situation can be solved in a variety
of straightforward ways.
 Taken together, they present the challenge of meeting users‟
reasonable expectations for protection of personal privacy.
                                                     24 Jun 2004
          So… What is Shibboleth?

 A Web Single-Signon System (SSO)?

 An Access Control Mechanism for Attributes?

 A Standard Interface and Vocabulary for Attributes?

 A Standard for Adding Authentication and Authorization
  to Applications?



                                                   24 Jun 2004
Shibboleth Architecture
(still photo, no moving parts)




                             24 Jun 2004
         Development Milestones
 Project formation - Feb 2000 Stone Soup; process began late
  summer 2000 with bi-weekly calls to develop scenarios,
  requirements and architecture.
 Linkages to SAML established Dec 2000
 Architecture and protocol completion - Aug 2001
 Design - Oct 2001
 Coding began - Nov 2001
 Alpha-1 release – April 24, 2002
 OpenSAML release – July 15, 2002
 v1.0 April 2003; v1.1 July 2003; v1.2 May 2004, v1.3 summer
 v2.0 likely end of the major evolution
                                                     24 Jun 2004
           Shibboleth Status
 Campus Adoption accelerating and working with increasing
 number of information/service providers - over 50 universities
 using it for access to OCLC, JSTOR, Elsevier, WebAssign,
 Napster, etc.
 Common status is “moving into production”
 The hard part is not installing Shibboleth but running “plumbing”
 to it: directories, attributes, authentication
 Work underway on some of the essential management tools such
 as attribute release managers, target resource management, etc.
 Needs federations to scale; being adopted by, or catalyzing,
 national R&E federations in several countries


                                                          24 Jun 2004
        Shibboleth Status

 Likely to coexist well with Liberty Alliance and may work
  within the WS framework from Microsoft.

 Growing development interest in several countries -
  providing resource manager tools, digital rights
  management, listprocs, etc.

 UK‟s JISC awards just announced for Core Middleware:
  Technology Development Programme – 8 of 15 involve Shib

 Used by several federations today – NSDL, InQueue,
  SWITCH and several more soon (UK, Australia, Finland,
  etc.)

                                                         24 Jun 2004
            Shibboleth -- Next Steps
 Full Implementation of Trust Fabric
    • Supporting multi-federation origins and targets
 Support for Dynamic Content (Library-style Implementation
  in addition to web server plugins)
 Sysadmin GUIs for managing origin and target policy
 Integration with Grids, Virtual Organizations
 Integration with Saml V2.0, Liberty Alliance, WS-Fed
 NSF grant to Shibboleth-enable open source collaboration
  tools
 LionShare - Federated P2P


                                                        24 Jun 2004
    Why Shibboleth?
    Improved Access Control

 Use of attributes allows fine-grained access control
    • Med School Faculty get access to additional resources
    • Specific group of students have access to restricted resources


 Simplifies management of access to extended
  functionality
    • Librarians, based on their role, are given a higher-than-usual
      level of access to an online database to which a college might
      subscribe
    • Librarians and publishers can enforce complicated license
      agreements that may restrict access to special collections to
      small groups of faculty researchers
                                                           24 Jun 2004
        Why Shibboleth?
        Federated Administration
 Flexibly partitions responsibility, policy, technology, and trust

 Leverages existing middleware infrastructure at origin -
  authentication, directory
    • Users registered only at their “home” or “origin” institution
    • Target does NOT need to create new userids


 Authorization information sent instead of authentication
  information
    • When possible, use groups instead of people on ACLs
    • Identity information still available for auditing and for applications that
      require it

                                                                      24 Jun 2004
        Why Shibboleth?
        Privacy

 Higher Ed has privacy obligations
   • In US, “FERPA” requires permission for release of most
     personal identification information; encourages least
     privilege in information access
   • HIPAA requires privacy in medical records handling


 General interest and concern for privacy is growing

 Shibboleth has active (vs. passive) privacy provisions
  “built in”


                                                      24 Jun 2004
           Benefits to Campuses

 Much easier Inter-Domain Integration
    • With other campuses
    • With off-campus service provider systems
 Integration with other campus systems, intra-domain
    • Learning Management Systems
    • Med School……
 Ability to manage access control at a fine-grained level
 Allows personalization, without releasing identity
 Implement Shibboleth once…
    • And then just manage attributes that are released to new targets




                                                                         24 Jun 2004
          Benefits to Targets/Service Providers
 Unified authentication mechanism from the vendor perspective
     • Much more scalable
     • Much less integration work required to bring a new customer online.
 Ability to implement fine-grained access control (e.g. access by role),
  allowing customer sites to effectively control access by attributes and
  thus control usage costs, by not granting access unnecessarily
 Once Shibboleth integration work completed on vendor‟s systems
      • Incremental cost of adding new customers is relatively minimal
      • In contrast to the current situation -- requiring custom work for
        each new customer
 Ability to offer personalization
 Enables attribute-based Service Level Model
 If universities have Shibboleth implemented already, easy
  implementation for them

                                                                         24 Jun 2004
            What are Federations?
 Associations of enterprises that come together to exchange
  information about their users and resources in order to enable
  collaborations and transactions
 Enroll and authenticate and attribute locally, act federally.
 Uses federating software (e.g. Liberty Alliance, Shibboleth, WS-*)
  common attributes (e.g. eduPerson), and a security and privacy set
  of understandings
 Enterprises (and users) retain control over what attributes are
  released to a resource; the resources retain control (though they
  may delegate) over the authorization decision.
 Several federations now in construction or deployment


                                                              24 Jun 2004
           Unified Field Theory of Trust
 Bridged, global hierarchies of identification-oriented, often
  government-based trust – laws, identity tokens, etc.
   • Passports, drivers licenses
   • Future is typically PKI oriented
 Federated enterprise-based; leverages one‟s security
  domain; often role-based
   • Enterprise does authentication and attributes
   • Federations of enterprises exchange assertions (identity & attributes)
 Peer-to-peer trust; ad hoc, small locus personal trust
   • A large part of our non-networked lives
   • New technology approaches to bring this into the electronic world.
   • Distinguishing P2P apps arch from P2P trust
 Virtual organizations cross-stitch across one of the above
                                                                 24 Jun 2004
            Federated Administration
Given the strong collaborations within the academic community,
 there is an urgent need to create inter-realm tools, so . .
 Build consistent campus middleware infrastructure
  deployments, with outward facing objectclasses, service points,
  etc. and then
 Federate (multilateral) those enterprise deployments with inter-
  realm attribute transports, trust services, etc. and then
 Leverage that federation to enable a variety of applications from
  network authentication to instant messaging, from video to web
  services, from p2p to virtual organizations, etc. while we
 Be cautious about the limits of federations and look for
  alternative fabrics where appropriate.
                                                             24 Jun 2004
       Federated Administration

              VO   VO

          O
Apps CM             O
          T             CM Apps
                    T                                  Other
 Campus 1                                              feds
                    Campus 2


   T           T        T


                            Federation   24 Jun 2004
         Shibboleth-based Federations
 InQueue
 InCommon
 Club Shib
 Swiss Education and Research Network (SWITCH)
 National Science Digital Library (NSDL)
------------------------------------
 State networks
 Medical networks
 Financial aid networks
 Life-long learning communities
                                              24 Jun 2004
                   The Research and Education
                   Federation Space

REF
Cluster
                    InQueue
                    (a starting                             Other
   Other            point)                                  clusters
   potential                             Other national
   US
                                         nets
   R+E
   feds
                            SWITCH

     InCommon                          NSD        Indiana
                                       L
                         The Shib
                         Researc
                         h Club

   State of Penn
   Fin Aid Assoc
                                     Slippery slope
                                     - Med Centers, etc
                                                                       24 Jun 2004
                       InQueue
 The “holding pond”
 Is a persistent federation with “passing-through”
  membership…
 Operational today. Can apply for membership via
  http://shibboleth.internet2.edu/ InQueue Federation
  guidelines
 Requires eduPerson attributes
 Operated by Internet2; open to almost anyone using
  Shibboleth in an R&E setting or not…
 Fees and service profile to be established shortly: cost-
  recovery basis
                                                      24 Jun 2004
               InQueue Origins
               2.12.04
                                             National Research Council of Canada
Rutgers University
                                             Columbia University
University of Wisconsin
                                             University of Virginia
New York University
                                             University of California, San Diego
Georgia State University
                                             Brown University
University of Washington
                                             University of Minnesota
University of California Shibboleth Pilot
                                             Penn State University
University at Buffalo
                                             Cal Poly Pomona
Dartmouth College
                                             London School of Economics
Michigan State University
                                             University of North Carolina at Chapel Hill
Georgetown
                                             University of Colorado at Boulder
Duke
                                             UT Arlington
The Ohio State University
                                             UTHSC-Houston
UCLA
                                             University of Michigan
Internet2
                                             University of Rochester
Carnegie Mellon University                                                  24 Jun 2004
                                             University of Southern California
          Major Targets
 Campuses that are also origins, wanting to share
  campus-based content
 Content providers – EBSCO, OCLC, JSTOR, Elsevier,
  Napster, etc
 Learning Management Systems – WebCT, Blackboard,
  WebAssign, OKI, etc
 Outsourced Service Providers – purchasing systems,
  dormitory management companies, locksmiths, etc.




                                                     24 Jun 2004
          InCommon Federation
 A permanent federation for the R&E US sector
 Federation operations – Internet2
 Federating software – Shibboleth 1.1 and above
 Federation data schema - eduPerson200210 or later and
  eduOrg200210 or later
 Became operational April 5, with several early entrants to
  help shape the policy issues.
 Precursor federation, InQueue, has been in operation for
  about six months and will feed into InCommon
 http://www.incommonfederation.org

                                                     24 Jun 2004
             InCommon Management
 Operational services by Internet2
    • Member services
    • Backroom (Certificate Authority, WAYF service, etc.)
 Governance
    • Executive Committee: Carrie Regenstein. Chair (Wisconsin), Jerry Campbell
      (USC), Lev Gonick (CWRU), Clair Goldsmith (Texas System), Mark Luker
      (EDUCAUSE), Tracy Mitrano (Cornell), Susan Perry (Mellon), Mike Teets (OCLC),
      David Yakimischak (JSTOR)
    • Two Executive Committee working groups
         – Policy: Tracy Mitrano, Chair
         – Communications, Membership, Pricing and Packaging: Susan Perry, Chair
    • Technical Advisory Group: Scott Cantor (OSU), Steven Carmody (Brown), Bob
      Morgan (Washington), Renee Shuey (PSU)
    • Project manager: Renee Frost (Internet2)
 Initially an LLC and likely to take 501(c)3 status

                                                                     24 Jun 2004
           Trust in InCommon - Initial
 Members trust the federated operations to perform its
  activities well
   • The operator (Internet2) posts its procedures, attempts to execute
     them faithfully, and makes no warranties
   • Enterprises read the procedures and decide if they want to become
     members
 Origins and targets trust each other bilaterally in out-of-
  band or no-band arrangements
   • Origins trust targets dispose of attributes properly
   • Targets trust origins to provide attributes accurately
   • Risks and liabilities managed by end enterprises, in separate ways


                                                               24 Jun 2004
           InCommon Trust - Ongoing
 Use trust  Build trust cycle


 Clearly need consensus levels of I/A
 Multiple levels of I/A for different needs
   • Two factor for high-risk
   • Distinctive requirements (campus in Bejing or France, distance ed,
     mobility)
 Standardized data definitions unclear
 Audits unclear
 International issues

                                                               24 Jun 2004
             Balancing the Operator‟s
             Trust Load
 InCommon Certificate Authority (CA)
   •   Identity proofing the enterprise
   •   Issuing the enterprise signing keys (primary and spare)
   •   Signing the metadata
   •   Could be outsourced
 InCommon Federation
   • Aggregating the metadata
   • Supporting campuses in posting their policies
   • Less easy to outsource




                                                                 24 Jun 2004
             InCommon Operations Docs
 InCommon_Federation_Disaster_Recovery_Procedures_ver_0.1
   • An outline of the procedures to be used if there is a disaster with the InCommon
     Federation.
 Internet2_InCommon_Federation_Infrastructure_Technical_Referen
  ce_ver_0.2
   • Document describing the federation infrastructure.
 Internet2_InCommon_secure_physical_storage_ver_0.2
   • List of the physical objects and logs that will be securely stored.
 Internet2_InCommon_Technical_Operations_steps_ver_0.35
   • This document lists the steps taken from the point of submitting CSR, Metadata,
     and CRL to issuing a signed cert, generation of signed metadata, and publishing
     the CRL.
 Internet2_InCommon_Technical_Operation_Hours_ver_0.12
   • Documentation of the proposed hours of operations.

                                                                           24 Jun 2004
               InCommon CA Operations Docs
 CA_Disaster_Recovery_Procedure_ver_0.14
    • An outline of the procedures to be used if there is a disaster with the CA.
 cspguide
    • Manual of the CA software planning to use.
 InCommon_CA_Audit_Log_ver_0.31
    • Proposed details for logging related to the CA.
 Internet2_InCommon_CA_Disaster_Recovery_from_root_key_compro
  mise_ver_0.2
    • An outline of the procedures to be used if there is a root key compromise with the CA.
 Internet2_InCommon_CA_PKI-Lite_CPS_ver_0.61
    • Draft of the PKI-Lite CPS.
 Internet2_InCommon_CA_PKI-Lite_CP_ver_0.21
    • Draft of the PKI-Lite CP.
 Internet2_InCommon_Certificate_Authority_for_the_InCommon_Federa
  tion_System_Technical_Reference_ver_0.41
    • Document describing the CA.


                                                                                     24 Jun 2004
              InCommon Key Signing Process
 2. Hardware descriptions
        a. Hardware will be laptop and spare laptop with no network capabilities, thumb
  drive, CDRW drive, media for necessary software
  3. Software descriptions
        a. OS, OpenSSL, CSP, Java tools for meta data
  4. Log into computer
  5. Generation of the CA Private Root key and self-signing
  6. Generation of the Metadata signing key
  7. Generate CSR for Internet2 origin
  8. Signing of new metadata sites and trusts files
  9. Backup copies of all private keys and other operational backup data are generated.
  10. Verify CD's and MD5 checksum
  11. Write down passphrase and put in envelopes and sign envelopes
  12. Securely store CA hardware and contents of local safe in safe
  13. Log that these actions occurred on the log in safe and then close and lock the safe
  14. Put thumb drive into secure db and copy data onto secure db
  15. Take private key password archive and other contents to Private Key Password
  safe deposit box and record in log that this was done.
  16. Take operational data archive to Operation Data safe deposit box and record in
  log that this was done.


                                                                           24 Jun 2004
    InCommon Operations Process Steps
 InCommon Process Technical Reviewers
   •   Scott Cantor, OSU
   •   Jim Jokl, University of Virginia
   •   RL Bob Morgan, University of Washington
   •   Jeff Schiller, MIT
 Key Signing Party
   • March 30, 2004 in Ann Arbor
   • Videotaped
   • Witnessed




                                                 24 Jun 2004
           InCommon Startup
 Membership: open to .edu-qualified sites and business
  partners
 Policy, Practices, Pricing, Packaging to be developed by
  Exec Comm working groups and phase one participants
 Privacy requirements to be developed:
    • May be = destroy received attributes immediately upon use
 Security requirements to be developed:
    • May be = enterprises post local I/A and basic business rules for
      assignment of eduPersonAffiliation values
    • Likely to progress towards standardized levels of authentication
    • Logout issues

                                                                24 Jun 2004
          Phase One Rollout
 11 organizations
 Requests to add more – 4 institutions, 2 service providers
 Feedback on process and documents
 Federation Operating Rules drafted
 Participant Agreement drafted/under review
 Participant Operational Practice Statement
  developed/being vetted by phase one participants
 Pricing and Packaging model drafted/proposals being
  discussed/vetted

                                                     24 Jun 2004
           The Potential for InCommon
 The federation as a networked trust facilitator
 Needs to scale in two fundamental ways
   • Policy underpinnings need to move to normative levels among the
     members; “post and read” is a starting place…
   • Inter-federation issues need to be engineered; we are trying to align
     structurally with emerging federal recommendations
 Needs to link with PKI and with federal and international
  activities
 If it does scale and grow, it could become a most
  significant component of cyberinfrastructure…


                                                                 24 Jun 2004
           Acknowledgements

 Design Team: David Wasley (U of C); RL „Bob‟ Morgan (Washington);
   Keith Hazelton (Wisconsin - Madison); Marlena Erdos (IBM/Tivoli);
          Steven Carmody (Brown); Scott Cantor (Ohio State)


  Important Contributions from: Ken Klingenstein (Internet2); Michael
          Gettes (Duke), Scott Fullerton (Wisconsin - Madison)


 Coding: Derek Atkins (MIT), Parviz Dousti (CMU), Scott Cantor (OSU),
                Walter Hoehn (Columbia/U of Memphis)




                                                                24 Jun 2004
     For More Information

 NSF Middleware Initiative-sponsored workshop:
“CAMP Shibboleth”
   • June 28-30 in Broomfield, Colorado
   • Features a Shib Install Fest
 Websites
 http://middleware.internet2.edu
 http://shibboleth.internet2.edu
 http:/www.incommonfederation.org


Renee Woodten Frost                 rwfrost@internet2.edu

                                                        24 Jun 2004