CalNet Terms of Services

Since CAS (Central Authentication Service) is a solution for single sign-on (SSO), applications that implement CAS must take security seriously. Once a browser logs into CAS, that browser can enter new applications without providing CalNet credentials again, which increases the risk of people inadvertently leaving themselves logged in to multiple applications, especially at shared workstations and public kiosks. If your department supports public kiosks, please see campus Kiosk Guidelines.

The CalNet Team, in consultation with campus developers, developed the following terms of service for using CAS. These terms of service have been reviewed and endorsed by the campus Information Security Office (ISO).

All applications which are used by the general campus population and use CalNet's Central Authentication Service must adhere to these standards. If the CalNet team identifies applications which are out of compliance with these standards, we will notify application owners and allow 2 months for them to come into compliance. Failure to comply with these terms may result in removal of the application from the CAS service registry.

1. Applications/Websites Must Register to Use CAS

In order for an application or any website URL to be protected by CAS Authentication, it must be registered. Before you can use CAS in test or production, you need to submit an SSO Registration.

2. Login/Logout Standards

• Applications must have a local session, i.e., once a user has authenticated with CAS and has presented an application with a service ticket, the application should create a local session so that each new request to the application does not go against CAS. CAS is for authentication only; it is not a security framework for a web application. Please see the Web Flow Diagram for an in-depth view of how this should work. The exception to this is if a user is requesting a static resource that has been protected by some CASified code. In this case, there is no "application" and no means of keeping track of a user's state. In this instance, it is ok for the application to direct the user to CAS for each request for the resource.
• Applications must use "session cookies" (if cookies are used) for local session state. A "session cookie" is a cookie that gets removed from the browser when the browser is closed or stops running.
• The application must present a "logout" option which, when exercised, logs the user out of CAS completely.
• The logout button should be labeled "CalNet Logout" to help the user understand that clicking the button will log him/her out of CAS, not just the local application.
• Application owners should implement global logout wherever possible.
• Applications that do not support global logout should set inactivity timeouts for local application sessions to no more than 30 minutes.
• Applications that provide access to data with high confidentiality requirements should set a shorter inactivity timeout (maximum 15 minutes).

Berkeley respects individual privacy and abides by UC policy and state and federal laws that protect individual privacy. More information on campus IT policy is available on the IT Policy website.

CalNet Identity Data contains person information from Student Information Systems, UCPath (Human Resources system), Alumni systems, Sponsored Guest system, and the public-facing campus directory (directory.berkeley.edu). Details regarding the release policy for CalNet Identity Data are available in the CalNet Identity Data Privacy and Directory Visibility Matrix.

• Information entered through the Campus Directory Update Tool may be displayed publicly in the campus directory. See the CalNet Identity Data Privacy and Directory Visibility Matrix for details;
• Some information is always available to campus applications and departments via secure data sharing processes. This data is not available to off-campus entities;
• Some information is always private and is not released to campus applications or departments without approval from campus data owners (Ex: Office of the Registrar for student data and the Office of Human Resources for employee and affiliate data).

Employees: Information about who works for the University is considered public information. Although employees can choose not to include their personal data in the public-facing campus directory, this data is still available to campus applications and departments via CalNet Identity Data. Many units and departments require employees to have their directory information available in the authenticated (non-public) directory.

Students: Student names are displayed in the public campus directory, and they may opt to display their email address as well. Students may choose not to include their name in the public-facing campus directory, but this data is still available to campus applications and departments. Students can request to make their records confidential via the Registrar's office. This affects not only data sent to campus departments and the public-facing campus directory listing, but all their school records as well. The Registrar requires a strong reason before they will grant confidential status; contact them to find out more.

Other private attributes included in the Campus Directory are listed in CalNet's LDAP documentation.

• You will choose your username, or CalNet ID, when creating your CalNet account. You must know your campus ID number, i.e. Student ID, UCPath ID, or Alumni ID, to create an account.
• You must abide by CalNet ID and Passphrase requirements.
• You can only use CalNet self-service tools if you have an accurate Recovery Email Address on your CalNet account.
• A CalNet passphrase must not be revealed to any other person for any reason. CalNet users will be held responsible if inappropriate activities are conducted under the authority of their CalNet ID by another person with whom they have intentionally shared their CalNet passphrase.
• Users must abide by policies governing the use of Berkeley Campus computers and the network. (See Campus IT policies).
• Users must follow acceptable use policies for UC Berkeley Information Technology Resources. (See Acceptable Use Policies).
• Campus services that are accessed online using CalNet may have additional conditions for use. CalNet users are required to familiarize themselves with and comply with these conditions.
• See Manage My CalNet Account for additional information and instructions.

Your CalNet ID is your online identity at UC Berkeley. It will be used for system access log-ins and authentication, and if you are eligible for campus email service, it will be the handle of your campus email address. For example, the CalNet ID oski.bear becomes oski.bear@berkeley.edu as an email address.

Recommendations:

