• The next meeting will be held in early August at UC Berkeley.  Jann Fong has solicited specific dates via electronic mail; please respond to her quickly.
• The last couple of meetings have not had wide attendance from campuses.  Could you please give me your opinions on the following?

  This group has a dual purpose:  1) Assist campuses in the development and operation of their identity management services, and 2) Address issues related to UCTrust.  Would people like meetings more specifically focused on one of these purposes at a time?  A few months ago, we agreed on meetings every two months.  Is that too often?  Not often enough? There is some correspondence between attendance and proximity to the hosting campus.  Is travel time and expense an issue?  Would a mix of conference calls and face-to-face meetings be better? Anything else?

Attendees

Chet Burgess, UCOP
Jacqueline Craig, UCOP
Greg Fellin, UCM
Jann Fong, UCB
Kevin Fong, UCOP
Faust Gorham, UCM
Karl Heins, UCOP
Bruce James, UCOP
Mike Kennedy, UCR
Brian Koehmstedt, UCM
Stephen Lau, UCSF (via telephone)
Andrew Tristan, UCR
David Walker, UCOP

Campus Status

• UCOP has joined InCommon but does not yet have an IdP registered.  AYSO will be registered with InCommon.
• UCM is just paying their InCommon membership feed now.
• UCR is completing their InCommon membership now.
• UCB just completed a Burton study and is starting to design their implementation project.  They will probably be hiring a business analyst to lead the project.  There will need to be some education of campus executive management about the costs involved.

Metadata Management

• Since UCTrust is a subset of InCommon, we can leverage InCommon's metadata distribution.  We only need UCTrust-specific metadata where  InCommon does not maintain something that we need.
• There are security risks if the metadata is wrong, although they are remote.  For example, if InCommon is breached, the URL of UCI's IdP could be changed to a PC somewhere else in the world.  That PC would also need to acquire the the private key associated with the InCommon certificate for UCI's IdP in order to forge identity assertions, but there is at least a denial of service potential here.
• InCommon Metadata
  • InCommon metadata is cryptographically signed, so any tampering can be detected once the metadata has been published.  The significant security risks are in the processes used by InCommon staff and member institutions.
  • Currently, InCommon has implemented appropriate separation of duties among the for their part of the management staff.  They have not yet implemented tools to allow member institutions to implement a separation of duties, but they plan to. 
  • InCommon's current plans are to allow a member's technical contacts to propose metadata changes that must be approved by the member's administrative contacts.
• UCTrust Metadata
  • There will be two components of the UCTrust metadata

  • Information for resource providers about which identity providers are certified to issue SAML assertions with the UCTrust Assurance attribute.  This will be distributed in the form of a Shibboleth Attribute Acceptance Policy (AAP) for the UCTrust Assurance attribute.
  • Information for identity providers to know which resource providers are certified to protect and make appropriate use of UCTrust identity information.  This will be distributed as a collection of proposed Shibboleth Attribute Release Policies (ARPs), one per resource provider.

  • The management and distribution of UCTrust metadata must support automated retrieval and installation of metadata updates on, say, a nightly basis by all identity providers and resource providers.  This means that controls must be in place to ensure that any tampering be detectable automatically. The process for proposing, reviewing, and deploying metadata updates will be:

  The initial request for a change will be made to the UCTrust Federation Administration at UCOP.  They will edit the appropriate files, cryptographically sign them, and send them to the designated UCTrust Metadata Reviewers.

  One of the UCTrust Metadata Reviewers (other members of UCTrust) will verify the UCTrust Federation Admistration's cryptographic signature, review the updates for correctness, cryptographically sign them (along with the UCTrust Federation Administration's signature), and send them to the designated UCTrust Metadata Deployers.

  The UCTrust Metadata Deployers (yet other members of UCTrust) will verify both signatures for the updated metadata and publish it on designated web sites for retrieval by identity providers and resource providers.

  • Identity providers will check for metadata updates on a regular basis, probably nightly.  After retrieval, both cryptographic signatures must be verified to ensure the validity of the metadata.  UCTrust members will share software for automating this process.
  • The precise form of cryptographic signature that we'll use is an open issue.  Mike Kennedy will research how InCommon does this and make a recommendation.  If InCommon's approach is not applicable, we can use signatures based on InCommon digital certificates or PGP.

Identity Service Recovery / Continuity

• There was agreement that it makes sense for campuses to provide backup sites for each other, but that the precise measures we take should be based on an analysis of risk and infrastructure requirements (cost).
  • The risk is largely a factor of the other services that require the identity management service.  Some portions of the identity management service (e.g., authentication, enterprise directory, Shibboleth) will probably have to be restored before most other services.
  • We'll want to coordinate with the data center managers' disaster recovery efforts. UCB is currently creating a backup for their identity management infrastructure at UCLA.  We'll be able to learn from their efforts.

Affiliations, Roles, Entitlements

• We defined some terms:
  • Affiliation and groups describe a person's relationship to the organization.  Examples are "student" and "member of the chess club."
  • Role describes a person's purpose for the organization.  Examples are "low-value purchaser" and "identity management system administrator."
  • Entitlements describe something that a person is allowed to do.  Examples are "access licensed library materials" or "view the general ledger."
  • Authorization can be determined by these factors, as well as other, probably more ad hoc, factors.
• Affiliations that campuses have created, beyond eduPerson's, include:
  • Alumni
  • Affiliates
  • Applicants
  • Emeritus
  • Library Patrons
  • Volunteers
  • Donors
  • Extension Students
• We need to continue this discussion to determine what we need systemwide.  We will do this, though, in the context of Internet2's Signet effort.  To that end, we will invite Lynn McRae, the person leading the Signet effort, to one of our future meetings.

Identity and Access Management Policy

• Jacqueline Craig discussed the new framework for IT policy.  [Since the meeting, Jacqueline distributed a new version of IS-11 - Identity and Access Management Policy, based on the discussion.]

Identity Management Practice

• The UCITPS has asked us to document current identity management practice.  Campuses will provide information about their identity management practice for the next meeting.
• We discussed the potential need for separation of duties in the identity management process.  Potential areas where this may be appropriate include:

  Approval and/or review of identification and registration processes when a high degree of assurance is required. Post audit of logs (e.g., changes to accounts, use of privileges)

Our Purpose and Name

• This group has a dual purpose:

  Assist campuses in the development and operation of their identity management services.

  Address issues related to UCTrust.

• The group will be called the UCTrust Identity Management Work Group.
• Now that UCTrust is getting underway, we can expect the work group's emphasis to shift toward it's first purpose.  Since all campuses are expected to participate in UCTrust at some time in the future, we will continue to discuss UCTrust issues as part of the work group's meetings.

Next Meeting

• The next meeting will be held in early August at UC Berkeley.  [Jann Fong has solicited dates via electronic mail.]