Federation Participant Information
1.1 The InCommon Participant Operational Practices information below is for:
1.2 Identity Management and/or Privacy information
1.3 Contact informationThe following person or office can answer questions about the Participant's identity management system or resource access management policy or practice.
Name: Steve Machuga
2. Identity Provider InformationThe most critical responsibility that an IdentityProvider Participant has to the Federation is to provide trustworthy and accurate identity assertions. It is important for a Service Provider to know how your electronic identity credentials are issued and how reliable the information associated with a given credential (or person) is.
2.1 If you are an Identity 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?
Information about account access is available in our Accounts Policy.
2.2 "Member of Community"is an assertion that might be offered to enable access to resources made available to individuals who participate in the primary mission of the university or organization. For example, this assertion might apply to anyone whose affiliation is "current student, faculty, or staff."
What subset of persons registered in your identity management system would you identify as a "Member of Community" in Shibboleth identity assertions to other InCommon Participants?
Member of community at Wesleyan is defined as accounts affiliated with persons who have an identification number, WesID, in our ERP and a corresponding Active Directory account.
Electronic Identity Credentials
2.3 Please describe in general terms the administrative process used to establish an electronic identity that results in a record for that person being created in your electronic identity database? Please identify the office(s) of record for this purpose. For example, "Registrar's Office for students; HR for faculty and staff."
Undergraduate Students and Graduate Students
Undergraduate first-year and transfer students apply to Wesleyan using the Common Application and QuestBridge Application. Graduate students apply through the Slate on-line graduate admission application. Both Admission Offices process these applications through the Slate Admission system which is a SaaS applications provided and supported by Technolutions (http://technolutions.com/). Once students have matriculated into Wesleyan, they are imported into the Peoplesoft Student System. A search/match routine keying on SSN, birthdate, name and address is run.
There are three possibilities:
- No matching data is found, the student is added to PeopleSoft with a unique Wesleyan ID (WesID).
- There is convincing matching data indicating that student already has a WesID in PeopleSoft, the student information is updated.
- There is some data but not it is not convincing, a human needs to review the evidence and determine if there is an existing WesID or a new WesID needs to be created for this student..
The import process is a joint task performed by the Admission and Registrar’s Office. Undergraduate matriculates average 725 students per year. The Graduate School matriculates approximately 40 students per year.
Continuing Studies and Graduate Liberal Studies Students
Continuing Studies students can apply through a Slate on-line application or they can be granted a provisional acceptance which allows them to take two initial classes. A manual search/match process is run and the applicants are entered into the Peoplesoft Student System.
Faculty and Staff
Faculty and Staff are hired into the University by Academic Affairs and Human Resources respectively. As part of that hiring process, a manual search/match process is run and the new faculty and staff members are entered into PeopleSoft.
The Wesleyan Account Management System (WesAMS)
Once each of these constituents are entered into PeopleSoft, WesAMS uses the WesID to create the accounts appropriate for their relationship (Student, Faculty or Staff) to Wesleyan.
2.4 What technologies are used for your electronic identity credentials (e.g., Kerberos, userID/password, PKI, ...) that are relevant to Federation activities? If more than one type of electronic credential is issued, how is it determined who receives which type? If multiple credentials are linked, how is this managed (e.g., anyone with a Kerberos credential also can acquire a PKI credential) and recorded?
Kerberos and username/password.
2.5 If your electronic identity credentials require the use of a secret password or PIN, and there are 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), please identify who in your organization can discuss with any other Participant concerns that this might raise for them:
Clear text is used often in server->server communication and some legacy systems. The University is working to retire these legacy systems.
2.6 If you support a "single sign-on" (SSO) or similar campus-wide system to allow a single user authentication action to serve multiple applications, and you will make use of this to authenticate people for InCommon Service Providers, please describe the key security aspects of your SSO system including whether session timeouts are enforced by the system, whether user-initiated session termination is supported, and how use with "public access sites" is protected.
Wesleyan uses CAS. There are session timeouts of the ticket granting ticket,TGT. Timeouts vary based on which IP is accessing the system; trusted subnets have a longer timeout than untrusted. Users can go to https://sso.wesleyan.edu/logout to eliminate the CAS session at any time. The session cookie is scoped to just the session.
2.7 Are your primary electronic identifiers for people, such as "net ID," eduPersonPrincipalName, or eduPersonTargetedID 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?
We strive not to change netID however it has been done in cases where specifically requested usually related to change in marital status.
We have discontinued the practice of reusing NetIDs. EduPersonTargetedID is currently created from a unique identifier in Active Directory unrelated to username and is therefore persistent.
Electronic Identity Database
2.8 How is information in your electronic identity database acquired and updated? Are specific offices designated by your administration to perform this function? Are individuals allowed to update their own information on-line?
Undergraduate applicant data is acquired by the Undergraduate Admission Office through the admission processes run by the Common Application and QuestBridge Applications. Graduate applicant data is acquired by the Graduate Student Services Office through a Slate on-line application. Continuing Studies applicant data is acquired by the Continuing Studies Office through a Slate on-line application or a paper application. Faculty and Staff information is acquired by Academic Affairs and Human Resources respectively through our PeopleAdmin recruiting system and personal interviews with the applicants.
Individuals are allowed to update own their information on-line.
2.9 What information in this database is considered "public information" and would be provided to any interested party?
We follow FERPA guidelines as described in the following government document http://www2.ed.gov/policy/gen/guid/fpco/ferpa/index.html . The following line is taken from this document: Schools may disclose, without consent, "directory" information such as a student's name, address, telephone number, date and place of birth, honors and awards, and dates of attendance.
Uses of Your Electronic Identity Credential System
2.10 Please identify typical classes of applications for which your electronic identity credentials are used within your own organization.
We use our electronic identity credentials to access:
- wireless network; shared computers in classrooms, labs and kiosks.
- File Servers
- Containing: Academic, Personnel, Financial and other Administrative Documents
- Web Page Creation
- Web Editor, Blogs etc.
- Institutional Databases
- Student, Human Resources, Financial, Fundraising, Scheduling, Security etc.
Attributes are the information data elements in an attribute assertion you might make to another Federation participant concerning the identity of a person in your identity management system.
2.11 Would you consider your attribute assertions to be reliable enough to:
[x] control access to on-line information databases licensed to your organization?
[x] be used to purchase goods or services for your organization?
[x] enable access to personal information such as student loan status?
2.12 What restrictions do you place on the use of attribute information that you might provide to other Federation participants?
We place advertising and FERPA related restrictions.
2.13 What policies govern the use of attribute information that you might release to other Federation participants? For example, is some information subject to FERPA or HIPAA restrictions?
Wesleyan's privacy statement is available online. This policy encompasses our Identity Management. Wesleyan stores some information that is subject to FERPA regulations; no data in our IdM database is subject to HIPAA.