[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Indexical problem in Shibboleth
Solving the Indexical Problem in Shibboleth: An informational note for OASIS SAML participants Introduction/ This note will try to lay out for OASIS SAML participants how Shibboleth solves the so-called "indexical problem". In our case the situation boils down to a destination website obtaining a set of attributes that "belong" to browser user that is trying to access a resource at the destination -- and being sure that the attributes really are associated with the user. This note assumes that the reader is very knowledgeable about SAML: its entities, its terminology etc. Also, this note won't lay out all of Shibboleth, but rather only those details that are relevant to exploring the indexical problem. (And frankly, these details are in flux. Among other things, we are rethinking the "relying party" portion hof the architecture.) The rest of the document consists of: Background on Shibboleth and its architecture, Messages flows that "solve" the indexical problem (we hope! :-)) Security Considerations i.e. how we can be broken. Background on Shibboleth/ Shibboleth is a system (still being designed) for the secure exchange of interoperable authorization information between federating sites. Our fundamental scenario is that of a browser user who is affiliated with an "origin site" wishing to access a resource at a "destination". The destination PEP will make an access decision based on the user's attributes (possibly but not necessarily including 'user name'). Shibboleth differs from SAML in that our system includes a design for the attribute authority (AA) that address certain privacy concerns: The Shibboleth AA includes a model of specifying destination resources such that the user can control which attributes are released to each resource. (This note however will not go into detail on the AA. (If you'd like to know more, contact me, Marlena Erdos, at marlena@us.ibm.com. I can send you my PowerPoint presentation on the AA.)) Attributes are obtained from an AA at the origin site. The entity at the destination site that engages in the Shibb protocol and makes the attribute request is called a "Shibboleth Attribute Requestor" or SHAR (rhymes with 'tar') for short . The SHAR will pass on attributes to the relevant PEP (though that won't be further discussed in this note). Both the AA and the SHAR have public key identities and hence can sign the messages and tokens they exchange. The origin site also has a "Web Login Service" component that functions similarly to the SAML authentication authority. The difference is that the assertion that actually identifies the user is consumed by the AA and never by the SHAR (or PEP). This note will continue to say "Web Login Service". Finally, Shibboleth has the notion of a "Where Are You From" service (WAYF) that lives "somewhere" in the Internet. This service interacts with the user at least once to find their origin site. Its use will become clear in the message flows. Message Flows/ 1. The browser user enters a URL for the desired resource. 2. The destination web server/SHAR determines that the desired resource is access controlled but there is no context information about the user accompanying the request. The SHAR redirects the user to the "Where Are You From (WAYF) service, appending the URL for the destination resource. 3. The WAYF service determines that the user has not used WAYF before. It presents the user with a web form, and asks the user to identify their origin site. (We intend to allow casual institutional names like "Brown", in addition to more formal "neticized" ones like "brown.edu") 4. The user selects (or types) their site name, and clicks "Go There!". The WAYF server optionally creates a cookie to remember the user's origin site, and then redirects the user to their origin site's local Web Login Server, appending the resource URL. 5. The origin site's local WebLogin Server determines that the user has not yet authenticated. It presents the user with a web form. 6. The user enters their userid and password (or does whatever the site requires), and clicks "Submit". 7. The origin Web Login Server, authenticates the user, using the local methodology. If authentication fails, the origin WLS presents the user with an error screen, and the user gets to try again. 8. When authentication succeeds, the origin WLS sends a request to the origin Attribute Authority (AA), passing along the user's local principal identity. (We expect to use the SAML authentication assertion to hold the user's principal identity.) 9. The AA generates a token called an "Attribute Authority Subject Identifier" or AASID (pronounced "acid"). The AASID will be used by the destination SHAR to create the request for attributes about 'this' user. This AASID contains - a handle for the user that is meaningful only to the AA. - information about the AA so that the SHAR can make the attribute request. - the DNS name of the SHAR (to prevent a malicious SHAR from masquerading as the user to another SHAR) - the IP address of the user (to make use of a stolen AASID a bit more difficult) - a relatively short validity period (on the order of minutes rather than hours) After signing the AA, the AA sends it to the origin WLS. 10. The origin WLS then redirects the user back to the destination, appending the AASID object to the destination resource URL 11. The user arrives back at the destination SHAR. The SHAR determines that the desired resource is access controlled and there is an AASID object accompanying the request. 12. The SHAR validates the signature on the AASID object, checks that the DNS name in the AASID is its own name, that the IP address in the AASID matches the IP address of the request, and that the validity period is OK. If all these checks pass, it extracts the user handle. 13. The SHAR builds the attribute request message directed to the origin AA. At this point in time, the only allowable request is "Give me all appropriate attributes". We do not currently allow the SHAR to request specific attributes. Included in the request is the user handle that was in the AASID, and the URL that the user originally passed in. The SHAR signs this request and sends it off (over a TBD protocol). 14. The AA checks the signature on the request message, then obtains the user handle and the resource URL. It also checks that the SHAR is a legitimate speaker for the resource represented by the URL. 15. The AA does a "best fit" match of the target URL and SHAR name against the entries in the user's "attribute release" policy set. It gets the attribute release information associated with the best fit and the corresponding attributes of the user. 16. The AA then creates the attribute response message, sending back the attributes and a validity period. 17. The SHAR receives the attribute response, does checks on the signature etc, and obtains the user's attributes. The SHAR then creates a cookie, scoped just to this server, containing the AASID object. 18. The SHAR sends on the user's request and user's attributes to the PEP. [Actually, we have some other steps here -- to deal with mapping the attribute into privileges appropriate for the PEP/PDP, but that isn't relevant to the indexical problem, so I've left it out.] The Second Time Around The next time the user contacts the destination, the destination will received the AASID that was stored as a cookie. The SHAR can either make another attribute request or use the user handle to find attributes that it has cached. If the validity period of the AASID is expired, that should be taken as "advice" to the SHAR that it might be wise to obtain a new AASID. Security Considerations/ If the AASID is "stolen" and the stealer can modify their IP address to be that contained in the AASID, and do this within the validity period of the AASID, the stealer will have all the attributes and associated rights of the user. To mitigate the possibility of stealing and misuse, we suggest the following guidelines to implementers: SSL must be used by all SHARs to prevent eavesdropping on the AASID. The AASID cookie should be a "memory cookie" that disappears when the browser exits. SHARs should pay attention to the validity period in the AASID. That is it! We have another message flow that also solves the indexical problem but doesn't yield a user handle that could be used for new attribute requests. I'll send this along later. Comments welcome of course. I apologize for the lack of pictures. (I am graphic-tool challenged.) Regards, Marlena PS David Wasley (UCal) is the person most responsible for the creation of these flows. He got assistance from (in alphabetical order): Steven Carmody (Brown), Marlena Erdos (Tivoli), Keith Hazeltine (UWMadison), RL Bob Morgan (UWashington). All of us have participated in creation of the model -- and we've gotten help from other Shibboleth participants, notably Michael Gettes (Georgetown), Ken Klingenstein (Internet2), and Scott Cantor (OhioState).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC