InCommon: A Shibbolethbased Research and Education Federation A publicsector, largescale, persistent

1
InCommon A Shibboleth-based Research and
Education Federation (A public-sector,
large-scale, persistent federation)
Renee Woodten Frost Internet2 Middleware and
Security 16 Dec 2004
2
Topics

• Basics
• Persistent federations
• A Shib slide
• InQueue and InCommon
• International RE federations
• Leading Trust to Slaughter
• Immediate issues WAYF, privacy
• The Federal e-Authentication work
• Working with Microsoft
• Next Steps

3
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

4
Business drivers for federations

• Corporate
• Need to link consumer identities among disparate
  service providers
• Link corporate employees through a company portal
  to outsourced employee services transparently
• Allow supply chain partners to access each others
  internal web sites with role based controls
• Research and education
• Access to and sharing of digital content
• The visiting scientist and eduRoam
• Inter-institutional courseware
• Grids and collaborative tools
• The commodity marketplace to come

5
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

6
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.3 1Q05 non web services, e-Auth
  certified,
• Shib v1.4 WS-Fed compliant
• OpenSAML 2.0 relatively soon, we hope
• Refactored Shib 2.0 3Q05?

7
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

8
Federal guidelines of relevance

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

9
US Shibboleth Federations

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

10
The Research and EducationFederation Space
Indiana
Slippery slope - Med Centers, etc
11
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

12
Some InQueue Origins

• 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

13
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 six months and will feed into
  InCommon approximately 150 members
• http//www.incommonfederation.org

14
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

15
Uses

• Institutional users acquiring content from
  popular providers (Napster, etc.) and academic
  providers (Elsevier, JSTOR, 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.)

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

17
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

18
Participants

• Two types of participants
• Higher ed institutions - .edu-ish requirements
• Service 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

19
I 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

20
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

21
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 CA CP/CPS
• Metadata management process
• Individual enterprises read the policies and
  decide whether to trust the federation operations
  and how to assign liability

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

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

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

25
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

26
Members Trusting Each OtherParticipant
Operational Practice Statement

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

27
Trust Pivot Points in Federations

• In response to real business drivers and feasible
  technologies,
• 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

28
The Art of Federation

• Prudence in ResourceProviderIds
• Use of targetedId (anonymous, persistent state)
• Original warnings
• Ability to request target amnesia/reset
• Diagnostics of fine-grain access control
• Overlapping and interacting federations

29
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

30
Leading Trust to Slaughter
31
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
• Authncontext, attributes
• Needs for legal frameworks
• Assignment of roles within federation between
• Treaties/MOU between federations
• Union of federations issues

32
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

33
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

34
Leading Trust from Slaughter
35
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

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

37
InCommon eAuth

• Federation interop with Shib (PKI in SAML)
• To ultimately use Bridge PKI as means of
  validating and locating members of OTHER
  federations
• InCommon CA to X-Certify with HEBCA or be signed
  by USHER having been X-Certified with HEBCA
• ShibGrid to address some Grid issues
• HEBCAGrid considered but no work yet
• See next slide

38
(No Transcript)
39
WS-Fed and Shib

• Verbal agreements to build WS-Fed
  interoperability
• Contract work commissioned by Microsoft, executed
  by Shib core development contracts executed by
  end of year, but work likely not till Spring
• WS-Federation Passive Requestor Profile
  Passive Requestor Interoperability Profile
• Discussions broached, by Microsoft, in building
  Shib interoperabilty into WS-Fed
• Devils in the details
• Can WS-Fed-based SPs work in InCommon without
  having to muck up federation metadata with
  WS-Fed-specifics?
• All the stuff besides WS-Fed in the WS- stack

40
Next Steps

• The GUIs and the diagnostics
• Commercial and value-added versions of Shibboleth
• Federation peering, likely using BCA frameworks
• Federated network security
• Use with virtual organizations
• Federated authorization