• keep it short -- you will be typing it often
• keep it professional -- professors and future employers will see your CalNet ID in your campus email address
• make it yours -- since your CalNet ID serves as your username in many campus collaboration systems, consider including all or part of your name
• keep it real -- you may use a pseudonym for privacy or other reasons, so long as the pseudonym does not constitute a false identity
• We recommend that CalNet IDs do not include identifying data other than your name, e.g., birthdate. For example, Oski1225 for a birthdate of December 25 is not recommended.

CalNet ID Requirements:

CalNet IDs must meet the following requirements:

1. Must be 2 or more characters in length (maximum 19)
2. Must contain at least 1 lowercase English letter, but no uppercase letters
3. Must not contain your Student, Employee, or Affiliate ID, or your passphrase
4. Must not start with cads followed by a number
5. Must not start with pvt-
6. Must not start with svc-
7. Must not start with app-
8. Must not start with app_
9. Must not start with guest-
10. Must not start with spa-
11. Must not start with a period (.)
12. Must not end with a period (.)
13. Must not start with a hyphen (-)
14. Must not end with a hyphen (-)
15. Must not contain two or more periods in a row (..)
16. Only the following characters are allowed:
    1. Lowercase letters (a through z)
    2. Numbers (0 through 9)
    3. Periods (.)
    4. Underscores (_)
    5. Hyphens (-)
17. Must not start with uid or contain uid followed by a number

CalNet offers two passphrase options, the regular passphrase and the long passphrase. You cannot reuse a passphrase; the system will reject reused passphrases. Your passphrase should not contain common passphrases, a single dictionary word in any language by itself or preceded and/or followed by any other single character (secret1, 1secret), sequences (“123”, “DEF”) in any order, or repeating characters (“444”, “ooo”).

Regular CalNet Passphrase Requirements:

Your passphrase must:

