Shibboleth: Building Tools for Inter-institutional Resource Sharing InCommon: A Shibboleth-based Research and Education Federation

1
Shibboleth Building Tools for
Inter-institutional Resource Sharing InCommon
A Shibboleth-based Research and Education
Federation

• Renee Woodten Frost
• Internet2 Middleware and Security
• 5 Feb 2005

2
Topics

• A Bit O Background - Internet2, Middleware, NMI
• What is Shibboleth? What is its Current Status?
• Why Shibboleth? Who is Using Shibboleth?
• What are Federations?
• InCommon
• Work with Other Federations
• International RE Federations
• Federal e-Authentication work
• Commercial WS-Fed
• For more information

3
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

4
A Map of Campus Middleware Land
5
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

6
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), Lynn McRae
  (Stanford), David Wasley (retired 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...

7
Internet2 Middleware and the NSF Middleware
Initiative (NMI)

• Internet2 Middleware a major theme for the last
  five years, drawing support from 200 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
  (Grids)
• Common campus and inter-institutional middleware
  infrastructure (Internet2/EDUCAUSE/SURA work)
• Issues periodic NMI releases of software,
  services, architectures, objectclasses and best
  practices
• R6 in Dec 04 most current release

8
The ModelEnterprises 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
  this 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.

9
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)

10
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 Credential Providers (campuses)
• Software for Resource Providers (content,
  services, etc)
• Operational Federations (scalable trust)

11
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

12
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.

13
Typical Attributes in the Higher Ed Community
Affiliation active member of community member_at_washington.edu
EPPN (eduPersonPrincipalName) Identity gettes_at_duke.edu
Entitlement An agreed upon opaque URI urnmacevendorcontract1234
OrgUnit Department Economics Department
EnrolledCourse Opaque course identifier urnmaceosu.eduPhysics201

14
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.

15
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?

16
Shibboleth Architecture (still photo, no moving
parts)
17
Shib Update

• Project formation - Feb 2000
• Inception of SAML effort in OASIS December 2000
• OpenSAML release July 2002
• Shib v1.0 April 2003
• Shib v1.1 July 2003
• Shib v1.2 April 2004 Shib v1.2.1 November 2004
• Shib v1.3 1Q05 non web services, e-Auth
  certified
• Shib v1.4 WS-Fed compliant
• OpenSAML 2.0 relatively soon
• Shib 2.0 3Q05?

18
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, resource management, etc.
• Needs federations to scale being adopted by, or
  catalyzing, national RE federations in several
  countries

19
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, listprocs,
  etc.
• UKs JISC 2004 awards 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.)

20
Shibboleth Some Next Steps

• Full Implementation of Trust Fabric
• Supporting multi-federation credential and
  resource providers
• Support for Dynamic Content
• SysAdmin GUIs for managing credential and
  resource policy
• Integration with SAML V2.0, Liberty Alliance,
  WS-Fed
• NSF grant to Integrate Shib with Grids
• NSF grant to Shibboleth-enable open source
  collaboration tools

21
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

22
Why Shibboleth?Federated Administration

• Flexibly partitions responsibility, policy,
  technology, and trust
• Leverages existing middleware infrastructure at
  home organization/credential provider -
  authentication, directory
• Users registered only at their home or origin
  institution
• Resource Provider does NOT need to create new
  userids
• Authorization information sent instead of
  authentication information
• When possible, use groups instead of people on
  Access Control Lists
• Identity information still available for auditing
  and for applications that require it

23
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
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
• Individual dept/school-specific needs
• 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 resource providers

25
Benefits to Resource 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
  vendors 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

26
What are Federations?

• Associations of enterprises that come together to
  exchange information about their users and
  resources to enable collaborations and
  transactions
• Enroll and authenticate and attribute locally,
  act federally.
• Uses federating software (e.g. Shibboleth),
  common attributes (e.g. eduPerson), and a set of
  security and privacy understandings
• Enterprises/users retain control over attributes
  released to resource Resources retain control
  (may delegate) over authorization decisions

27
Business drivers for federations

• Research and education
• Access to and sharing of digital content
• The visiting scientist and eduRoam
• Inter-institutional courseware
• Grids and collaborative tools

28
Requirements for federations

• Federation operations
• Federating software
• Exchange assertions
• Link and unlink identities
• Federation data schema
• Federation privacy and security requirements
• Federations should be positioned to support both
  web services and direct applications

29
Policy Basics for Federations

• Enterprises that participate need to establish a
  trusted relationship with the operator of the
  federation in small or bilateral federations,
  often one of the participants operates the
  federation
• Participants need to establish trust with each
  other on a per use or per application basis,
  balancing risk with the level of trust
• Participants need to agree on the syntax and
  semantics of shared attributes
• Privacy issues must be addressed at several
  layers
• All this needs to be done on a scalable basis, as
  the number of participants grow and the number of
  federations grow

30
Federal Guidelines of Relevance

• NIST Guideline on Risk Assessment Methodologies
• NIST Guideline on Authentication Technologies and
  their strengths
• Federal e-Authentication Efforts

31
US Shibboleth Federations

