1. CUMREC, 2004 Copyright: Ian Taylor, Rupert Berk, Heidi Berrysmith; 2004. This work is the intellectual property of the authors. Permission is granted for this material to be shared for non- commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

2. After Pubcookie, Now What? The Authorization Layer at the University of Washington Ian Taylor, Rupert Berk, Heidi Berrysmith

3. Pubcookie Single sign-on to all Web resources a.k.a. WebISO http://www.pubcookie.org/

4. University of Washington Public research institution 3 campuses Student Enrollment (Autumn 2003) of 42,757 (39,136 on Seattle campus) 23,462 Faculty and Staff Decentralized administration No mandating of standard authorization practices No Office of Access & Data Management

5. Authorization history Scores of administrative applications Most created by Computing & Communications Dating from 1970 & each decade since As the technology changed, new applications tended to re-invent Authorization Result: multitudes of mechanisms & procedures Headaches for Administrators & others Now: vendor apps increasingly popular…

6. Integrated Authorization Project Goals: Coherent Authorization mechanism Central system Distributed management Single point of entry on the web

7. Integrated Authorization Project Timeline August 2000: Integrated Authorization Project kickoff IAP Planning Group: visions, rules, designs, 9 months. May 2001: First developer hired... September 2002: Second developer hired... Result: ASTRA: Access to Systems, Tools, Resources and Applications January 2003: ASTRA v. 1.00.00 released to production

8. ASTRA Approach to Development Meet the local needs first; dont ignore approaches and solutions at other institutions Take an incremental, stepping-stone approach Continue to respond to the changing needs of the community of users (application developers, campus users, etc.)

9. ASTRA Authority Attributes Initial Theory –Party –Domain (affiliation) –Role –Privilege –Action Current Practice –Party –Privilege (application) –Role –Action –Span of Control –Qualifier

10. ASTRA Concepts & Rules An Attribute Authority service Consuming applications No self-authorization allowed Distributed Management of Authorization –User: uses the consuming application –Authorizer: uses ASTRA to create Users –Delegator: uses ASTRA to create Authorizers Post Entry Review Messages (PERMs)

11. ASTRA Concepts & Rules Complete history of authorization activity preserved for an audit trail Spans of Control (access restrictions) –Budget Numbers, Payroll Unit Codes, Curriculum Codes, Facility Numbers, etc. –Source is always external to ASTRA –Encourage use of shared, institutional sets of values vs. private, idiosyncratic sets

12. ASTRA Demo Over to Heidi …

13. Technical: Architecture Web user interface –Microsoft ASP –J++ COM+ Data store –SQL Server APIs –Campus-wide Web service (.NET) –Trusted server farm environment COM.NET/COM+ Batch export

14. Technical : Architecture

15. Technical: APIs

16. Technical: Security User Authentication –PubCookie (Authentication Service) –Two-factor authentication (SecurID) required by web interface Application Authentication –X.509 certificate authentication required by web service (UWSCA) –Domain name authentication required by COM+ API Applications retrieve only data to which they are authorized

17. Technical: Performance Performance is sufficient for now Recommended usage of ASTRA service: one request per user session. Applications are asked to cache that data. Future: Push authorization data to an LDAP store for improved speed and availability

18. What Did it Take to build ASTRA? Resources, effort, staffing –1-3 developers –1 part-time project manager –1 part-time business analyst –1 very part-time UI designer Infrastructural support: System and DB administration provided Funding

19. What Did it Take to implement ASTRA? High level buy-in from the Administration Training: jointly with Application Client Support teams ASTRA Client Support: low level of activity Empowerment and education: rights and responsibilities of Authorizers/Delegators Open Door Approach: invite & encourage applications to participate

20. Lessons learned Evolutionary path, incremental development, adaptive approach: this works Dont let the technology overwhelm the business realities (e.g. the Roles issue) Sell the big picture and the long-term perspective to application developers Authorization is difficult to talk about Need successful partnerships

21. Results After 15 months in production, 8 client applications –In active development: 3 –In discussion: 15 –Prospective: 14 6 Delegators 314 Authorizers 4464 Users

23. Benefits No attempt yet to measure cost or time savings Developers: no need to invent access control for their applications Administrators: single point of entry, more control, more visibility of authorizations University enterprise: auditable, accessible data Future: Personalized MyWork portal

24. The Future So bright … More consuming applications More application features Shibboleth, and so on …

25. Contacts and Resources www.washington.edu/computing/astra astra@washington.edu

26. Contributors Ian Taylor Rupert Berk Ann Testroet Heidi Berrysmith Gabe Florentino Alexis Raphael Tracy Monaghan Advisory Committee