InCommon Federation: Participant Operational Practices

 

Participation in InCommon enables the participant to use Shibboleth identity sharing technologies to manage access to on-line resources that can be made available to the InCommon community. One goal of the InCommon Federation is to develop over time community standards for such cooperating organizations to ensure that shared identity assertions are sufficiently robust to manage access to important protected resources. The InCommon Federation expects that participants eventually should be able to trust each other's identity management systems as they would trust their own. The fundamental requirement that InCommon imposes on participants is that they provide authoritative and accurate identity information to other participants. In furtherance of this goal, InCommon requires that each participant make available to other participants certain basic information about their identity management system.

 

Two criteria for trustworthy assertions are: (1) that the identity management system fall under the purview of an organization's executive management and (2) the system for issuing end-user credentials (e.g. userids/passwords, Kerberos principles, etc.) specifically have in place appropriate risk management measures (for example authentication and authorization standards, security practices, risk assessment, change management controls, audit trails, etc.)

 

InCommon requires that Resource Providers, who receive identity assertions from another organization, respect the other organization's policies, rules and standards regarding the protection and use of that data. Furthermore, such information must be used only for the purpose for which it was provided. InCommon prohibits the sharing of that data with third parties or aggregation of it for marketing or reporting purposes without explicit permission of the information provider.

 

InCommon requires participating organizations to make available to all other InCommon participants answers to the questions below.[1] Additional information to help answer each question is available in the next section of this document.

 

1.     Participant Information Contact

Please identify a person or office at your organization who can answer questions about your identity management or resource access management policy or practice.

Name Andrea Beesing                                                                                     

Title or role Assistant Director, Identity Management                                  

Email address amb3@cornell.edu                                                                    

Phone number 607-254-7441                                                                         

FAX 607-255-1297                                                                                           

2.     Federation Participant Community

2.1     If you are a Credential Provider, how do you define the set of people who are eligible to receive an electronic identity? If exceptions to this definition are allowed, who must approve such an exception?

Eligibility is set forth in University Policy 5.x Cornell Electronic Identifier, Information Technology Authentication and Authorization Policy (draft). Cornell issues NetIDs to members of the Cornell community: students, staff, faculty, affiliates and alumni. Unit heads (or their designees) may sponsor the issuance of a NetID to individuals who do work that furthers the mission of Cornell University. Cornell is in the process of implementing a guest ID, but we do not envision that these credentials would be used within the InCommon federation.                                    

2.2     What subset of this community would you identify as an eduPerson "Member of Community" in Shibboleth identity assertions to other InCommon participants? For example, this assertion might apply to anyone whose affiliation is "current student, faculty, or staff."

Current students, faculty and staff.                                                                                         

3.     Participant Community Authentication Policies and Practices

The most critical responsibility that a Participant has to the InCommon Federation is to provide trustworthy and accurate identity assertions.[2] It is important for a Resource Provider to know how your electronic identity credentials are issued and how reliable the information associated with a given credential (or person) is known.

Electronic Identity Credentials

3.1     Please describe the administrative process used to establish an electronic identity? Please identify the office(s) of record for this purpose. For example, "Registrar's Office for students; HR for faculty and staff."

NetIDs are issued by two offices at Cornell: the HR office for faculty and staff, the Contact Center (Helpdesk) of the central IT organization (CIT) for students, affiliates, exceptions with sponsor, and alumni who attended Cornell prior to the institution of NetIDs. A government-issued ID must be presented in all cases, except for the population of new students entering the University during the fall semester. Upon payment of the deposit, new students are issued a NetID to their permanent address on file with the University Registrar. The office of record for faculty and staff is HR, for students and alumni the University Registrar. Records for affiliates and exceptions with sponsor are created in the directory by the Contact Center (i.e. there is no central data of record)                                                                           

3.2     What technologies are used for your electronic identity credentials (e.g. Kerberos, userID/password, PKI, ...)? If more than one type of electronic credential is issued, how is it determined who receives which type?

