Shibboleth FAQ draft-internet2-mace-shibboleth-shib-faq-07.txt Nate Klingenstein 4 May, 2002 Comments should be directed to ndk@internet2.edu. Introduction 1. What is Shibboleth? Shibboleth is a system for facilitating sharing of resources between institutions. When a user at one institution tries to use a resource at another, Shibboleth sends attributes about the user to the remote destination, rather than making the user log in to that destination. The destination can use the attributes in deciding whether or not to grant access to the user. Shibboleth lets each user choose which information about them can be released to each destination. In particular, a user may choose whether or not their name is sent to the remote site as an attribute, protecting privacy in scenarios where a user's name is not as important as verifying some other fact, such as being affiliated with an institution. 2. How can sending attributes alone be useful? Attributes are generally used to refer to the characteristics of a user, e.g. "IBM employee," "Faculty Member," or "Currently Enrolled in Physics 202". Often, a set of attributes about a user are what is actually needed rather than name with respect to giving the user access to a resource. For example, pubs and bars don't register their customers by name, but rather ensure that each customer is at least the minimum drinking age. It would be quite cumbersome for the pub if it had to request and verify a name and password for each customer, but an analogous situation is found all over the web today. Access control by attributes can also let a destination simplify administration of access control to resources by allowing a resource administrator to specify a required characteristic that applies to many users. One alternative of specifying each legitimate user by their individual name is time-consuming and error prone, particularly in environments like higher ed where there is a lot of turnover in parts of the population. Another approach is for each destination to register users from other domains whom they wish to give access to their resource. This is typically done by assigning a username/password for each individual user from every origin domain, causing significant overhead for the target site. Shibboleth, in combination with a trust model known as federated administration, can greatly simplify this problem. 3. What sorts of attributes can generally be sent by Shibboleth? Shibboleth is capable of sending virtually any characteristic about an individual associated with the institution desired by an origin, such as being eligible for digital content, being a law student, or a username. Shibboleth is open-source, uses industry standards, and extensible to allow sites to design XML structures for the expression of their attributes and transmit these attributes to the target. Shibboleth has also been designed to be very modular, allowing sites to easily augment the source code with the ability to interpret new attributes. It is important that both target and origin share a common understanding of the attributes and formats to be shared, however, to ensure successful communication. A Shibboleth club can be used to help define the set of attributes to be used in a given community. 4. How can Shibboleth help to protect users' privacy? A user can choose which of their attributes can be released to any specific destination. This means that a user may choose to send only that they are a member of a certain class to a collaborational project, may choose to send their name to the research group site they belong to, and may also choose to release that they are a student to a digital library. Frequently in current designs, identity is mapped backwards to determine attributes such as member of a particular working group, which is then used to govern access to resources. Shibboleth reverses this process, allowing attributes to be sent with an identity optionally included only if it is necessary. The target site will only know the attributes and information necessary to perform an access control decision, protecting users' anonymity in cases where their identity is not necessarily important. This gives users a large amount of control and flexibility about how their attributes are released and known. Administration has the capability to develop default guidelines for attribute release for users. 5. How are remote resources protected by Shibboleth? After the target receives attributes, it will make an access control decision based on the attributes received. The manager of a remote resource can define a boolean expression based on a user's attributes. Depending on the outcome of this expression, access can be denied or granted. These rules can be defined for certain directories or web pages only on a server, and future versions of Shibboleth are expected to provide support for the concept of application domains. 6. How does Shibboleth securely exchange attributes? Shibboleth has been extensively designed to protect attributes while in transit from many potential attacks. Hosts in all communications are authenticated, and vulnerable transactions are protected using secure channels. Other techniques are employed to protect user privacy and defend against replay attacks. More details on particular flows and security mechanisms can be found in the Shibboleth Architecture, located at http://shibboleth.internet2.edu/. It is important to note that Shibboleth does not provide any limitations on what the target can do with received attributes or what the origin can submit as a presumably accurate representation. Trust agreements are necessary to define the population, retention, and use of attributes out of band. 7. What is a federated administration? Why is it useful? Federated administration is a way of making authentication, authorization, attributes, etc. useful to other domains that are willing to trust the information in a light-weight, distributed fashion. This allows for items of information that are established in one domain to be trusted in another domain based on the trust relationship between the two domains. Doing so can reduce administrative burdens for all parties concerned without relying on a central authority or similar service to perform extensive operations. A registry service is often still needed to host agreements reached by the federation, trusted information about which members are in the federation, or who is authoritative for which entity. A Shibboleth club is a specific instance of a federated administration. A club performs a set of basic functions for the Shibboleth architecture relating to the creation of trust by communities of interest. Internet2 operates a reference club, Club Shib; more information on Club Shib and clubs in general can be found on the Shibboleth web site. Operation of a club is not necessary for Shibboleth use, but it can greatly simplify matters of multilateral trust. Institutions that are members of one club can still define additional bilateral agreements with other institutions. 8. Who is creating Shibboleth? Shibboleth is being developed by members of Internet2 with guidance from the MACE group of higher education architects and a major contribution of work from IBM. Alpha and beta development were spearheaded by Carnegie Mellon University, Ohio State University, and IBM. Advanced 9. What is SAML? How do the SAML and Shibboleth fit together? Security Assertions Markup Language(SAML) is a standard for the exchange of "security assertions" using a standard XML format. This open standard provides a general way to provide certain information in protocol flows. However, SAML is only useful for the transmission of information, and has declared many components and the trust framework out of scope. Shibboleth and Shibboleth clubs provide the infrastructure and trust necessary to make the SAML specifications into a useful application. 10. What are the benefits of open source software based on open standards? Open source software is generally more secure and evolves faster due to the larger body of individuals possessing, using, and modifying the code. Open standards are particularly important in middleware because they extend the interoperability of different systems and enhance compatability. The faster evolution will mean Shibboleth is likely to offer greater and simpler compatibility with legacy systems and broader functionality. The use of SAML as a transport mechanism will help Shibboleth interoperate with other SAML-based security applications. 11. What is required for a campus to set up and to operate Shibboleth? There are different requirements to operate a Shibboleth target or a Shibboleth origin. It is advised that origins operate some manner of SSO service. Shibboleth is currently only available as an Apache module, so targets must operate Apache webservers. No other requirement is particularly unusual and most should be found in common deployments, but for a detailed list of requirements, refer to the Shibboleth Deployment Guide. 12. Will any changes be required on local machines? Shibboleth has been explicitly designed to require very little of users' machines. The only requirement is that the user operate a javascript capable web browser which supports HTTP-level POST and redirections. No further modification or software is necessary. 13. What is required for a destination to make its resources available through Shibboleth? If a destination already makes its resources available through the web, protecting these resources using Shibboleth is simple. Access control rules can be specified in the configuration of the Shibboleth module, or specified for individual directories using .htaccess files. Resources that are not web-accessible are not currently supported by Shibboleth, but support for these applications should be developed soon. 14. What is the timeframe for Shibboleth? Shibboleth is intended to go into alpha testing with a limited set of sites by the end of April. A full beta version is expected to be completed by the end of July. 15. How can a Shibboleth origin and target trust each other? Shibboleth is designed to utilize a trust model which deals with both the secure transit and proper use of attributes. Technical trust, which largely deals with safeguarding information while it is on the wire, must be established such that sites can be certain attributes are only being released to the intended target site and that eavesdroppers cannot acquire attributes they were not intended to know. Political trust occurs primarily out of band and must be designed to govern how attributes are initially populated and what is done with them once they are received by the target. Shibboleth leverages a system of certificate distribution and a mechanism for associating these certificates with known origin and target sites at each participating server. This infrastructure is then used in conjunction with signing and encryption of messages whenever necessary to build the underlying infrastructure to allow sites to be confident of whom they communicate with. Once Shibboleth has successfully and securely delivered the proper attributes to the correct target, it is up to that target's privacy and attribute usage policies to govern use of attributes from that point on. Bilateral agreements or Shibboleth clubs can provide some guidelines and some measure of protection to attributes once sent. Similarly, Shibboleth cannot vouch for the integrity or validity of the attributes it sends, but only the authenticity and that the attributes came from an appropriate authority. It is up to trust agreements to provide some level of assurance as to the content of attributes. 16. How can Shibboleth use client certificates? Although it isn't specified in the architecture, client certificates offer a unique symbiosis with the Shibboleth architecture. A process could be defined and implemented by which an opaque client certificate could contain information about the user's home institution and, optionally, the user's pseudonymous identity. This could obviate the need for use of a WAYF and possibly even user-mediated authentication with the origin in this instance. 17. What are some benefits to higher ed institutions of using Shibboleth? Shibboleth affords both new capabilities and new privacy to higher ed in the online world. The ability to protect identity while still sending non-personally identifying attributes about a user trying to access a site allows for much simpler and more anonymous access control. Shibboleth's ability to send information about users for access control is functional no matter where the user is, allowing a user to be on any computer anywhere and still be granted access to Shibboleth-protected resources using their home institution's Shibboleth services. Shibboleth can provide a single infrastructure to support a variety of intercampus authorization services, including access to digital content, support of shared workgroups between institutions, and instructional collaboration. Online collaboration and licensing of instructional materials could be made simpler, faster, and more secure. Shibboleth can also help institutions begin deployment of web services in a higher-education orientation. The net effect will ease the burden on IT departments, information providers, and users while providing new capabilities. 18. What are some benefit to information providers of using Shibboleth? Information providers are given a vastly more simple way to maintain use rules and user bases, while allowing more powerful means of access control. Shibboleth relies on information kept at origins, meaning information providers may no longer need to create and maintain separate databases of authorized users. Users of online material can be located anywhere and don't need to use a portal, and only users which fulfill the eligibility the information provider defines will be granted access. Attribute acceptance policies can be defined in simple booleans or can be made arbitrarily complex with the modular, open-source code provided by Shibboleth. 19. Why is Shibboleth named Shibboleth? http://shibboleth.internet2.edu/why-shibboleth.html