1. Protecting Privacy; Gaining Access Renee Woodten Frost Cheryl Munn-Fremon Renee Woodten Frost Cheryl Munn-Fremon

2. 2 Copyright Renee Woodten Frost and Cheryl Munn-Fremon, 2005. This work is the intellectual property of the authors. 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 authors. To disseminate otherwise or to republish requires written permission from the authors.

3. 3 Internet2 Mission and Goals Internet2 Mission Develop and deploy advanced network applications and technologies, accelerating the creation of tomorrow’s Internet. Internet2 Goals Enable new generation of applications Re-create leading edge R&E network capability Transfer technology and experience to the global production Internet

4. 4 Internet2 Today MotivateEnable End-to-end Performance Networks Middleware Applications Services Security

5. 5 Topics for Today Why Important Federations InCommon For more information

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

7. 7 What We’re All Trying to Accomplish Simplify end user access to multitude of online services Facilitate operation of those services by IT organizations Increase security Preserve individual privacy Enable online service for our constituents earlier in their affiliation with us, wherever they are, and ongoing Participate in new, inter-organizational, collaborative architectures and environments

8. 8 How We Can Facilitate It Identity and Access Management: provides an enterprise-wide, policy-driven middleware infrastructure that enables: Scalability Consistency Integrity Integration Collaboration

9. 9 Identity Management (IdM) Set of standards, policies, procedures, and technologies that provide electronic credentials to individuals and maintain authoritative information about the holders of those credentials.. and assist in determining and granting access.. aka “Identity and Access Management”

10. 10 IdM Infrastructure Definitions Identity set of attributes about, and identifiers referring to, a subject (person, service…) Authentication process used to associate a subject with an identifier Authorization process of determining if policy permits an intended action to proceed Credentials attributes about a subject used to identify (authentication) or make access decisions (authorization) about what it can do in a particular context

11. 11 Higher Ed Need for Federated Administration 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.

12. 12 Federated Identity Management Relying on the Identity Management infrastructure of one or more institutions or units.. to authenticate and pass authorization-related information to service providers or resource- hosting institutions or enterprises.. via institution-provider agreements.. facilitated by common membership in a federation (like InCommon)

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

14. 14 What is Shibboleth? (federating software) 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 identity providers = campuses (origins) Software for resource providers (targets) Operational Federations (scalable trust)

15. 15 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)

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

17. 17 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 resource provider 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.

18. 18 Typical Attributes in the Higher Ed Community Affiliation“active member of community” member@washington.edu EPPN (eduPersonPrincipalNa me) Identitygettes@duke.edu EntitlementAn agreed upon opaque URI urn:mace:vendor:contract1 234 OrgUnitDepartmentEconomics Department EnrolledCourseOpaque course identifier urn:mace:osu.edu:Physics2 01

19. 19 Shibboleth Architecture

20. 20 Current Status: Shibboleth v. 1.2.1 Open-source, standards-based, privacy- preserving federating software Accelerating deployment globally: InCommon, NSDL, SWITCH, Finland, Netherlands, United Kingdom (three), Australia, InQueue, League of Federations Commercial information providers in production: Elsevier Science Direct, OCLC, etc. Working on underlying Attribute Authority GUI and resource protection Growing international development interest providing resource manager tools, email list software, etc.

21. 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. 22 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 Resource Provider 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

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

25. 25 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 trust: 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

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

27. 27 The Research and Education Federation Space REF Cluster InQueue (a starting point) InCommo n SWITCH The Shib Resear h Club Other national nets Other clusters Other potenti al US R+E feds State of Penn Fin Aid Assoc NDS L Slippery slope - Med Centers, etc Indiana

28. 28 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; approximately 150 participants 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

29. 29 Federation A permanent federation for the R&E US sector Federation operations – Internet2 Federating software – Shibboleth 1.2 and above Federation data schema - eduPerson200210 or later and eduOrg200210 or later Federated approach to security & privacy with posted policies Became fully operational September 2004, with several early entrants shaping the policy & process issues. http://www.incommonfederation.org

30. 30 Principles Support the R&E community in inter- institutional collaborations InCommon itself operates at a strong level of security and trustworthiness InCommon requires its participants to post their relevant operational procedures on identity management, privacy, etc InCommon will work closely with other national and international federations

