Internet2 Middleware & Security/University of Michigan Federations Renee Woodten Frost Internet2 Middleware & Security/University of Michigan November 17, 2004

Topics Federations: The Basics Shibboleth-based Federations InCommon Management Operations Trust/Policies Next Steps 12/6/2018 2

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 12/6/2018 3

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 12/6/2018 4

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 object classes, 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. 12/6/2018 5

Federated Administration VO VO O T Apps CM O T CM Apps Other feds Campus 1 Campus 2 T T T Federation 12/6/2018 6

State of Federations Today Buzz Existent approaches Corporate: internal and short-term external R&E: persistent external collaborations (and some internal) Government: applications and qualified Credential Providers Possible convergence of models Persistent public federations Ad hoc business federations Peering within and among using bridged approaches 12/6/2018 7

Requirements for Federations Federation operations Federating software Exchange assertions Link and unlink identities Federation data schema Federation privacy and security requirements 12/6/2018 8

Federations and PKI The rough differences are payload format (SAML vs X.509) and typical length of validity of assertion (real-time vs long-term) Federations use enterprise-oriented PKI heavily and make end-user PKI both more attractive and more tractable. The analytic framework (evaluation methodologies for risk in applications and strength of credentials) developed for PKI is useful for federations. The same entity can offer both federation and PKI services PKI-oriented infrastructure (e.g. Federal Bridge CA) can be leveraged in support of federations 12/6/2018 9

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 12/6/2018 10

Federal Guidelines of Relevance NIST Guideline on Risk Assessment Methodologies NIST Guideline on Authentication Technologies and their strengths Federal e-Authentication 12/6/2018 11

US Shibboleth Federations InQueue InCommon Uses Management Policies Shared schema Club Shib National Science Digital Library (NSDL) State, system, and campus federations Texas, Ohio State, etc… 12/6/2018 12

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 12/6/2018 13

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 R&E setting or not… Fees and service profile to be established shortly: cost-recovery basis 12/6/2018 14

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 12/6/2018 15

InCommon Federation Federation operations – Internet2 Federating software – Shibboleth 1.1 and above Federation data schema - eduPerson200210 or later and eduOrg200210 or later Became fully operational mid-September, with several early entrants already in to help shape the policy issues. Precursor federation, InQueue, in operation for almost a year and will feed into InCommon; approximately 150 members http://www.incommonfederation.org 12/6/2018 16

InCommon Principles Support the R&E 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 12/6/2018 17

InCommon Uses Institutional users acquiring content from popular providers (Napster) and academic providers (Elsevier, JSTOR, EBSCO, Pro-Quest, etc.) Institutions working with outsourced service providers, e.g. grading services, scheduling systems, LMS (WebAssign, Blackboard, etc.) Inter-institutional collaborations, including shared courses and students, research computing sharing, etc. 12/6/2018 18

InCommon 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) 12/6/2018 19

InCommon 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 12/6/2018 20

InCommon Participants Two types of participants: Higher ed institutions: 2- and 4-year accredited Resource providers: partners sponsored by higher ed institutions, e.g. content providers, outsourced service providers (WebAssign, Roomschedulers, etc) Participants can function in roles of credential/identity providers and resource/service providers Higher ed institutions are primarily credential providers, with the potential for multiple service providers on campus Resource providers are primarily offering a limited number of services, but can serve as credential providers for some of their employees as well 12/6/2018 21

InCommon Pricing Goals Prices Cost recovery Manage federation “stress points” Prices Application Fee: $700 (largely enterprise I/A, db) Annual 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 12/6/2018 22

Trust in InCommon - Initial Use trust  Build trust cycle 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 + liabilities managed by end enterprises, in separate ways 12/6/2018 23

Balancing the Operator’s Trust Load InCommon Certificate Authority (CA) Identity proofing the enterprise Issuing the enterprise signing keys (primary + spare) Signing the metadata Could be outsourced InCommon Federation Aggregating the metadata Supporting campuses in posting their policies Less easy to outsource 12/6/2018 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. 12/6/2018 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. 12/6/2018 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. 12/6/2018 27

Participant Agreement Highlights Agree to post policies Security Basic identity management Privacy Inform InCommon on a timely basis of key compromise Be prudent about and responsible for ResourceProviderIds issued Be responsible for adhering to their POP statement 12/6/2018 28

Participant Operational Practice (POP) 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 12/6/2018 29

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 12/6/2018 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… 12/6/2018 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 12/6/2018 32

Next Steps Applications Some leverage federations Some ignore inter-institutional uses Content providers increasingly aware; outsource providers learning Open-source development community is challenge Commercial and value-added versions of Shibboleth Federal E-Authentication Move towards standard levels of assurance Possible applications: Ed loans, Fastlane Federation interactions/peering: inter-fed, union of feds 12/6/2018 33