Kerberos with userID (NetID) and password is used.                                                            

3.3     If your electronic identity credentials require the use of a secret password or PIN, are there circumstances in which that secret would be transmitted across a network without being protected by encryption (i.e. "clear text passwords" are used when accessing campus services)? If so, please describe.

The IT Office is currently sponsoring a university-level policy that would make it mandatory to eliminate this practice throughout the university, and the central IT organization is already committed to this principle. The transmission of the NetID password in clear text has been eliminated for most centrally-maintained applications. The remaining few will be addressed in the coming year.      

3.4     If you make use of a "single sign-on" or similar campus-wide system to authenticate people for use with InCommon Resource Providers, please describe the key security aspects of your SSO system such as session timeouts enforced by the system, whether user-initiated session termination is supported, how use with "public access sites" is protected, etc.

Cornell uses a Kerberos-based single sign-on system for authentication. When native Kerberos or Cornellπs out-of-band solution (SideCar) is used, the user is presented with a ticket indicator in the system tray which displays the user's NetID while a session is established. Users are educated to close this floating window when they are done to clear their session. Public labs post reminders. Some applications attempt to protect against users leaving credentials unattended by clearing the credentials cache and forcing authentication at key points in the applications (such as initial log in, and when performing updates). Default lifespan of a Kerberos ticket is 10 hours in the above scenario.           

CUWebLogin is the solution for web-based applications that does not require users to install software on the desktop. It utilizes a central server to prompt users for their NetID and Password over an SSL connection. Web sites which utilize CUWebLogin do not receive the user's password in any form.  Currently, CUWebLogin credentials are good only on a particular web site--if multiple sites are visited which require authentication, the user will need to authenticate via CUWebLogin to each separately. Currently there is no "indicator" that the user has CUWebLogin credentials established for a particular site. When authenticating via CUWebLogin users are reminded that they must close all browser windows (and the browser itself on a MacOS machine) in order to clear their credentials. We are currently at work on a "single-sign on web cookie " (not domain cookie based--similar in concept to Yale's CAS product) system which will also cause a pop-up browser window to be activated when credentials are established. This will be similar to the floating Kerberos window for natively kerberized applications.  The pop up window will have instructions on how to clear credentials and/or will have a link for clearing them if clicked. Target implementation date is 10/1/04. CUWebLogin credentials are good for 8 hours.

3.5     Are your primary electronic identifiers for people, such as "net ID" or eduPerson EPPN, considered to be unique for all time to the individual to whom they are assigned? If not, what is your policy for re-assignment and is there a hiatus between such reuse?

The NetID is unique to the individual, permanent and never reassigned.                             

Identity Credential Database

3.6     How is information in your identity database acquired and updated? Do Offices of Record perform this function? Are individuals allowed to update their own information on-line?

Offices of Record maintain identity information for staff, faculty, students and alumni. The CIT contact center maintains identity information for exceptions with sponsor and affiliates. Individuals can update bio-demo data such as campus address, home address, phone numbers, working title.                                       

3.7     What information in this database is considered "public information" and would be provided to any interested party?

Name, NetID, address, phone number, affiliation, job title, email address. Individuals can elect to suppress the display of data so that it cannot be publicly accessed.                      

Your Uses of Your Electronic Identity Credential System

3.8     Please identify typical classes of applications[3] for which your electronic identity credentials are used within your own organization?

Most centrally-maintained administrative applications including HR Payroll, Contributor Relations, Student Employment System, CourseEnroll, Faculty Advisor. The NetID and password are also used for wireless network registration, electronic mail, campus network dial-up service, billed printing service, online library resources, as an electronic signature in an online timecard system (COLTS).                                                                                                                                 

4.     Attribute Assertions

Attributes are the data elements in an identity assertion you might make to another InCommon Federation participant.

4.1     Would you consider your identity assertions to be reliable enough to:

control access to on-line information databases licensed to your organization?
be used to purchase goods or services for your organization?
enable access to personal information such as student loan status?