31. 31 Trust 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 Identity Providers and Resource Providers trust each other bilaterally in out-of-band or no-band arrangements Risks and liabilities managed by end enterprises, in separate ways

32. 32 So where did we begin? InQueue Virtual Production Team Middleware project manager Finance Membership Communications and Branding Technical Support Group Legal/Organizational VPT Director Began Deployment Plan Established a preliminary budget and business model

33. 33 Morphing into a Deployment Team Middleware Project Leader VPT Director Technical Services team Documentation specialist Developer representative Legal coordinator And after we were far down the road Deployment Project Manager

34. 34 Operational Staffing today Operations Manager Documentation/Communication specialist Registrar/Administrative Assistant A/R support Technical Services Team Middleware Project Manager

35. 35 LLC Management Governance Steering Committee: Carrie Regenstein, Chair (Wisconsin) Two Steering Committee working groups Policy Communication, Membership, Pricing/Packaging Technical Advisory Group Operations – Internet2 InCommon Certificate Authority Issuing the enterprise certificate signing keys Metadata and Certificate submission Hosting the WAYF (where are you from) Supporting Campuses in posting their policies Store front (process maps, application process, billing, registry authority

36. 36 Where the real work began Developing the documents Getting all the stakeholders to agree to the policies and practices Defining the rules and processes for who could join Determining the rigor of the identification process Developing pricing/packaging plan

37. 37 Documents (to date) LLC Membership criteria Pricing/packaging cost recovery model Federation Operating Practices and Procedures (FOPP) and Technical Operations Docs Participant Agreement (PA) Participant Operational Practices (POP)

38. 38 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_Refer ence_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.

39. 39 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_c ompromise_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.

40. 40 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 their employees as well

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

42. 42 So you want to join Review federation documents Evaluate risks Complete the web application form and identify: Executive Liaison InCommon Administrative Contact Billing Contact Pay $700 application fee by credit card http://www.incommonfederation.org/

43. 43 Participant Risk Assessment Areas of possible risk Misrepresentation by a participant organization Incorrect or corrupted metadata Incorrect public key for Participant Mis-configuration or malfunction of the InCommon WAYF Failure to notify Participants of changes in FOPP or POPs

44. 44 Identity Verification Process by Internet2 Review the application and request any additional information Verify organization is a U.S, 2- or 4-year institution of higher education Verify individual’s identification Phone number in public directory Direct contact with executive liaison Send out Participation Agreement for signature Prepare Invoice

45. 45 Participant Next Steps Sign Participation Agreement and return paper copies to InCommon Pay $1000 annual fee Administrative contact will receive unique ID and password. Receive certificate (s) from InCommon Post your Participant Operational Practices (POP) and provide URL to InCommon

46. 46 Participation Agreement Participant Responsibilities Employ an implementation of Shibboleth or equivalent Use Identity Attributes as described on website Install any software that may be required by the Federation Provide InCommon with accurate metadata Terms of any agreement between participants shall be agreed to by and among such participants

47. 47 Participation Agreement cont’d. Participant Responsibilities cont’d. Provide technical and administrative contact information Bear its own costs and expenses Participate in a manner that does not violate Federal, state or local laws or that interferes with others Make available reliable and trustworthy information about its identity management system

48. 48 Participant Operational Practices Provide authoritative and accurate attribute assertions Attributes are protected and privacy respected Provide basic information about identity management system A series of questions for Participants Participant information Electronic Identity Database information Attribute Assertions Privacy Policy

49. 49 Trustworthy Attribute Assertions Requirements ID management system is under the purview of the executive or business management System for issuing end-user credentials has in place appropriate risk management measures Authentication standards Security practices Audit trails Etc.

50. 50, 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 Federal Government “Peering” with national federations in other countries “Gateways” with commercial federations

51. 51 For More Information Websites http://middleware.internet2.edu http://shibboleth.internet2.edu http:/www.incommonfederation.org Renee Woodten Frost rwfrost@internet2.edu rwfrost@internet2.edu Cheryl Munn-Fremon cmfremon@internet2.edu

52. 52