Internet2/MACE and IBM are working on a research and development project called Shibboleth (Erdos 2001) to provide security for interaction between a number of uni- versities. Internet2 is a consortium of some 200 universities that are working with industry and the government to develop and deploy advanced networking technolo- gies. Specifically, the Shibboleth project is investigating practical technologies to sup- port institutional sharing and access control to Web-based services. It is a goal of Shibboleth to use open standards in its solutions. Shibboleth explicitly states as one of their key concepts that they will use the message and assertion formats and protocol binding developed by SAML. What makes this project especially interesting is the scope and difficulty of the security problems that Shibboleth is attempting to solve. This section will give an overview of Shibboleth as an advanced example of some solu- tions to some of these hard security problems.
Let’s first walk through the Shibboleth model, and then we will discuss three impor- tant problems for which Shibboleth is attempting to derive solutions. The Shibboleth model is shown in Figure 5.3.
Figure 5.3 Shibboleth Model.
Browser (Joe) Attribute Authority WAYF Access Control SHAR SHIRE Requestor University Resource Provider 3b 3a 5 2 6 4 3 1 Handle Service
Starting at the lower left of Figure 5.3, we see a user, Joe, at his browser in the requestor university, say, MIT, attempting to access some resource at the resource uni- versity, say, Harvard. When Joe makes his request he connects with the Shibboleth Indexical Reference Establisher (SHIRE), line 1. Since one of the aims of Shibboleth is privacy, Joe does not identify himself to the SHIRE at Harvard. Instead, the SHIRE, noticing the lack of any SAML authentication assertion, redirects Joe’s request (2) to Where Are You From (WAYF), which looks up the handle service (HS) that is associ- ated with MIT. Joe will have previously registered his handle service with the WAYF service. The WAYF service returns the URL for Joe’s HS to the SHIRE. The SHIRE redi- rects Joe’s request to the MIT HS through Joe’s Browser (3).
If Joe has not authenticated himself previously with the MIT HS, he is required to do so at this point (3a). The handle service looks up the correct attribute authority, AA, that handles Joe’s attributes (3b) and creates an object that identifies Joe. This object, called an attribute query handle (AQH), contains a reference to Joe that is opaque to the SHIRE but can be interpreted by the AA to identify Joe’s attributes. The AQH also con- tains the URL to the attribute service that handles Joe’s attributes. The HS returns the AQH to the SHIRE. Note that the SHIRE does not know Joe’s identity. It only has the opaque reference to Joe, which it cannot interpret.
The SAML request/reply protocols are used for these messages, while the browser uses the POST profile of SAML to access the SHIRE. The package that makes up the AQH contains the URL to the AA and a SAML authentication assertion. When the SHIRE receives the AQH, it carries out a number of security checks on the SAML asser- tion to assure its validity, such as valid time and signature checks. The HS is required to digitally sign the SAML assertion.
The SHIRE passes the AQH to the Shibboleth attribute requestor (SHAR), which contacts the MIT attribute service returning the AQH and its own URL. The SHAR uses a SAML attribute query request in the return call to the AA to request Joe’s attributes. The attribute service decodes the AQH, identifies Joe’s attributes, and returns Joe’s attributes to the SHAR, using a SAML response containing a SAML attribute assertion. The SHAR then passes the attributes to the access control at Harvard, which uses them to grant or deny access. As noted, Shibboleth uses SAML assertions and protocols as a standardized way to pass much of the data between entities.
The various services must establish out-of-band trust relationships—for example, between the SHIRE and HS and between the SHIRE and the Attribute Service.
Having completed this overview, we will now look at the approach that Shibboleth uses to satisfy the goals of privacy and federation, and some special services that the attribute service can offer.
Privacy
There are two aspects of privacy:
■■ Keep my identity secret.
■■ Don’t share any of my private information with anyone else unless I authorize it. The Shibboleth model as described above puts forth one solution to these require- ments. Sending only a set of attributes to Harvard satisfies the first goal. The system 128 Chapter 5
does not reveal Joe’s identity, since Harvard cannot derive Joe’s identity from the infor- mation that is sent to the SHIRE. Shibboleth uses the subject element in all SAML asser- tions in such a way as to represent the blinded name of Joe. However, Joe also might not want to reveal to Harvard that he is a full professor in the Astronomy department, for example, which is one of his attributes. This is the second privacy problem.
This second type of privacy, honoring the amount of information sent to another party, is accomplished in a different way by Shibboleth. Joe can arrange with the AA at his MIT attribute service which attributes to reveal to which requesting party. When the SHAR at Harvard sends a request to the AA at MIT, the protocol requires that it send its URL with the request and that it has authenticated itself to the AA at MIT. This is done prior to any requests for attributes. Therefore, the AA at MIT only sends the attributes that Joe has permitted it to send to Harvard.
There is another aspect of the second type of privacy––can Joe trust the AA to only reveal what Joe has authorized the AA to release? This is out of the scope of Shibboleth, or for that matter any automated system. This trust must be established between the authority keeping a user’s information and the user. The question then becomes, “Do you trust that organization?” The fact that the AA is within Joe’s organization makes this a solvable problem.