UC Berkeley identity management (IdM) business needs and technology approaches

Authentication

• Reliable, secure, centrally managed system which allows users to prove their identity before accessing systems and services.

• Kerberos — authenticates based on identity credential (CalNet ID) and passphrase (stored in the authoritative MIT Kerberos environment and synchronized with Active Directory).

• Authentication Web Server (AWS) is a homegrown resource which provides web-proxied Kerberos authentication. The AWS is aging and does not support desired authentication features such as single sign-on.

• Central Authentication Service (CAS), which will be replacing the AWS, has been in production since July 2007. Applications using AWS for authentication should convert to CAS by December 31, 2008.

• See below for information on multifactor authentication.

Authorization

• Ensure that only those people with appropriate permission are granted access to resources.

• Ideally provide centrally managed systems with user-friendly tools for delegating authorization administration (e.g., assigning roles and associated permissions).

• Campus CalNet directory — LDAP.
  • Highly available.
  • Contains coarse-grained attributes about people's campus affiliations (student, faculty, staff).
  • Allows privileged binds for web applications to gather specific information which may be needed to determine authorization (such as SID, employee ID, etc.).
  • A significant hardware and platform migration for the directory is planned for this year to improve performance and ensure the directory can accommodate an increasing population.
  • Alumni will be added to the directory this spring and the CalNet team hopes to add pre-SIRed students before the end of 2008.

• Departmental databases (against which CalNet directory data is compared).
  • These databases typically contain the fine-grained data about users that determine access for a specific application.

• The campus has purchased a product called Sun Identity Manager (SIM) and hired a consulting group to conduct a pilot setup during the spring 2008 semester. This product is an enterprise-level identity management system which connects multiple campus identity sources together (via adapters) and provides user interfaces and tools for centralized management and delegated administration of account provisioning, deprovisioning, and managing and assigning roles. IST staff are exploring target applications for SIM that will allow us to develop experience with the tools, evaluate the resources necessary to maintain and expand the service, and determine longer-term goals for the SIM pilot project.

Secure access to sensitive data

• Set a higher standard for accessing data with higher requirements for confidentiality and integrity.

• Ensure that access to such systems is deprovisioned promptly when people leave or change roles.

• LDAP accounts are "deprovisioned" when students/faculty/staff leave the University.

• RSA SecureID tokens are required to access some IST network devices and database servers.

• Sun Identity Manager (SIM) could improve the provisioning and deprovisioning process by allowing changes made centrally to propagate more quickly to associated systems.

• CAS second-level authentication — by early summer, CalNet plans to introduce the CalNetKey, a 6-character or longer key that users will enter via a keypad displayed on the monitor. Those applications wanting or requiring additional security could require this second level of authentication.

• Multifactor authentication, like smart cards and biometric data, are commonly used in industry to provide greater protection for sensitive data. These tools are very costly to implement, however, as they require central systems and peripheral devices. At this point, IST has no active plans to broadly implement multifactor authentication on campus.

Real time data integration

• Ensure that students, faculty, and staff can access resources quickly when they join the campus or change roles.

• Integrate data from source systems (HRMS, SIS) as close to real time as possible.

• Daily batch feeds from systems of record (HRMS, SIS) update the campus directory (LDAP).

• Data from these sources is synchronized to detect matches and create a single UID for each user.

• A limited amount of user account data is synchronized in real time from CalNet to Active Directory and CalAgenda via FioranoMQ messaging (JMS).

• Over the next year, the CalNet team would like to expand the real time JMS synchronization between HRMS/SIS and CalNet, and to notify campus applications quickly of directory changes. By the end of 2008, the CalNet team would like to allow students to upgrade to "friendly" CalNet IDs, as opposed to requiring that they use their FERPA-protected SID as their CalNet ID. Real time updates via a messaging layer will ensure that campus applications are notified immediately when students (and others) change their CalNet ID.

Convenient access to resources

• Reduce the number of username/password combinations.

• Reduce the number of times users must reauthenticate.

• Last year, campus chose an open-source product, Central Authentication Service (CAS), as the replacement for AWS. CAS provides single sign-on for web applications (more than 50 applications have been registered to use CAS since July 2007).

• Synchronization of MIT Kerberos principal string (CalNet ID) and passphrase with Active Directory.

• A proposal to extend CalNet authentication to CalMail, the most widely used campus application, was denied by the CISPC last year due to security concerns (given that email clients often store login credentials on mobile devices). As web applications which require greater security adopt CAS second-level authentication, extending CalNet authentication to CalMail can be reconsidered as a viable option for providing user convenience and reducing redundancy (CalMail would no longer manage passwords).

Policy compliance, audit, and reporting

• Ability to generate reports quickly that provide detailed documentation about access permissions — which staff had access to what applications and when access was granted/revoked.

• Central data only reports on global attributes such as when a person becomes a member of the campus community and when he or she leaves.

• No central tools are available for reporting on access permissions for specific systems or applications. Data must be retrieved from local application logs and records.

• One of Sun Identity Manager's primary selling points is its ability to centralize reporting for detailed information about access to specific applications.

Ability to use campus single sign-on (SSO) to access third-party applications

• Provide easy-to-use authentication tools for campus members who need to access online resources from trusted third parties (federated identity management).

• Ensure that UC Berkeley can participate in systemwide business support systems that leverage federated identity management (such as Learning Management Systems for online ethics and sexual harassment training).

• Participation in higher education federations — UC Berkeley joined the InCommon Federation in January 2008 and is a registered InCommon Identity Provider.

• InCommon uses Shibboleth, a technology based on Security Assertion Markup Language (SAML) to share agreed-upon sets of attributes between identity providers and service providers.

• UC Berkeley should be a member of UCTrust by early spring 2008.

• As an InCommon Identity Provider, UC Berkeley is set to allow campus members to authenticate via Shibboleth to the UCOP-sponsored Learning Management Systems once the software vendor has a production Service Provider instance established (estimated April 2008).

• UCOP is working to establish a process by which campus members can use Shibboleth authentication for the systemwide At Your Service Online (AYSO) application.