Introduction to Federations Renee Woodten Frost Internet2 Middleware & Security/University of Michigan June 29, 2004

Copyright Renee Woodten Frost 2004 Copyright Renee Woodten Frost 2004. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author. 4/23/2019 2

Topics Federations: The Basics Leading Edge Experiences Business drivers and the basic model Technical Considerations Policy Considerations Leading Edge Experiences Shibboleth-based federations InQueue InCommon Management Trust/Policies Operations Phase One Rollout Shibboleth and InCommon International federations and inter-federation issues 4/23/2019 3

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 4/23/2019 4

Business drivers for R&E 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. 4/23/2019 5

Requirements for Federations Federation operations Federating software Exchange assertions Link and unlink identities Federation data schema Federation privacy and security requirements Non web services can also leverage federations 4/23/2019 6

Federating Software Comparison Liberty Alliance V 1.1 of their functional specs released; 2.0 under discussion Federation itself is out of scope Open source implementations not emphasized Current work is linked identities Shibboleth V1.2 released; 1.3 and 2.0 under development Most standards-based; pure open source in widening use Current work is attribute release focused; linking identities in 2.0. Can Shibboleth and Liberty converge? SAML 2.0 is key WS-* Complex framework, consisting of 9 areas, which can form a whole cloth solution to the problem space, but which need to closely interact with each other to do so. Standards process and IPR issues uncertain Will need considerable convention and detail to resolve into a working instantiation Can Shibboleth/InCommon interoperate with WS-*? Under active discussion with Microsoft 4/23/2019 7

The Point of Privacy Kudos for Shibboleth! Liberty Alliance Has Missed the Point eWeek November 24, 2003 By  Jim Rapoza  http://www.eweek.com/article2/0,4149,1396027,00.asp What I'd like to see the group do is add more mechanisms to make it easy for third-party developers to create tools that give users total control over how their data is shared. A good model for this is the Internet2 group's Shibboleth ID management specification, which was designed mainly for academic institutions. In Shibboleth, users have built-in controls that give them final say over how their data is controlled. 4/23/2019 8

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 the information to be shared Privacy issues must be addressed at several layers All this needs to be done on scalable basis, as number of participants grow and number of federations grow 4/23/2019 9

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 architecture from P2P trust Virtual organizations cross-stitch across one of the above 4/23/2019 10

Federal Guidelines of Relevance NIST Guideline on Risk Assessment Methodologies NIST Guideline on Authentication Technologies and their strengths Federal e-Authentication 4/23/2019 11

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. 4/23/2019 12

Federated Administration VO VO O T Apps CM O T CM Apps Other feds Campus 1 Campus 2 T T T Federation 4/23/2019 13

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 4/23/2019 14

The Research and Education Federation Space REF Cluster InQueue (a starting point) InCommon SWITCH The Shib Research Club Other national nets Other clusters Other potential US R+E feds State of Penn Fin Aid Assoc NSDL Indiana Slippery slope - Med Centers, etc 4/23/2019 15

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 4/23/2019 16

InQueue Origins 2.12.04 National Research Council of Canada Columbia University University of Virginia University of California, San Diego Brown University University of Minnesota Penn State University Cal Poly Pomona London School of Economics University of North Carolina at Chapel Hill University of Colorado at Boulder UT Arlington UTHSC-Houston University of Michigan University of Rochester University of Southern California Rutgers University University of Wisconsin New York University Georgia State University University of Washington University of California Shibboleth Pilot University of Buffalo Dartmouth College Michigan State University Georgetown Duke The Ohio State University UCLA Internet2 Carnegie Mellon University 4/23/2019 17

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, etc Outsourced Service Providers – purchasing systems, dormitory management companies, etc. 4/23/2019 18

InCommon Federation A permanent federation for the R&E US sector To be operated by Internet2, open to regionally accredited 2- and 4- year education institutions and business partners Became operational April 5, with several early entrants to help shape the policy issues. Precursor federation, InQueue, has been in operation for almost a year and will feed into InCommon http://www.incommonfederation.org 4/23/2019 19

Federation Requirements - InCommon Federation operations – Internet2 ProductionTeam Federating software – Shibboleth 1.1 and above Federation data schema - eduPerson200210 or later and eduOrg200210 or later Federation privacy and security requirements – in discussion; could be: Privacy requirements: Initially, destroy received attributes immediately upon use Security requirements: Initially, enterprises post local I/A and basic business rules for assignment of eduPersonAffiliation values Likely to progress towards standardized levels of authentication Logout issues 4/23/2019 20

InCommon Management Operational services by Internet2 Governance Application - 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 4/23/2019 21

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 4/23/2019 22

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 4/23/2019 23

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 4/23/2019 24

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_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. 4/23/2019 25

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_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_InCommon_Federation_System_Technical_Reference_ver_0.41 Document describing the CA. 4/23/2019 26

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. 4/23/2019 27

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 4/23/2019 28

Phase One Rollout Organizations from InQueue pool Requirements Initially 11 Recently added 5 Requests still coming Requirements Feedback on process and documents Participation in working group activities Targeted completion – August, 2004 4/23/2019 29

InCommon Documents (to date) Membership criteria Pricing/packaging cost recovery model Federation Operating Rules Participant Agreement Participant Operational Practice Statement (POPS) 4/23/2019 30

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… 4/23/2019 31

InCommon, some time from now Established with several hundred participants Multi-layered strength-of-trust threads among participants Working with state and/or regional federations “Peering” with national federations in other countries “Gateways” with commercial federations 4/23/2019 32

For More Information Websites http://middleware.internet2.edu/foo/ http:/www.incommonfederation.org http://shibboleth.internet2.edu Renee Woodten Frost rwfrost@internet2.edu 4/23/2019 33