Attendees

Chet Burgess, UCOP
Jacqueline Craig, UCOP
Gregory Fellin, UCM
Eric Goodman, UCSC
Karl Heins, UCOP
Bruce James, UCOP
Brian Koehmstedt, UCM
Gabriel Lawrence, UCSD
Jim Madden, UCSD
Scott Menter, UCI
Bob Merryman, UCSD
Bob Ono, UCD
Peggy Rogers, UCOP
David Walker, UCOP
Albert Wu, UCLA

Campus Status and Readiness for UCTrust

• UCSD – IAM structure in place for last several years – used to sign on to core systems (BLINK)
  • Many elements in place: registering, permission, prepopulate a list of questions to populate access permissions
  • HR process to verify identity; a few basic questions used to provision accounts; roles set up in HR process – preregistration necessary before they can access the email account that was already set up for them
  • Attribute release policy: targeted at mobile applications – InCommon, UCTrust, campus applications
  • SSN – use only a portion – very few objections
  • All resources use Shibboleth
  • LOA – self-register vs dept security system verified permissions
  • Planning for addition of multi-factor authN – 3 back end systems at hand, all pluggable
• Davis
  • Minimum requirements: consistent.
  • Use Kerberos – widely used for campus core applications, and depts. Are using
  • 2-factor authen for student apps, and advancing (Safeword - Looks like a calculator – replaceable batteries)
  • web-based Kerberos proxy, looking at CAS
  • InCommon attributes – not sure
  • Bob now has IdM responsibility – looking at engagement with Burton, possibly
  • Not sure there is consistency with 9.1.1.2 – verification; issue credentials and passwords – remote password change with a couple of challenge questions
• UCOP (AYSO development)
  • Combined Your Benefits Online and UC 4 yourself: At your service online (AYSO)
  • Testing shibboleth with the new app – UCSD is testing
  • Prerequisite of use requires signing off on UCTrust agreement
  • Hopefully up next month – combined site on 4/24 – may not yet have shib, depending on proof-of-service, sign offs, etc. – should be close
  • Initial login requires response to a set of questions and option to continue using secondary requests
• Merced
  • Account provisioning: staff/faculty account creation: IdM allows for MSO’s to enter general information – generates a temporary account later matched by PPS: UCM ID and password created. Or PPS info fed in, which creates a UCM ID and password – need to take a little action to begin access to email, calendar, portal.
  • Student UCM ID and password that allows them to enter the portal; applicant account roles over to become a student account: SOR – have to answer some questions.
  • Deprovisioning: some period after departure allowed, but can terminated accounts immediately by changing passwords
  • Use SUN ID manager – highly customized. Challenge in sending data to downstream systems: goal is to send in real time. – write directly to db or send batch feed files. What is primary office of record– requires a lot of logic to determine what can be sent and when.
  • Matching with repositories of record is the single biggest challenge
• UCLA
  • April – roll out enterprise directory
  • Bundled with a series of changes with student and payroll
  • Provisioning: students – records populated when they apply with UID, will get login when they file their SIR (with PIN) – gets converted to a login. Staff: 30 minute self-service availability, accounts created after answering a set of questions.
  • Guests: have to go through a third party
• UCOP
  • Prototype of shib
  • No strong binding between UID and the individual
  • AD is the directory repository – PC coordinator creating the credentials – no certainty as to their verification – manual applications sent to help desk for setting up accounts
  • Proposed projects to integrate disparate processes: directory, downstream systems, accounts, etc.
  • Can we leverage UCLA?
• Santa Cruz
  • Not ready yet. Still working on the IdM side. Use old Athena system just tracks accounts; not necessarily an identifier.
  • SUN ID Manager – working with SUN professional services
  • Campus process to determine what accounts related to known individuals (many different accounts on campus)
  • Will require confirmation of basic data – not end-to-end. Separate offices provide data. Getting feeds form PPS and PS student system. Data feed from academic HR
  • Goal: everyone tied to source system or an expiration date so they can de-provision accounts. Multiple status is acceptable. Also tracking for types of appointments.
  • Campus IT security committee: password reset requirements? Can’t use their newly created email account to use as confirmation. Can email to a third party accounts. Also, shared secrets are probably known by parents.
  • Had intended to be live Sep 2005, but now hoping to go live this quarter
• Irvine
  • Scott Mentor. Accepted UCTrust requirements. Account created directly from payroll - hard to set up in advance. Students have accounts but not sure who they are. Data comes from the registrar.
  • Web SSO (WebAuth – proxy server) for long time. Now are catching up.
  • Introducing roles over the next fall.
  • Looking at Burton Group, SUN IM (free with no support) possibly.

Draft UC Policy for Identity Management

• The intended scope of the document.  The intent was to address campus-wide identity management, not all identity management for all applications.
• The distinction between requirements and recommendations.  "Shall" and "must" indicate requirements; "should" indicates a recommendation.

Operational Issues for UCTrust

• Help Desk

  Share support contact information among UCTrust members (telephone, electronic mail, URL, hours of operation) Maintain a common UCTrust knowledge base, using a wiki to enable contributions from everyone.  Backup authentication should be available for this, in case it's needed during the failure of a campus identity management infrastructure.

• Service Levels

  At some time in the future, we should deal with expected service levels among UCTrust members.  (Perhaps just document them for now.)

• User Interface Issues

  We should develop a common template for user interfaces involving UCTrust.  It should help the user understand workflow, progress, and who to call for help. UCLA will be working on this for their campus and will share with the group.

• UCTrust Operational Status

  We should implement a UCTrust status page, primarily for support personnel, that monitors the health of all UCTrust Credential Providers and Resource Providers.

UCnetID Assignment

• UCnetIDs are currently assigned by an overnight, batch-oriented process.  Campuses send files of employees and students to UCOP, and UCOP adds UCnetIDs to the files.  Matching for employees is on SSN and birth date; matching for students is only on (a hashed) SSN.  Experience has shown that the employee matching algorithm is good, but is not good for students, because many students are registered without SSNs.  There is no automated process for resolving mismatches.
• It is not necessary to have a UCnetID for everyone.  Right now, we only use them for employees' access to At Your Service Online (AYSO).  It is likely that any future need for UCnetID among a particular community of UC-affiliated people would be accompanied by access to the information needed to achieve good matches (e.g., for students that receive financial aid).
• The proposal outlined in the section titled "Appendix: Proposed Modifications to IID and uDir" of Identity and Authentication: Next Steps was discussed.  It was felt that the proposed web service would be valuable, but that campus identity management processes would probably not be integrated into IID.  (IID would need to be integrated with the web service, though.)

Affiliations and Roles

• Definitions

  Affiliation describes a person's relationship with the institution (e.g., student or employee).
  Role describes a person's function for the institution (e.g., UCTrust Credential Provider).
  Entitlement describes something a person is allowed to do (e.g., perform low-value purchasing).

• Campuses would like better definition of the eduPerson affiliations, such as employee and student.  Also, new affiliations, such as retiree, are needed and could be defined values for eduPerson's scopedAffiliation attribute.
• Campuses are finding entitlements more useful than roles.
• We need to create a scheme for identifying affiliations, roles, and entitlements that accommodates both system-wide and campus requirements.  The scheme should be compatible with current Internet2/Signet work.
• This is an important, but complex area, and we ran out of time.  We'll continue this discussion in future meetings.

Future Meetings

• Vendors
• Disaster recovery / continuity
• Integration of Pathways into identity management processes