5.     Privacy Policy and Use of Acquired Information

InCommon Federation participants must respect the legal and organizational privacy constraints on identity information provided by other participants and use it only for its intended purposes.

5.1     What restrictions do you place on the use of identity information that you might provide to other InCommon Federation participants?

Information must be used only for the purpose it has been provided. It must not be aggregated or provided to any third party without Cornell's permission.                         

5.2     What policies govern the use of information that you might release to other InCommon Federation participants? For example, is some information subject to FERPA or HIPAA restrictions?

Policy 4.4 Access to Cornell Alumni Affairs Information, Policy 4.5 Access to Student Information, Policy 4.12 Data Stewardship and Custodianship; for information about Cornell Universityπs IT policies, please see: http://www.cit.cornell.edu/oit/policy/drafts/     

5.3     If a Resource Provider, what use do you make of identity information that you receive in addition to basic access control decisions?

Cornell is not currently a Resource Provider.

6.     Technical Standards, Versions and Interoperability

Identify the version of Internet2 Shibboleth code release that you are using or, if not using the standard Shibboleth code, what version(s) of the SAML and SOAP and any other relevant standards you have implemented for this purpose.

Shibboleth 1.1                                                                                                                             

                                                                                                                                                    

7.     Other Considerations

Are there any other considerations or information that you wish to make known to other InCommon Federation participants with whom you might interoperate, e.g., concern about the use of clear text passwords?

                                                                                                                                                    

                                                                                                                                                    

 

Additional Notes and Details on the Operational Practices Questions

 

As a community of organizations willing to manage cooperatively, and in many cases without formal contracts, access to on-line resources, it is essential that each participant have a good understanding of the identity and resource management practices implemented by other participants. The purpose of the questions above is to establish a base level of common understanding by means of posting this information for other participants to consider.

 

In answering these questions, please consider what you would want to know about your own operations if you were another participant deciding what level of trust to place in interactions with your on-line systems. For example:

• What would you need to know about a Credential Provider in order to make an informed decision whether to accept their assertions to manage access to your on-line resources or applications?
• What would you need to know about a Resource Provider in order to feel confident providing it information that it might not otherwise be able to have?

It might also help to consider how identity management systems within a single institution could be used among its organizations.

• What might your central campus IT organization, as a Resource Provider, ask of a peer campus Credential Provider (e.g. Computer Science Department, central Library, or Medical Center) in order to decide whether to accept its identity assertions for access to resources that the IT organization controls?
• What might campus departments ask about the central campus Identity Management system if they wanted to leverage it for use with its own applications?

The numbered paragraphs below provide additional background to the numbered questions in the main part of this document.

[1]    Other InCommon participants may wish to contact this person or office with further questions about the information you have provided or if they wish to establish a more formal relationship with your organization regarding resource sharing.

 

[2]    It is important for a Resource Provider to have some idea of the community whose identities you may represent. This is particularly true for assertions such as the eduPerson "Member of Community" or "student," etc. A typical definition might be "Faculty, staff, and active students" but it might also include alumni, prospective students, temporary employees, visiting scholars, etc. In addition, there may be formal or informal mechanisms for making exceptions to this definition, e.g. to accommodate a former student still finishing a thesis or an unpaid volunteer.

 

[2.1] This question asks to whom you, as a Credential Provider, will provide electronic credentials. This is typically broadly defined so that the organization can accommodate a wide variety of applications locally. The reason this question is important is to distinguish between the set of people who might have a credential that you issue and the set of people who fall within your definition of "Member of Community" for the purpose of InCommon assertions.

 

[2.2] The assertion of "Member of Community" is often good enough for deciding whether to grant access to basic on-line resources, e.g. library-like materials or web sites. InCommon encourages participants to use this assertion only for "Faculty, Staff, and active Students" but some organizations may have need to define this differently. InCommon Resource Providers need to know if this is so.

 

