INCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES FOR RUTGERS UNIVERSITY
InCommon requires Participants to make available to all other Participants answers to the questions below. This document contains information for Rutgers University.
1. Federation Participant Information
1.1 The InCommon Participant Operational Practices information below is for:
InCommon Participant organization name Rutgers University
The information below is accurate as of this date March 2, 2018
1.2 Identity Management and/or Privacy information
Additional information about the Participant’s identity management practices and/or privacy policy regarding personal information can be found online at the following location(s).
The primary policy affecting privacy is the Acceptable Use Policy for Computing and Information Technology Resources and the guidelines referenced on that page. More specific guidance on privacy and confidentiality for personal information is available at the Non-Public Personal Information policy page. Information specific to students is available from the Office of Student Affairs Compliance.
1.3 Contact information
The following person or office can answer questions about the Participant’s identity management system or resource access management policy or practice.
Name Identity Access Management Services
Title or role Identity Access Management Services
Email address idp_operations@email.rutgers.edu
Phone +1 848-445-4646 FAX +1 732-445-5493
2. Identity Provider Information
The most critical responsibility that an Identity Provider 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.
Community
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?
The underlying Identity PersonRegistry maintains data on quite a variety of people who have some association with Rutgers. This includes faculty, staff, students, alumni, students of special programs of various types, and guests such as collaborators at other institutions. NetIDs and other identifiers are auto-generated for these populations upon provisioning from source systems (HR, SIS, and Guests). Person Registry, in real time, provisions identifiers and roles to the downstream systems including the IdM enterprise LDAP. The long-term direction at Rutgers is to separate authentication from authorization, because different applications have different sets of valid users. Thus we will issue NetIDs to, and have passwords for, a fairly wide variety of people. But applications will only permit a subset that are authorized to use that application. In particular, key administrative applications have additional authorization requirements.
There is a “default” authorization, which corresponds to people who are authorized to use “generic” University services such as email and the public labs. Shibboleth is currently configured to use this authorization. This includes current faculty, staff and students, entering students who have accepted admission, students who have graduated for a year after graduation, visiting faculty, and others whom departmental chairs or equivalent certify as working closely enough with Rutgers that it is legitimate for them to use Rutgers IT resources.
The concept of “student” is a remarkably flexible one at modern Universities. The student role in LDAP (and the corresponding value of “student” for affiliation) uses a fairly strict definition: full-time students, and Continuous Education students who have a similar affiliation. Thus it does not include members of various ad hoc and short-term programs. It does include summer school students who have enrolled and paid the full tuition, but only during the summer term.
If you do not wish to see the full variety of people, we recommend that you check the eduPersonScopedAffiliation attribute.
Because faculty, staff, and students are tied to administrative data, it is nearly impossible to create exceptions for these roles. Exceptional cases are handled by “guest” roles. If a Shibboleth application checks for the “member” affiliation type, it will not see any such exceptions.
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?
Everyone identified by the IdP participates in our primary mission in some way. However, it is probably safest to use people with the affiliation type “member”. This includes faculty, staff and students, including incoming students who have accepted admission. It does not include alumni nor visiting faculty and other non-Rutgers employees who have been authorized to use Rutgers IT resources.
We have the following definitions for members:
| employeeType | eduPersonAffiliation |
| FACULTY | faculty, employee, member |
| EMERITUS | member |
| STAFF | staff, employee, member |
| RETIREE | affiliate |
| ADMIT COMING | student, member |
| STUDENT | student, member |
| ALUMNI | alum |
| STUDENT WORKER | staff (but not primary), employee, member |
| SUMMER STUDENT | student, member |
| WINTER STUDENT | student, member |
| GUEST | affiliate |
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.”
Identity management is based on an Identity Management Person Registry, which gets its data from the student records database for students and payroll for faculty and staff.
The primary authorities are the Registrar’s Office for students and University HR for faculty and staff.
For people other than current and former faculty and staff and students, a dean, department chair or equivalent must file an annual statement indicating that they are authorized to use Rutgers resources. Identities for these people are maintained directly in the IdM PersonRegistry and provisioned to downstream systems including People Data Service and LDAP.
For faculty, staff, guests, and on-campus students, the IdM PersonRegistry applies Identity matching using personal data including SSN, birth date, and name before creating identifiers and assigning roles.
NetID is auto-generated at the time of creating the record in the PersonRegistry among other Identifiers, and roles are derived from the source systems. NetID must be activated by the user before it can be used to authenticate to services. The NetID activation process involves setting up a password. For faculty, staff, and guests, a welcome letter is sent upon provisioning their Identity accounts with instructions to activate the NetID. For students, a link to the NetID activation page is provided in the enrollment documents that are mailed to the students. Orientation sessions for both students and employees are also used to reinforce the NetID activation process.
Users of administrative applications have an additional check. They are required to accept the data access agreement online. The process for this serves as verification that their credentials were properly issued.
Password recovery can be done via a self-service tool within the NetID management application. Users can recover their password using the secret questions and answers. If they are unable to use the secret questions and answers, users can contact the Help Desk, which performs identity proofing, and subsequently provides activation key to the users who can use the self-service tool to recover the password.
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?
Our primary authentication is via Kerberos. While we are capable of authenticating via one-time cards, any authentication done via Shibboleth will use Kerberos (via CAS).
We also use 2-factor authentication via DUO security. The CAS DUO-plugin is used to pass on the second step-up authentication to DUO.
Very few non-web applications talk directly to Kerberos. Most use LDAP or the CAS single sign-on system, which then talk to Kerberos to check passwords. Currently, our Shibboleth Identity Provider uses CAS to check passwords, and LDAP to look up information about people.
One-time cards are issued by the Information Protection and Security group, which requires a visit in person. A one-time card will be issued whenever the person is authorized to use an application that requires one-time authentication, using a request that is approved by the office in charge of the application.
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:
It has been policy for a number of years that the primary Kerberos password may not be sent in the clear. The Rutgers Information Protection and Security office follows up on any indications that this policy is being violated.
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.
We are using the CAS single sign-on system with the Shibboleth Identity Provider. The CAS SSO TGT can last up to 8 hours.
For Shibboleth-enabled services, CAS issues service tickets (ST) that do not generate a long-lived session. All session management must be handled at the application level. As such, user-initiated session termination is also an application level consideration and is typically invoked by the user logging out of the application (if the service provider supports the Single Log Out functionality).
Public access sites that are under central control have users log in and out. Their software is set to create a clean environment at each login. Shibboleth session would not persist across logins.
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?
Our normal identifier for IT services is the NetID. While we discourage changing NetIDs, it is possible for a user to request a new NetID, and we will eventually comply. We do not normally recycle old NetIDs, but it has happened in a very small number of cases such as the integration of UMDNJ with Rutgers. To address these rare scenarios, an internal identifier is also used with the backend systems which is immutable and is never recycled.
eduPersonPrincipalName is based on the NetID.
eduPersonTargetedID is computed by Shibboleth.
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?
Key data such as names and roles are maintained by central offices: the Registrar for students and University HR for faculty and staff. For users who are not students or employees, such as guests, information is updated manually as part of the process of annual review.
Users can update some information, such as official business/campus email address, which may be released via Shibboleth to approved service providers.
2.9 What information in this database is considered “public information” and would be provided to any interested party?
Note that students may choose to hide any of this information or their entire entry. Faculty and staff may choose to hide their email address from getting exposed via the online directory when accessed externally, and faculty and staff may also hide their entire entry with highest disclosure setting. Even if it appears on the following list, information that the user has hidden is not considered public.
For all: Given Name, Surname, Common Name, Email.
For faculty and staff only: Telephone, FAX, Postal address, Title, Campus, Organizational Unit, Location, Department, Organization code (a coded form of department)
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.
Currently our electronic credentials are used for any web-based applications. This includes web applications hosted locally on-premise or on the cloud.
Attribute Assertions
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?
Privacy Policy
Federation Participants must respect the legal and organizational privacy constraints on attribute information provided by other Participants and use it only for its intended purposes.
2.12 What restrictions do you place on the use of attribute information that you might provide to other Federation participants?
They would be expected to abide by FERPA rules for student information. That would effectively rule out release of any personally identifiable information about students, since customers of Shibboleth wouldn’t know which students have hidden their information. We are unlikely to release any non-public information about faculty and staff, or any personal information about students, without a specific agreement about how it will be used. Any request for student data is always first reviewed and approved by the University Registrar or the Human Resources data owners.
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?
Some identity management data is subject to FERPA. However, we are unlikely to release any non-public information about faculty and staff, or any personal information about students, whether controlled by FERPA or not, without a specific agreement about how it will be used. Any request for student data is always first reviewed and approved by the University Registrar or the Human Resources data owners.
3. Service Provider Information
Service Providers are trusted to ask for only the information necessary to make an appropriate access control decision, and to not misuse information provided to them by Identity Providers. Service Providers must describe the basis on which access to resources is managed and their practices with respect to attribute information they receive from other Participants.
Rutgers has currently registered one service provider (Hyrax) with InCommon. Our other current service providers are intended for use by Identity Providers from Rutgers.
3.1 What attribute information about an individual do you require in order to manage access to resources you make available to other Participants? Describe separately for each resource ProviderID that you have registered.
Hyrax currently receives email addresses, first/last names, ePPN, campus postal address, and other semi-opaque identifiers.
3.2 What use do you make of attribute information that you receive in addition to basic access control decisions? For example, do you aggregate session access records or records of specific information accessed based on attribute information, or make attribute information available to partner organizations, etc.?
Yes. The application is used to let people register research data. People searching for data want to know who supplied it, what institution they are affiliated with, what their role is, etc. Most of this information is supplied by the participant as they register, but some fields are repopulated with attributes from Shibboleth.
3.3 What human and technical controls are in place on access to and use of attribute information that might refer to only one specific person (i.e., personally identifiable information)? For example, is this information encrypted?
The information is not encrypted, because the whole point is to make it available to people searching for data that the participant has registered. The participant can edit the data, but our administrative staff would have access to the original attributes.
3.4 Describe the human and technical controls that are in place on the management of super-user and other privileged accounts that might have the authority to grant access to personally identifiable information?
This is a research system. While it’s intended to result in a system that’s widely usable, in fact the only people we expect to use the system are participants in the grant. The data is general information that you’d normally expect to find in a University directory. So controls aren’t extensive. The PI determines who can access the data.
3.5 If personally identifiable information is compromised, what actions do you take to notify potentially affected individuals?
We would notify them by email.
4. Other Information
4.1 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 3.2.1 for the Identity Provider.
4.2 Other Considerations
Are there any other considerations or information that you wish to make known to other Federation participants with whom you might interoperate? For example, are there concerns about the use of clear text passwords or responsibilities in case of a security breach involving identity information you may have provided?
Non-public personal information should be handled using the best standard educational security and privacy practices. This includes encryption during transmission and availability only to authorized applications. However, the primary requirement is hard to codify: we expect applications and the systems on which they are run to follow best security practices throughout.
Notification of security or privacy problems should be sent to abuse@rutgers.edu. This is the public email address of the Information Protection and Security group.