Origins: The Requirements of Participating in Federations CAMP Shibboleth June 29, 2004 Barry Ribbeck & David Wasley

Credential Providers: Requirements for Participation in Federations CAMP Shibboleth June 29, 2004 Barry Ribbeck & David Wasley

The Essence of Federation  A federation is much like a digital community  Communities “work” if People speak a common (enough) language People behave in ways that enable successful coexistence  Trust in the real world is often defined as much by experience as by rules Hard to replicate with machines that expect 1’s or 0’s.  In order to participate in an electronic identity federation, an institution must understand and play by the rules and must communicate with other participants using a common language (syntax and semantics)

Federated Identity  Credential Providers establish electronic identities “Identity” is the set of information associated with a person An “electronic credential” issued to the person is linked to their “identity”  Resource Providers offer access to resources for specific groups of people Based in part on some aspect(s) of their identity  Resource Providers are asked to trust Credential Providers to offer accurate information  Credential Providers and their subjects trust Resource Providers to not misuse that information  Why should they?

Why a Federation for the Academic Community?  Scenario #1: Instruction Professor teaches at USC, which has enrolled students from CMU, through an inter-institutional cooperative agreement of universities. During scheduled office hours, the professor works at her workstation, when a pop-up box appears that John Doe from CMU is requesting to initiate a videoconference with her. (authZ #1) Info is also conveyed that CMU asserts that this is, in fact, who he claims to be and further, is an enrolled student in the class. She can make an informed decision about whether to accept the videoconference invitation. (authZ #2) The info is believed because it has been delivered in the context of a trusted federation.

Why a Federation for the Academic Community?  Scenario #2: Research A group of researchers, spread across a number of participating institutions of the federation, want to securely share a web site located on one of the campuses. Each researcher can use his or her own campus identity and login to access the restricted site. Confidence is based on the fact that the institutions belong to a trusted federation.

Why a Federation for the Academic Community?  Scenario #3: Living and learning A content provider (aka “target”) wants to change from IP access controls to better technologies for gating content to an institutional customer, and is therefore willing to accept campus credentials for access to content. This provides better security and enables higher levels of granularity in controlling access if restricted access is desired. The basis for the content provider trusting in the origin is the trusted federation.

The InCommon Federation  The InCommon federation is intended to support production- level end-user access to protected resources by providing the means to allow organizations to make effective decisions about sharing resources, based upon the attributes presented by an authoritative source on behalf of requesting user.  InCommon Federation operations – supported by Internet2 Establishes minimum standards for the community Issues credentials for use with federation service platforms Distributes metadata about federation participants  InCommon Federating software and data schema Shibboleth 1.1 and above, though others may be added later eduPerson or later and eduOrg or later  InCommon registers participants and distributes metadata

Participants trust in the Federation  Participants trust the federated operations to perform the federation’s activities well Vetting process for InCommon component identity credentials for participants’ Shib platforms Reliable process for collecting & distributing necessary operational information among participants The operator (Internet2) posts its procedures, attempts to execute them faithfully, and makes no warranties InCommon will make a reasonable effort to ensure that it is working with individuals who truly can represent the participant organization. Organizations read the procedures and decide if they want to participate

Participants trust in each other  Credential Providers trust that Resource Providers will do what they say  Resource Providers trust that Credential Providers have in place the proper controls and procedures to manage credentials  CPs and RPs trust each other through bilateral arrangements Participants post a statement of basic information (POP) Risks and liabilities managed by end enterprises, in separate ways

What is required of a Credential Provider?  Establish “Identity Management” as part of critical business practices Visible and supported at high levels Backed by institutional policy and practices  Develop authoritative Person Registry What elements of identity are needed? What office is authoritative for which elements?  Decide what type of credentials are needed Depends on risk associated with use of associated identity UserID/pwd - weak but OK for many things PKI on smartchip device - strong and needed for some things  Implement operational practices & technology

Inventory of campus identity elements  Typically starts with Registrar and HR data But not -all- such data is needed in this context  Campus adds things like person IDs, addresses, affiliations, roles (some day)  The identifier inventory informs the process of determining the requirements for trust, including what assertions are acceptable for what purposes.  Risk and trust requirements are determined by the resource providers and the users considering their personal privacy risk.  How all this is managed is important!

Credentials  Electronic credentials connect a person to information about them  How does your campus ensure this connection is valid? The initial I&A process is critical Different processes result in different levels of assurance  Are credentials shared (or sharable)?  High risk or sensitive applications may require more than one credential  Some people may require more than one credential And possibly more than one identity

Developing levels of assurance  How much assurance is needed for various purposes?  Risk and trust requirements will be determined by the resource holder as well as the user considering their personal privacy risk. Taken together, these requirements will determine the technologies and policies implemented. At the low risk & low trust end of the continuum: public information websites, videoconferencing meeting for the Shib Development Team. –What assertions— if any — should be required? At the mid-level of risk and trust: access to copyrighted materials, course management systems, business services, etc. At the high risk & high trust end of the continuum: access to medical records, data from a bio-terrorism lab, videoconferencing meeting of security experts discussing response to network security emergency.

Theoretical Risk-Trust Matrix

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 participants; “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 integrate with other emerging federations and and with federal and international activities  If it does scale and grow, it could become a most significant component of cyber-infrastructure…

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  Audit requirements unclear  International issues (language, legal, political,…)

Getting to first base  Alphonse-Gaston: establishing a set of rules to determine criteria for InCommon participation Individual participants may not want to know the details about other participants’ policies. Do they need to? –Trust engendered through optional disclosures. Federation participants use different assumptions, e.g, some University Systems may want to join as a collective system, while others would prefer to join as individual campuses. Is consistency important? Are multiple federation memberships problematic? Should participants be asked to vouch for other potential participants?

Authenticate locally, Act federally  For general information  For participation information