[3]    For example, if there is a campus recognized office of record that issues such electronic credentials and that office makes use of strong, reliable technology and good database management practices, those factors might indicate highly reliable credentials and hence trustworthy identity assertions.

 

[3.1] Many organizations have very informal processes for issuing electronic credentials. For example, one campus does this through their student book store. A Resource Provider may be more willing to accept your assertions to the extent that this process can be seen as authoritative.

 

[3.2] Different technologies carry different inherent risks. For example, a userID and password can be shared or "stolen" rather easily. A PKI credential or SecureID card is much harder to share or steal. For practical reasons, some campuses use one technology for student credentials and another for faculty and staff. In some cases sensitive applications will warrant stronger and/or secondary credentials.

 

[3.3] Sending passwords in "clear text" is a significant risk and all InCommon participants are strongly encouraged to eliminate any such practice. Unfortunately this may be difficult, particularly with legacy applications. For example, gaining access to your CorporateTime calendar via a wireless data connection while you are attending a conference might reveal your password to many others at that conference. If this is also you campus credential password, it could be used by another person to impersonate you to InCommon participants.

 

[3.4] "Single sign-on" (SSO) is a method that allows a user to unlock their electronic identity credential and then use it for access to a variety of resources and applications for some period of time. This avoids people having to remember many different identifiers and passwords or to continually log into and out of systems. However, it also weakens the link between an electronic identity and the actual person to whom it refers because someone else might be able to use the same computer and assume the former userπs identity. If there is no limit on the duration of a SSO session, an InCommon Federation Resource Provider may be concerned about the validity of any identity assertions you might make. Therefore it is important to ask about your use of SSO technologies.

 

[3.5] In some identity management systems, primary identifiers for people might be reused, particularly if they contain common names, e.g. Jim Smith@MYU.edu. This can create ambiguity if a Resource Provider requires this primary identifier to manage access to resources for that person.

 

[3.6] The database that holds information about a person is at least as critical as the identity credentials that provide the links to records in that database. Appropriate security for the database, management and audit trails of changes made to that database, and management of access to that database information are important.

 

[3.7] Many organizations will make available to anyone certain, limited "public information." Other information may be given only to internal organization users or applications, or may require permission from the subject under FERPA or HIPAA rules. A Resource Provider may need to know what information you are willing to make available as "public information" and what rules might apply to other information that you might release.

 

[3.8] In order to help a Resource Provider assess how reliable your identity assertions may be, it is helpful to know what use you make of them. The assumption here is that you are or will use the same Identity Management System for your own applications as you are using for InCommon purposes.

 

[4]    Agreement on the definition of attributes and their availability is critical to interoperability among Federation participants. The two basic schema that are required to be implemented by InCommon participants are eduOrg and eduPerson[4]. In addition, some assertions can be derived from elements of these schema, e.g. "Member of Community" might be asserted "if and only if eduPerson affiliation includes at least one the values Faculty, Staff, or Student" (see also item 2.2 above).

 

[4.1] Your answer to this question indicates the degree of confidence you have in the accuracy of your identity assertions.

 

[5]    InCommon Credential Providers are strongly encouraged to post on their web site the privacy and information security policies that govern their identity management system.

 

[5.1] Even "public information" may be constrained in how it can be used. For example, creating a marketing email list by "harvesting" email addresses from a campus directory web site may be considered illicit use of that information. Please indicate what restrictions you place on information you make available to others.

 

[5.2] Please indicate what legal or other external constraints there may be on information you make available to others.

 

[5.3] As a Resource Provider, please declare what use(s) you would make of information you receive.

 

[6]    Most InCommon participants will use Internet2 Shibboleth technology but this is not required. It may be important for other participants to understand whether you are using other implementations of the technology standards.

 

[7]    As a Credential Provider, you may wish to place constraints on the kinds of applications that may make use of your assertions. As Resource Provider, you may wish to make a statement about how User credentials must be managed. This question is completely open ended and for your use.