• InQueue
• InCommon
• Uses
• Management
• Policies
• Shared schema
• Club Shib
• NSDL
• State, system, and campus federations
• Texas, Ohio State, etc

32
The Research and EducationFederation Space
Indiana
Slippery slope - Med Centers, etc
33
InQueue

• The holding pond
• Is a persistent federation with passing-through
  membership
• Operational today. Can apply for membership via
  http//shibboleth.internet2.edu
• Requires eduPerson attributes
• Operated by Internet2 open to almost anyone
  using Shibboleth in an RE setting or not
• Fees and service profile to be established
  shortly cost-recovery basis

34
Some InQueue Credential Providers

• Brown University
• Cal Poly Pomona
• Carnegie Mellon University
• Columbia University
• Cornell University
• Dartmouth College
• Duke University
• Georgetown University
• Georgia State University
• Internet2
• London School of Economics
• Michigan State University
• National Research Council of Canada
• New York University
• Penn State University
• Rutgers University
• The Ohio State University
• The University of Kansas

• University of Alaska Fairbanks
• University of Arkansas
• University of Bristol
• University of Buffalo
• UCLA
• University of California, San Diego
• University of California Shibboleth Pilot
• University of Colorado at Boulder
• University of Michigan
• University of Minnesota
• University of Missouri - Columbia
• University of North Carolina at Chapel Hill
• University of Rochester
• University of South Dakota
• University of Southern California
• UT Arlington
• UTHSC-Houston
• University of Virginia
• University of Wisconsin

35
What is InCommon?

• A Shibboleth-based Research and Education
  Federation for the US
• A public-sector, large-scale, persistent
  federation

36
Federation

• Federation operations Internet2
• Federating software Shibboleth 1.2 and above
• Federation data schema - eduPerson200210 or later
  and eduOrg200210 or later
• Federated approach to security and privacy with
  posted policies
• Became fully operational mid-September, with
  several early entrants shaping the policy issues.
• Precursor federation, InQueue, has been in
  operation for about a year and will feed into
  InCommon approximately 150 members
• http//www.incommonfederation.org

37
Principles

• Support the RE community in inter-institutional
  collaborations
• InCommon itself operates at a high level of
  security and trustworthiness
• InCommon requires its participants to post their
  relevant operational procedures on identity
  management, privacy, etc
• InCommon will be constructive and help its
  participants move to higher levels of assurance
  as applications warrant
• InCommon will work closely with other national
  and international federations

38
Uses

• Institutional users acquiring content from
  popular providers (Napster, etc.) and academic
  providers (Elsevier, JSTOR, OCLC, EBSCO,
  Pro-Quest, etc.)
• Institutions working with outsourced service
  providers, e.g. grading services, scheduling
  systems
• Inter-institutional collaborations, including
  shared courses and students, research computing
  sharing, etc.
• (Shared network security monitoring, interactions
  between students and federal applications,
  peering with international activities, etc.)

39
Management

• Legal - initially LLC, likely to take 501(c)3
  status
• Governance
• Steering Committee Carrie Regenstein, chair
  (Wisconsin), Jerry Campbell (USC), Lev Gonick
  (CWRU), Clair Goldsmith (Texas System), Ken
  Klingenstein (I2), Mark Luker (EDUCAUSE), Tracy
  Mitrano (Cornell), Susan Perry (Mellon), Mike
  Teets (OCLC), David Yakimischak (JSTOR)
• Two Steering Committee advisory groups
• Policy Tracy Mitrano, Chair
• Communications, Membership, Pricing, Packaging
• Susan Perry, Chair
• Technical Advisory Group Scott Cantor (OSU),
  Steven Carmody (Brown), Bob Morgan (UWash), Renee
  Shuey (PSU)
• Project manager Renee Woodten Frost (Internet2)

40
Operations

• Operational services by Internet2
• Storefront (process maps, application process)
• Backroom (CA, WAYF service, etc.)
• Federation Operating Practices and Procedures
  (FOPP)
• InCommon Process Technical Advisory
• 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 and witnessed

41
Participants

• Two types of participants
• Higher ed institutions - .edu-ish requirements
• Resource providers commercial partners
  sponsored by higher ed institutions, e.g. content
  providers, outsourced service providers, etc
• Participants can function in roles of identity
  providers and/or resource providers
• Higher ed institutions are primarily identity
  (credential) providers, with the potential for
  multiple service providers on campus
• Resource (service) providers are primarily
  offering a limited number of services, but can
  serve as credential providers for some of their
  employees as well

42
Pricing

• Goals
• Cost recovery
• Manage federation stress points
• Prices
• Application Fee 700 (largely enterprise I/A,
  db)
• Yearly Fee
• Higher Ed participant 1000 per identity
  management system
• Sponsored participant 1000
• All participants 20 ResourceProviderIds
  included additional ResourceProviderIds
  available at 50 each per year, available in
  bundles of 20

43
Trust in - initial

• Members trust the federated operators to perform
  its activities well
• The operator (Internet2) posts its procedures
• Enterprises read the procedures and decide if
  they want to become members
