Shibboleth Working Group Overview and Requirements Document
draft-internet2-shibboleth-requirements-01.html
Steven Carmody
February 20, 2001
comments to: mace-shibboleth@internet2.edu
Table of Contents
1. Abstract
2. Introduction
3. Specific Goals for Stage 1 of Shibboleth
4. The Shibboleth Model
5. Possible Scenarios
6. Service Requirements
7. References
8. Acknowledgements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL used in this document are to be interpreted as described in [bradner97].
Shibboleth, a joint project ofInternet2/MACE and IBM,is investigating architectures, frameworks, and practical technologies to supportinter-institutional sharing and controlled access to web available services.The project will produce an analysis of the architectural issues involved in providing suchinter-institutional services, given current campus realities and the current state of relevant standards.It will also produce a pilot implementation todemonstrate the concepts. MACE would like to thankIBM for itsparticipation and analytic support.
Shibboleth aims to develop an architecture for a standards based vendor independent web access control infrastructure that can operate across institutional boundaries. The Internet community has achieved significant commonality in the web space by virtue of having such standards (e.g. HTML/HTTP/JavaScript/SSL/etc),and having a few no- or low-cost implementations of the clients and servers. Standards and standard architectures have promoted interoperability. This project seeks to define similar standards for the secure exchange of trusted interoperable information which could be used in authorization decisions. The goal is is to develop and promulgate an architecture, which can then be used in a multi-vendor, open source, standards based environment. If a commercial product fits in this scenario, it does so because it embodies an architecture that can potentially be replicated in a multi-vendor/open-source/standards-based way.
The problem space includes defining:
If vendor independent standards existed in this space, and assuming they addessed our requirements and made technical sense, it would be attractive to use them. (This could be a de-facto standard, or something blessed by a relevant standards organization.) The Shibboleth Project will participate in standards development efforts. Clearly, there is growing interest from both the user community and the vendors of single domain web access control solutions in having a blessed interoperable standard in this space. The OASIS XML Security Services Technical Committee, a vendor supported effort to establish an interoperable standard, clearly bears watching. However, this effort does not expect to provide a complete solution to the problem (e.g. they assume that trust has already been established between the origin and target sites). Shibboleth is not about achieving consensus within a standards body, and is also not inclined to wait forever for such a standard to appear. Shibboleth owes a great deal to several previous and current efforts in this sphere, including the DLF effort An Architectural prototype for Certificate Based Authentication and Authorization,the previous UK based effort the CANDLE project,the current UK based effort the Sparta project,and the current Spanish effort.
The design must address the reasonable expectations of users that their privacy will be safeguarded, and that they will be able to manage the disclosure of personal information to another site. Some existing law gives some users control over the release of personal information (e.g. in the US, FERPA gives university students the right to block the disclosure of personal information; the EU privacy laws require explicit user approval for transferring data from which the real identity of a living person could be deduced, etc.) More important than the laws, though, is a recognition that a growing number of people are concerned about managing how and when their personal information is available and exposed in cyberspace. The design must accomodate the needs of some sites to use personal information as part of an authorization decision and the reasonable expectations of users that they will be able to manage this process, that disclosing information to one site does not disclose it to others, and that there will be no inadvertant disclosures.
Shibboleth will define standards in a number of areas, allowing locally managed origin-site authentication systems and locally managed target-site authorization systems to interoperate successfully. The intent is to support, as much as possible, the heterogeneous security systems in use on campuses today, rather than mandating use of particular schemes like Kerberos or X.509-based PKI, or particular vendor products. In the ideal casewhere the client and server do both use PK certs (and the client certis verifiable by the server), the Shibboleth architecture should permitthem to do so without further complication. In addition, it is not our intent to enhance local authentication systems (e.g. by adding support for delegation).
Shibboleth will require that a site have a web based authentication mechanism (login"). This functionality is considered to be out of scope for Shibboleth. However, we recognize that many sites do not currently have this functionality, and consequently may supply this functionality as a Shibboleth add-on. We are talking to other university based projects, and would like to provide a web login mechanism that could be shared by several services. Campus-wide Single-signon for web services is also considered a local matter, out of scope for Shibboleth. Shibboleth does not plan to implement or provide that functionality. It will, however, define how Shibboleth and an existing SSO mechanism can interoperate.
(define good behavior) To the extent possible, Shiboleth should strive to remain compatible with and support the security architectures used by the portal evironments popular in higher education. Many universities see web based portals as a key component of their information delivery strategy. Portals give users customized, personalized views of their information, projects, and courses. Many sites deploying portals are hoping to provide single-signon for all of the services available through their portal. This will require a local web SSO framework. In addition, the n-tier architecture of many portal based services will require that the local authentication service provide a delegation mechanism. Widespread use of portals is likely to highlight the need for a more generalized authorization mechanism for intra-campus use. It would be desireable if this enhanced mechanism could accept credentials from other sites. As noted previously, out intent remains to view authentication and authorization as local systems, and work to define the standards needed in order to allow these local systems to interoperate.
While Shibboleth is focused on web-based services, many other services also see the need for a multi-domain access control infrastructure (e.g. QoS, H.323, Calendaring, etc). Fostering the creation of a common infrastructure that could be shared by these other services is not an explicit goal of Shibboleth. That would be a daunting task, given the current level of understanding of cross-domain security issues. However, the longer term goal of an interoperable access control infrastructure should not be ignored, and some effort should be made to "push the ball forward" in the larger effort.
3.1 (consensus on model) Develop a solution model and an architecture for cross-institutional exchange of authorization information, within the web framework. This will include means of a) creating and managing trust between sites, b) managing which information an origin site transfers to each target site, c) standard schema definitions allowing inter-site communication, and d) securely transferring attributes from the origin site to the target.
3.2 (work needed to achieve interoperability) Define the standards (e.g. attribute names, well defined interfaces to the authorization information) and protocols (e.g. methods of obtaining additional attribute information about an individual) that will allow independent implementations to interoperate. To the extent possible, remain compatible with any emerging standards in the commercial world.
3.3 (higher ed community education; evangelism) Define the requirements that sites must meet in order to participate in Shibboleth (e.g. having a campus authentication system). Promote "best practice" for implementing the local infrastructure required to simplify the local implementation of Shibboleth (e.g. use of particular directory schema standards).
3.4 Develop a solution that can address a combination of these three scenarios.Taken individually, each of these situations can be solved in a variety of straightforward ways. Taken together, they present the challenge of meeting the user's reasonable expectations for protection of their personal privacy.
3.5 (Respect the user's privacy.) Aim to provide reasonable personal privacy protections for users. Try to give the user control over the release of attribute information (including their identity) to the target site. Address the legalities that govern the release of personal information. In the U.S., FERPA governs the release of inormation about higher education students. Although this is a U.S. based project, we should remain aware of the European Union laws that govern the release of any personal information.
3.6 (open source implementation) Prototype (or complete) an open source implementation demonstrating solutions to the three scenarios.
3.7 (ease of implementation for a site) Shibboleth must work with the Apache web server, and with common, minimal authorization systems such as htaccess files. However, the shibboleth design should not be *tied to* minimal infrastructure. The design process should consider working with more mature, more evolved authorization systems.
3.8 There is considerable overlap between Shibboleth and the UK-based Sparta project. To the extent possible, maximize overlap betwen the two projects. Their goals include:
The defined problem spans the administrative boundaries of multiple campuses and enterprises. Developing a solution requires defining the roles, relationships, and responsibilities of these various entities. There are many ways to look at this problem; there are many solutions to it. This section describes the model that the Shibboleth project will use when developing a solution. This section is not intended to be a design document. Rather, it is a high-level description of how we see the problem, and the solution framework that we intend to pursue.
To the browser user, and to the web resource manager, Shibboleth will appear to be a "user to user" service. The web resource manager will specify who can access her resources, and the browser user will supply the appropriate credentials when he attempts to access these resources. However, in order for this transaction to succeed, the campuses (or enterprises) that both of these people are members of must have previously taken certain specific steps. If their campuses are not participating in Shibboleth, then individuals from those communities cannot use Shibboleth.
The origin site (where the browser user belongs) is responsible for authenticating the user, and for providing attribute information about the user to the target. These statements must be true, and will be signed by the institution. The target site (where the web resource manager belongs) is responsible for comparing these statements against the policy rules associated with the desired resource. Shibboleth will also include, and the origin site should make available to the user, a mechanism allowing the browser user to manage the release of personal information to the target site. Both sites will need to satisfy themselves as to the true origin of a request or a set of assertions. The relationship between the two sites may include a contract which governs which information can be passed to the target.
Every site that joins Shibboleth can decide to participate as an origin, as a target, or as both. Commercial information providers, for instance, are likely to join only as targets. Being an origin has different requirements from being a target. To participate in Shibboleth, a site must ensure that other sites can validate the requests and statements that it makes. This document will refer to this process as "establishing trust betwen the sites". In the world of network and computer security, trust refers to the level of confidence we have in the information supplied by another entity.
Shibboleth will require that a joining institution make available a PKI certificate containing the public key of their Shibboleth signing entity. All statements from the institution must be signed using the matching private key. When a site receives a signed request from another site, it must be easy for the recipient to securely obtain the requestor's certificate, in order to validate the signature.
The browser user is a member of the community at the origin site. This site must maintain a campus-wide identifier space, run a campus-wide authentication system, and make assertions about each user. The origin site is the trusted entity in this model -- not the browser user.
The origin site must assign identifiers to users, and manage the name space. There may be up to four different kinds of identifiers. There are likely to be local identifiers, used within the local authentication system. There will be the traditional kinds of handles (SSN, employee number, name and address, etc); some of these may be supplied as attributes to the target. There will be pseudononymous identifers, supplied to targets, and which can be used (within an access control framework) to obtain additional information about a user. And there will be the user's name, expressed in a standard Shibboleth syntax.
Local identifiers are used within the local authentication system. Different systems have vastly different formats for names (e.g. Kerberos uses principal@realm, within PKI a certificate binds a key to a Distinguished Name, but there is no requirement that this name be used within the authorization system). There is no need for a site to export these names, or to normalize them to some standard syntax.
Shibboleth will use pseudononymous identifiers in conversations betwen the origin and target sites. The origin site will remember the mapping between each pseudononymous identifier that it has generated and the appropriate local identity. The target site can request assertions of specific attributes attached to a specific pseudononymous identifier. Several factors (see below) will affect whether the origin site releases this information. These pseudononymous identifiers, although unique, need not provide an external organization with sufficient information to allow them to precisely identify a single specific individual.
Because in some cases access will be controlled by a list of names, Shibboleth will promulgate a standard way of expressing a name used in the inter-domain context. We have chosen to use the EPPN attribute defined with the eduPerson object class.
Authentication is another responsibility of the origin site. Authentication is the process where a network user establishes a right to an identity -- in essence, the right to use a name. There are a large number of techniques that may be used to authenticate a user -- passwords, biometric techniques, smart cards, certificates. The "thing" that is supplied to prove identity is called a credential. Note that names need not correspond to the usual names of individuals in the physical world. A user may have the rights to use more than one name: we view this as a central philosophical assumption in the cross-organizational environment. There is a scope or authority problem associated with names; in essence, when a user is authorized to use an identity this is a statement that some organization has accepted the user's right to that name.
An authentication service is a network-accessible system that performs this verification. Sites use many different approaches to authentication, so the user's authentication method is not likely to match the target's. Even if they do match, policy constraints ("only type your password into approved pages") or trust-domain limitations (disconnected Kerberos realms or certification authorities) will mean direct client-server authentication will not work in practice. In the ideal case where the client and server do both use PK certs (and the client cert is verifiable by the server), Shibboleth should permit them to do so without further complication. However, in the short term, authentication will be handled locally.
Some campuses have implemented local single signon mechanisms to facilitate access to controlled web resources scattered across the campus. The user only has to sign on once to access multiple systems and applications. Shibboleth will provide a way for these systems to interoperate with it. However, Shibboleth will not attempt to provide an implementation of a local SSO scheme.
An identifier has attributes associated with it. These may be demographic in nature -- for example, attribute/value pairs signifying a faculty member in engineering, or signifying a student enrolled in a specific course -- or they may capture permissions to use resources. Attributes may be bound closely to a name (for example, in a certificate payload) or they may be stored in a directory or other demographic database under a key corresponding to the name. Attributes may change over time; for example, from semester to semester the set of courses that a given identity is associated with may well change. Just because some system on a network has knowledge of a name does not necessarily imply that it has access to attributes associated with that name. There is a fine line between rights to names (authentication) and attributes; for some purposes, simply knowing that a user has a right to a name from a given authorizing authority may itself represent sufficient information (an implicit attribute, if one wishes) that can support access management decisions.
Individual sites will decide which attribute information they want to keep about individuals in their community, and what to name these attributes. The mechanism for managing these attributes is a local choice. However, we expect most sites to use an Ldap directory, and to associate these attributes with the user objects. This project, however, will likely develop a standard set of attributes (and a controlled vocabulary of values for each), so that sites can exchange attributes and make common assertions. In addition, individual pairs of sites can negotiate the use of custom attributes. It will be the responsibility of the local site to map between the local attribute names and the inter-domain names.
People (and services and resources) are often organized into named groups in order to simplify the process of assigning rights and privileges. LDAP, the de-facto standard in directory services, supports several ways of storing group definitions. Many sites attempt to automatically maintain the membership of certain centrally-maintained groups: faculty, staff, students, department rosters, course enrollments, etc. In addition, users (and roles - e.g. the local support person in geology, whoever that is today) are often empowered to create and maintain their own local group definitions.
The origin site must be running an Attribute Authority process that can accept a pseudononymous identifier and, within an access control framework, provide additional attribute information. This information will be supplied as assertions signed by the origin site.
There are three controling factors in the process of creating assertions: any existing contract between the origin and the target sites, the current request from the target to the origin, and the browser user. Contracts will typically exist between campuses and commercial information providers. They usually specify who can use the resource (e.g. "active members of the community"), and often constrain the information that the provider can collect (e.g. access must be anonymous, so the provider cannot collect identity). In such a case, if the provider asked for identity and even if the user were willing to provide it, it cannot be sent to the target. As part of the process of making the authorization decision, the target may request additional attribute information from the origin site. For instance, the access rules for the desired resource may require that the origin provide assertions on multiple attributes. The target will not recognize this situation until it begins the authorization process. At some point, it may need to request additional information. Lastly, the user must be able to control the release of personal informaiton to the target. The target may need the user's identity in order to make an authorization decision. The user may decide against releasing this information (in which case they will not gain access to the resource). But, the user must be able to control which information is released to which targets.
The target site is responsible for providing an authorization infrastructure. Authorization is the process of determining whether a requestor is permitted to access a resource. Oftentimes, the authorization decision will require examining a set of attributes associated with that identity. Note that permission to perform an action does not guarantee that the action can be performed; for example, a common practice in cross-organizational licensing is to further limit access to a maximum number of concurrent users from among an authorized user community. An authorization service is a network-accessible system that makes, or helps make, this decision.
In Shibboleth, the origin site will provide a set of assertions about the user. The target will match these against the policy rules associated with the desired resource, will ask for additional information if needed, and will produce an access decision (yes or no).
A variety of methods are used to determine eligibility: individual identity (e.g. Jane Doe can read this), group membership (all students enrolled in CS11, all members of the Georgetown community), role (all Department Chair's can see this). Oftentimes, individual and group identities are organized into a set of hierarchical relationships, and rights are privileges are managed within this tree structure. In order to simplify management, rights often inherit downward through the tree. Rights generally fall into three categories: read/query, write/update, and use (execute, print, etc). Individual services often create privileges that are specific to it. For example the identity might be 'member of South Bank University' and it might be authorized to view an electronic journal article, copy parts of it, print it. Rights include transport rights (to copy, transfer or loan a document), render rights (the right to play or print), derivative rights (the right to re-use material).
Authorization has traditionally been done by associating an Access Control List (ACL) with a resource (e.g. a file, directory, web object, printer, etc). Initially, each application (or system service) had to implement its own access control mechanism; many still do. Over time, Policy Managers began to appear - infrastructure services that centralized the authorization function, and abstracted it out of each application. These services brought more consistency to the ways in way access was managed; increasingly, sites came to see managing access as a policy issue. However, Policy managers usually continued to use an ACL model to specify and store permissions. More recently, attribute certificates have begun to be examined as a possible approach.
In order to work with Shibboleth, authorization systems will have to be able to accomodate names that are specified as user@domain. Many existing authorization systems assume that all identities are local. Oftentimes, the authorization system will make the set of assertions (collectively called entitlements) available to the web resource.
Distributed systems often provide a way for the authentication system to establish a security context. That functionality is not being provided here. Shibboleth will provide a way to transport assertions from the origin to the target, but it will not transport the kind of information typically needed to establish a security context.
Many of these definitions are taken from [Westerinen00].
The process of validating a requestor's claimed identity. Typically, the requestor presents one or more credentials as proof of identity.
Taken individually, each of these scenarios can be solved in a variety of straightforward ways. Taken together, they present the challenge of meeting the user's reasonable expectations for protection of their personal privacy.
Notes:
Notes:
Notes:
Notes:
Notes:
Notes:
G1. Shibboleth specifies an origin site and a target site. In practice, a particular site can operate as one or the other of these, or as both. Operating as one SHOULD NOT require a site to operate as the other.
G2. A user SHOULD be willing to tolerate some amount of delay on their initial access to each remote site. Users SHOULD understand that some amount of conversation will have take place between the origin and target sites, as part of the process of validating the user as a valid user. However, successive requests to the same site SHOULD respond within "normal web response time".
I1. Origin Sites MUST manage identity for the members of their communities, and MUST assign a unique EPPN format identifier to each entity.
AN1. Each origin site MUST have an existing local campuswide authentication system.
AN2. Users MUST authenticate to web services using the method their campus has documented for them. User should NEVER be asked to type their passwords into a remote authentication service.
AN3. Policy issues (such as "how long does a login last") are considered to be local issues, out of scope for Shibboleth
AN4. There MUST be a standard way for the local authentication system to assert the local identity of the browser user to the local Attribute Authority. A user MUST be able to access remote resources without the target site implementing a version of the origin site's authentication system.
AN5. If the intra-institutional user experience is single signon (ie, "login", however that happens, only once for many/all local sites), then the inter-institutional access SHOULD also have that same experience. However, only-once-for-all-external-accesses (in addition to a local signon) would probably be acceeptable.
AN6. None of the existing university mechanisms implement authentication by requiring that the browser user traverse a "front door". Shibboleth SHOULD continue this approach.
PP1. The design MUST allow users some control over the distribution of personal attribute information. The design MUST address the reasonable expectations of users that their privacy will be safeguarded, and that they will be able to manage the disclosure of personal information to other sites. Users MUST have the option of blocking certain transfers.
PP2. The design SHOULD allow users to automate, to the extent they are comfortable, the process of deciding what information to release and when.
PP3. The solution SHOULD include a mechanism that addresses the laws of the EU countries regarding use of personal data.
PP4. The solution MUST be compatible with a reasonable interpretation of the U.S. FERPA laws.
AT1. Each origin site MUST maintain a set of attributes associated with each of its users. The names and uses of the attributes are local decisions.The local definition of some standard shibboleth attributes (e.g. "active member of their community") will be a local decision.
AT2. There MUST be a standard syntax for assertions about attributes.
AT3. There MUST be a set of pre-defined attributes which can be used to make common assertions. These attributes should have associated with them possible values of pre-defined controlled vocabularies.
AT4. Each campus MUST operate a centrally managed process willing to make assertions about the attributes of individual users, and formatted using standard Shibboleth syntax and semantics. This process MUST operate under the Personal Privacy guidelines.
AT5. Target sites MUST accept the assertion of the origin site as to whether or not an attribuute is valid for a particular individual.
EN1. The process of building an entitlement MUST involve 1) any pre-existing agreement between the origin and target sites that specifies which attributes can be exchanged, 2) the attributes being requested as a result of a particular user request for a web resource and the target site's need for specific attribute information in order to make an authorization decision, and 3) the user managing the process of releasing personal attribute information.
EN2. There MUST be a standard syntax for entitlements.
EN3. The entitlements MUST be transported to the target site, which will use them as input to the authorization decision.
EN4. A user MUST always be able to control the inclusion of a Specific Identity attribute in an entitlement.
EN5. The design SHOULD include a framework that provides the target and origin sites some flexibility in choosing how and where authorizations are expressed, and how and when are these exchanged. In general, policy decisions will be made by using the attribute information contained in the entitlements supplied by the user (and augmented by any additional attribute information obtained dynamically by the target site), and matching this information against a policy rule that determines eligibility. It is clear, though, that this could be done in two very different ways:
A decision to use one approach or the other determines which site shoulders the bulk of the burden for managing the authorization process. It also determines which site knows what is in the policy rule. There is an allocation of work (or of pain, perhaps) between resource owners and origin domain managers as to who manages the detailed authorization info. If content providers have to manage accounts for all users from the origin site, that's pain for them. If the origin site has to manage detailed authorizations to resources for each of its people, that's pain for them. Choices in the middle need to be outlined.
AZ1. Resource managers at the target site MUST be able to define policy rules which specify the set of entitlements required to obtain access to a particular web resource.
AZ2. A properly configured web server MUST ensure that only those requestors having the appropriate entitlements can access the resource(s).
AZ3. The target site MUST manage authorization, matching an entitlement provided by the origin site against the appropriate policy rules.
AZ4. Resource owners SHOULD be able to specify in a policy rule that "group X at site Y" can access the resource. Shibboleth should be able to express this idea.
CD1. A trust relationship MUST have been previously established between the origin and the target sites. A variety of formalisms and mechanisms for creating trust are anticipated, depending on the nature of the transactions between sites. Trust agreements may range from simple acceptance of another institution's credentials to formal, contractual mappings between institutions based on detailed procedural comparisons.
CD2. There SHOULD be a scaleable, easy-to-manage mechanism for establishing and defining trust between sites. The process of managing the set of relationships between the N sites using shibboleth mechanisms MUST be scaleable.
CD3. The target site MUST trust the assertions made by the "shibboleth entity" at the origin site about the browser user.
CD4. The contract between the origin and target sites MAYspecify how the target can use the attribute information supplied by the origin site. In particular, the contract should address whether the target can attempt to aggregate attribute information across multiple requests, in order to get a fuller picture of the user. While the contents of a particular contract are clearly out of scope for Shibboleth, it might be useful to establish a default contract that defines target site behavior in the absence of a superseding contract.
CD5. Policy issues (e.g. whether an origin site is willing to provide certain attribute values to a particular target site) MUST be negotiated out-of-band. No provisions will be included in the protocols to negotiate these dynamically.
CD6. A resource manager at any participating site SHOULD be able to find out about the terms of use between her site and a specific other site.
CD7. The design and the implementation SHOULD address the security requirements of information vendors who place a high value on their property (and consequently will only align with architectures which provide the required level of security).
B1. Shibboleth MUST work with common-off-the-shelf browsers (i.e. the "current" version of the Microsoft and Netscape browsers, with current defined by the marketplace).
B2. Shibboleth SHOULD strive to avoid requiring Shibboleth-specific software on client machines. This should be done only when there is absolutely no alternative.
B3. The Shibboleth design MUST not require usable client certificates.
W1. The implementation MUST run with the Apache web server.
W2. A site MUST be able to participate in Shibboleth as an origin or as a target whether or not they are running a local SSO implementation.
W3. Once access control has completed, session management MUST be handled by the web application.
A1. Implementations SHOULD support auditability of the user action "user approves releasing attributes".
[bradner97] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Westerinen00] A. Westerinen, et al., "Policy Terminology, INTERNET-DRAFT, November 24, 2000.
[Lynch98] Lynch, Cliff, A White Paper on Authentication and Access Management Issues in Cross-organizational Use of Networked Information Resources, Revised Discussion Draft of April 14, 1998.
[Hazelton00] Hazelton, Keith, et al. eduPerson 1.0 Schema, January 2001.
[IMI00] Internet2 Middleware Initiative, Identifiers, Authentication, and Directories: Best Practices for Higher Education., May 9, 2000.
The author gratefully acknowledges the suggestions of Marlena Erdos, Ken Klingenstein, R.L. "Bob" Morgan, David Wasley, and the members of the mace-shibboleth list.
Steve Carmody
Computing and Information Services
Brown University
Steven_Carmody@brown.edu