- DRAFT 8/10/2004 -
Responsibilities for Federated Authentication
There are three types of players with respect to federated
authentication:
- Identity Managers - The organizational units that manage
electronic identity information and provide identity information and
authentication services for their campuses/sites.
- Service
Providers - The
organizational units that manage services. These services are
generally network-based, but may not necessarily be so.
- Community Members - The
people who have an established affiliation with a campus; they are the
people who
use the Service Providers' services and whose electronic identity is
managed by Identity Managers.
This document discusses the identity-related responsibilities for which
each of these players assumes liability.
Identity Managers
Identity Managers are responsible for a campus's enterprise directory, the campus's
repository of information about the members of its community.
Identity Managers are also responsible for the identification,
registration, and authentication processes that bind specific Community
Members
to the information about those members in the enterprise
directory. In particular,
Identity Managers are responsible for:
- Accuracy and timeliness of information in the enterprise
directory.
- Privacy of information in the enterprise directory. This
requires a registration process by which services are authorized to
utilize identity information.
- Availability of the network-based services that provide access to
information in the enterprise directory.
- Accuracy of the binding of Community Members to information in
the enterprise directory. This includes:
- The identification and registration processes, which result in
the issuance of electronic credentials
(e.g., user ID and password)
to Community Members.
- The authentication process, which verifies posession of
credentials within each
session.
- Audit logs that enable investigation of security incidents and
misrepresentation of identity.
- Standards and best practices that guide the behavior of Service
Providers and Community Members in the use and protection of identity
information. In order to facilitate use of services by members of
multiple campus's communities, the University will establish minimum
standards and service levels for all Identity Managers within UC.
As part of the membership requirements for UC's federation, Identity
Managers will provide documentation (i.e.,
service level descriptions) describing the degree to which which they
meet these responsibilities.
Service Providers
Service Providers are responsible for the secure operation of their
services. With respect to their use of identity information, they
are responsible for:
- Awareness of Identity Managers' service levels. When
multiple levels are available (or negotiable), selection of appropriate
service levels to meet the service's needs. When a sufficient
service level is not available from the Identity Manager, the Service
Provider may need to implement its own identity management services in
order to meet its service's security requirements.
- Audit logs that enable investigation into security incidents
related to information provided by Identity Managers.
- Compliance with Identity Managers' standards and best practices
for use and protection of identity information.
Service Providers are also responsible for standards and best practices
that guide the use of their services, as well as appropriate audit logs
and descriptions of their service levels. Those responsibilities,
however, are outside the scope of this document.
Community Members
Community Members are responsible for protection of the electronic
credentials
provided to them by their Identity Manager. In particular, they
are each individually responsible for:
- Assurance that their credentials are not held by other people.
- Compliance with Identity Managers' standards and best practices
for use and protection of identity information.
Community Members are also responsible for conformance with Service
Providers' standards and best practices. Those responsibilities,
however, are outside the scope of this document.
David Walker - 8/10/2004