• Contracts address operational and legal issues
• Origins and targets establish trust bilaterally
  in out-of-band or no-band arrangements (using
  shared posting of practices)
• Origins must trust targets dispose of attributes
  properly
• Targets must trust origins to provide attributes
  accurately
• Risks and liabilities managed by end enterprises,
  in separate ways
• Collaborative apps are generally approved within
  the federation
• Higher risk apps address issues through
  contractual and legal means

44
Members trust Operations

• The federation operations presents limited but
  real exposures in identity proofing members
  properly and in the metadata management
• InCommon publishes its procedures for identity
  proofing and its operational procedures
• InCommon Certificate Authority CP/CPS
• Metadata management process
• Individual enterprises read the policies and
  decide whether to trust the federation operations
  and how to assign liability

45
Operations Docs

• InCommon_Federation_Disaster_Recovery_Procedures_v
  er_0.1
• An outline of the procedures to be used if there
  is a disaster with the InCommon Federation.
• Internet2_InCommon_Federation_Infrastructure_Techn
  ical_Reference_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.

46
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_compromise_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_I
  nCommon_Federation_System_Technical_Reference_ver_
  0.41
• Document describing the CA.

47
Participant Agreement Highlights

• Agree to post policies
• Security
• Basic identity management
• Privacy
• Inform InCommon on a timely basis of key
  compromise
• Be responsible for ResourceProviderIds issued
• Be responsible for adhering to their POPS
  statement
• Stay timely on metadata

48
Members Trusting Each OtherParticipant
Operational Practice Statement

• Basic Campus identity management practices in a
  short, structured presentation
• Identity proofing, credential delivery and
  repeated authentication
• Provisioning of enterprise-wide attributes,
  including entitlements and privileges
• Basic privacy management policies
• Standard privacy plus
• Received attribute management and disposal

49
Trust Pivot Points in Federations

• In response to real business drivers and feasible
  technologies, need to increase the strengths of
• Campus/enterprise identification, authentication
  practices
• Federation operations, auditing thereof
• Campus middleware infrastructure in support of
  Shib (including directories, attribute
  authorities and other Shib components) and
  auditing thereof
• Relying party middleware infrastructure in
  support of Shib
• Moving in general from self-certification to
  external certification

50
International Federation Peering

• Shibboleth-based federations in the UK,
  Netherlands, Finland, Switzerland, Australia,
  Spain, and others
• International peering meeting October 14-15 in
  Upper Slaughter, England
• Issues include agreeing on policy framework,
  comparing policies, correlating app usage to
  trust level, aligning privacy needs, working with
  multinational service providers, scaling the WAYF
  function
• Leading trust to Slaughter

51
Leading Trust to Slaughter
52
Three Types of Issues

• Internal federation issues
• Business drivers educational, research, admin
  helping each country find a reason
• Cookbook key issues and common touchpoints
• Alignment with other trust services such as PKI
• Inter-federation issues
• Needs for agreements
• Authentication context, attributes
• Needs for legal frameworks
• Assignment of roles within federation between
• Treaties/MOU between federations
• Union of federations issues

53
Inter-federation Agreements

• Protocols
• Shib on the outside generally Shib within
• Versioning issues
• Data
• Authn context field structure and values
• LOA US Federal guidelines, the Australian
  points system, etc.
• Eduperson, eduOrg and cross-mappings
• Persistent identifiers
• Trust
• Federation operations
• Inter-federation legal agreements
• Member statements
• Formats
• Controlled vocabulary

54
League of Federations

• Brand, logo, presence
• Handling international resource-providers
• Qualifying new members
• Relationship to other sector activities,
  particularly government (and health services)
• Support for virtual organizations
• Promoting its use for applications eduRoam,
  GLIF, Grids
• EU Privacy issues
• International WAYF
• Universal InQueue

55
Leading Trust from Slaughter
56
Immediate International Issues

• International WAYF management of the user
  experience
• List of Federations that contain IdPs
• Where to put multi-nationals?
• Handling of exceptions in a consistent fashion
• Privacy
• EU Privacy directives intended for attributes
  associated with identity
• Rules for interior and exterior privacy may be
  different for EU
• And then theres the Swiss

57
Federal Government

• Federal E-Authentication has a number of pilots
  under way. One of them is now Shib.
• Phase 1 and Phase 2 efforts funded, with
  deliverables due over the next six months
• Policy framework comparison submitted Oct 7
• Technical interoperability demonstrated October
  14
• Policy discussions and applications meetings now
  occurring
• Potential phase 3 and 4 would include working on
  a federal federation and peering with Higher Ed
  and other federations meetings underway

58
WS-Fed and Shib

• Verbal agreements to build WS-Fed
  interoperability
• Contract work commissioned by Microsoft, executed
  by Shib core development
• Contracts executed and work likely this Spring
• Discussions broached, by Microsoft, in building
  Shib interoperabilty into WS-Fed
• Devils in the details

59
For More Information

• Websites
• http//middleware.internet2.edu
• http//shibboleth.internet2.edu
• http/www.incommonfederation.org
• Renee Woodten Frost rwfrost_at_internet2.edu