1. David L. Wasley Office of the President University of California Shibboleth Safe delivery of reliable authorization data David L. Wasley University of California

2. 2 Shibboleth & the PKI Puzzle

3. 3 Internet2 Shibboleth v Middleware initiative to leverage existing campus authentication methods while encouraging Resource Providers to adopt better access management methodology l Usable by a wide variety of resources v The focus is on the trusted release of a User’s attributes to allow Resource Providers to make appropriate authorization decisions l Local authentication method is taken for granted

4. 4 Typical Resources v Shibboleth design depends on web technology v Content providers l Shib should be a drop-in package (well, almost) l Should simplify the trust model l Access rules would be established in contracts v Portals - either local or remote l Remote would require negotiation for personal ID v ASPs etc…

5. 5 Typical User Attributes v Primarily from eduPerson Object Class l See http://www.educause.edu/eduperson/http://www.educause.edu/eduperson/ v “member of community” could be derived l What about specific “group” memberships? v Eligibility under terms of a specific contract v Personally identifying information v User-defined attributes are possible l e.g. for specific target use l Problematic from security point of view

6. 6 Privacy is a serious design goal v User’s institution should have a default release policy that all Users (can) know l E.g. always give “member of the campus community” l Internal vs external defaults might be different v Users should be able to augment that policy l Separate interface to AA to edit release policy l Real-time interaction may be implemented too s Easier for non-technical Users to understand l May be required by FERPA or HIPAA or …

7. 7 Shibboleth Elements v Local security domain Attribute Authority (AA) l Has access to User directory l Keeps a release policy database s May be modified to reflect User preferences v Target domain Attribute Requestor (SHAR) l Retrieves anonymous “handle” for the User l Gets User attributes from AA over SSL/TLS v Uses XML/SAML for messages l Critical messages are digitally signed

8. 8 Helpers v Shib Handle Requestor (SHIRE) l Dynamically generated indexical reference to User v Where Are You From (WAYF) server l May be a third party (Club Shib) service v Local User Handle Server (HS) l Provides dynamic, anonymous query handle v Local campus authentication mechanism l WebLogin with PubCookie or PKI or UID/Pwd …

9. 9 Shibboleth Message Flows

10. 10 Some Interesting Issues v Who do you trust? l More properly - “How much trust do you require?” l SHAR must trust AA and vice versa s Probably requires an out of band agreement l Does the SHIRE trust the HS? s Club Shib could broker this trust l Club Shib may be a set of rules of the game v How do Users specify attribute release policy? l It’s hard enough for the experts to do it…

11. 11 Shibboleth Summary v Leverage existing authentication methods l Including PKI v Inherent controlled release of User information l User privacy, FERPA, HIPAA, etc. … v A step towards the broader use of PKI l Reference implementations will be made available l Content providers are early “target of opportunity” v See http://middleware.internet2.edu/shibboleth/ http://middleware.internet2.edu/shibboleth/

12. 12 Shibboleth Status v Specification document in final draft v Coding to begin “any day now” l IBM is interesting in the coding v Demo prototype at I2 Fall meeting l If all goes well l Hope to get at least one content provider involved v Interest from JA-SIG uPortal, others …