• Be at least 12 characters long (maximum 255) and may include spaces
• Contain at least three of the four following character groups:
  • Uppercase letters (A through Z)
  • Lowercase letters (a through z)
  • Numbers (0 through 9)
  • Symbols/special characters (!, $, #, or %, etc.)

Your passphrase must NOT:

• Contain your first name, middle, or last name(s)
• Contain your CalNet ID
• Contain leading or trailing spaces

Long CalNet Passphrase Requirements:

• Your long passphrase must be at least 20 characters long (maximum 255) and may include spaces
• Your passphrase must NOT contain your first name, middle, or last name(s) or your CalNet ID
• Cannot contain leading or trailing spaces
• There are no other requirements

UC Berkeley Special Purpose Accounts (SPAs) are restricted to furthering academic, research, administrative, or public service activities only. SPAs, their contents/data, and the associated email account are owned by UC Berkeley and the department of the employee who created the SPA at the time it was created.

If the use of a SPA account is out of compliance with UC and UC Berkeley policies, including the UC Berkeley Acceptable Use Policy, or the terms of any service accessed by this account, it will be disabled immediately.

Department managers have the authority to modify membership and/or disable a SPA and/or manage the content of SPAs owned by their department.

Please note that if there are no active employees in the SPAs direct membership, the associated email account will be notified and then all other direct members removed a week later. If you receive notice that a SPA no longer has direct members, the director or manager of the department owns it must contact calnet@berkeley.edu and request an employee be added to the SPA group.

Accessing a SPA owned by a different department

Users requesting access to a SPA owned by a different department must coordinate approval through the owning department’s leadership. CalNet can identify what department owns a SPA, but cannot disclose its current membership. To gain access, a user should contact the SPA directly or reach out to the owning department’s Manager or Director, who must then email calnet-admin@berkeley.edu with their title and the specific access request. For additional assistance or privacy concerns, contact privacyoffice@berkeley.edu.

Transferring a SPA to a different department

Department Managers and Directors have the authority to transfer ownership of a Special Purpose Account (SPA) between departments. To initiate a transfer, the Manager must email calnet-admin@berkeley.edu with the names and titles of the responsible parties from both the original and new departments, the SPA name, and the specific Department org code (e.g., KOLIB) for both the current and receiving units.

I understand that this/these sponsored guest account(s) are to be used only for furthering academic, research, administrative, or public service activities at the University. If it comes to my attention that the sponsored guest(s) failed to comply with UC and UC Berkeley policies, including the UC Berkeley Acceptable Use Policy and the terms of any service accessed by the sponsored guest, I will expire the guest account(s) or contact calnet@berkeley.edu to do so immediately.

CalNet resources must be developed so as to comply with all applicable laws and policies governing the University of California, Berkeley. Please review the comprehensive IT Policy Library for additional information and clarity.

Before you provide any service to your users, you must properly verify their identification. Similarly, CalNet expects and requires its campus partners to ensure that proper identity verification is performed before people are entered into a system that will result in them getting CalNet credentials. Below are two methods of identity verification:

Face-to-Face Requirements

The UC Trust policy states: "A government or University issued ID with a picture must be presented to and verified by an officer of the credential provider as belonging to the registrant."

Simply put, you must look at a user’s Federal or State-issued photo ID, such as a driver license, to confirm the user’s identity in person before providing the person information from their record or performing an action. Your doing so ensures that UC Berkeley complies with UC Trust standards.

So please remember: NEVER perform an account action, provide account information to a user, or enter a new user into a system that results in CalNet credentials before you have verified the user's identity! The best way to verify a user’s identity is to check the federal or state-issued ID in person.

Remote Identification Requirements

The UC Trust federation has specific guidelines for establishing "face-to-face" level of assurance when a user cannot be physically present. These requirements are outlined in the Identity Verification Guideline, which is only available to authorized employees on campus and users of the CalNet Admin Tool. Again, NEVER perform an account action, provide account information to a user, or enter a new user into a system that results in CalNet credentials before you have properly verified the user's identity!

Identity Federations

UC Berkeley is a member of two identity federations: InCommon and UCTrust. InCommon is the largest federation of higher education institutions in the United States. UCTrust is a federation for the UC system that is managed through UC Office of the President (UCOP).

In order to belong to InCommon and UCTrust federations, UC Berkeley has to comply with very high standards, including requirements for how user identity is verified, how authentication credentials are asserted, and how credentials are handled by service providers.

Identity federations consist of "identity providers" (such as CalNet) and "service providers" (such as bConnected or CalTime). Service providers trust the identity information provided by CalNet, and CalNet must trust that service providers adequately protect that information.

Shibboleth is the software used by InCommon and UCTrust to manage the communication between CalNet and service providers, including authentication requests.

Privacy and Confidentiality:

Each CalNet Directory attribute has an owner whose permission must be obtained before an application may use that data. The LDAP Attributes Details identifies each owner.

• Individuals who are granted privileged access (bind) must comply with any usage restrictions relevant to the types of data accessed.
• In cases where data may not be further distributed or republished, the application must display informational instructions to the users.
• CalNet's usage restrictions apply to downstream or secondary uses.
• Use of LDAP data must respect user privacy flags.

Security Cautions and Guidelines:

Ensure that application servers are configured very securely, especially if they will be handling confidential or sensitive information. MSSEI compliance is required. For example:

• Do not run unnecessary services.
• Maintain the latest available system software updates.
• Ensure the machine is in a secure physical location.
• Limit direct login access to the machine.
• Register your system with Socreg

If you are using CAS, ensure that you are in compliance with the CAS Terms of Service (below).

The use of encryption is required to prevent unauthorized access to restricted data during transmission.
 

Data output to user workstations may be vulnerable to unauthorized disclosure because, e.g.:

• Normal web browser access doesn't provide for a way to "log off" an application securely other than closing down the browser completely.
• Workstations may be left unattended at times.
• Multiple users may share workstations.

When developing applications that will display confidential or sensitive information, minimize data access vulnerability at user access interfaces, by using measures such as:

• Incorporate "time-out" features of appropriate duration.
• Display warning messages to users regarding sensitive or confidential data.
• Some information may be so sensitive that even one view of it by an unauthorized party can cause substantial damage. In such cases, consideration should be given to not making the information available via the Web.

CalNet Test Environment

The CalNet team supports a test environment which includes all major components of our central authentication and authorization systems, including CAS, LDAP, Shibboleth, Active Directory, and our Identity Management System. We consider this test environment a production service for campus developers integrating applications with our identity management infrastructure.

Developers are encouraged to test authentication and authorization using the CalNet test environment prior to deploying applications.

Test IDs

The CalNet team provides rSPA for testing in both test and production LDAP. Please see CalNet rSPA Test Accounts for details and instructions for obtaining access.

Testing against CAS

During the CAS registration process, developers are asked to indicate service URLs for their environments. These URLs are registered in both the CAS qa and prod tiers (auth-test.b.e and auth.b.e).

Test LDAP

If your application conducts authorization queries against LDAP, please use ldap-test to validate your application and to perform any load testing (see below). Normal queries by your dev/qa systems can be performed against the prod tier (ldap.b.e).

Test Shibboleth

If you are using Shibboleth for authentication, please point all authentication requests to shib-test.berkeley.edu.

Test System Modifications

At times, the CalNet team needs to modify the test environment to upgrade operating systems and software, test new system configurations for improved performance, or implement new authentication and authorization components.

To ensure smooth rollout of system changes, the CalNet team will notify CalNet developers in advance of such modifications and request the assistance of CalNet developers in testing changes before they are migrated to our production environment.

Load Testing

At times, the CalNet team and other campus departments may need to conduct load testing against the CalNet test environment. Any developer planning load testing that includes a high volume of requests to CalNet systems (CAS, LDAP, Shibboleth) should send a notice to the CalNet team, calnet-admin@berkeley.edu with at least 2 weeks advance notice. The CalNet team will evaluate impact and send notice to the larger CalNet developer community as necessary.

Applications May Not Proxy CalNet Authentication Without an Approved Information Security Exception

"Proxied authentication" is when an application requests a user’s CalNet credentials and passes them to CalNet, instead of CalNet receiving the credentials first. This practice is prohibited unless you have an approved Information Security Exception.

Proxied authentication is only allowed if there is a very strong business case for it. If you feel this is necessary, please follow the process for submitting an Information Security Policy Exception Request.

Failure to get an approved exception may result in your application losing access to campus network services.