Authorization Management at the University of Washington

1. Authorization Management at the University of Washington Rupert Berk (rberk@u.washington.edu)Lead, Security MiddlewareCAMP, Denver, November 8, 2006

2. Institutional Context • Public research institution • 3 campuses • Student Enrollment (Autumn 2006) of 44,221 (40,216 on Seattle campus) • 27,203Faculty and Staff (Autumn 2005) • Decentralized administration • No mandating of standard authorization practices • No Office of Access & Data Management

3. Technology Context • Decision to invest in Heritage applications rather than ERP • Mostly custom web apps, often front-ends to Heritage Systems • Scores of administrative applications often with differing authorization mechanisms and procedures

4. Rationale: Why integrated authorization? • Delay between request for access and implementation of access • Inconsistency in creation of privileges • Problems of over-privileging • Lack of visibility as to who can do what • Frustration for administrators and others

5. Goal Appropriate access in a timely manner

6. Proposal • Single, coherent, web-based management UI • Distributed management

7. ASTRA • “Access to Systems, Tools, Resources, and Applications” • v1.0 released to production in January, 2003 • Using ASTRA, 500 Authorizers manage 95,000 authorizations for 9,600 people • 19 mostly home-grown applications

8. Overview: How it works 1 Sally gets a notification from ASTRA that she has been given access ASTRA DB Mary, an administrator for the Medical Genetics Unit, uses ASTRA to give Sally access to the Financial Desktop application (FD) FD applies its authority POLICY based on the authorizations returned from ASTRA and renders appropriate screens for Sally; FD caches Sally’s auths for an appropriate amount of time FD requests Sally’s authority for FD from ASTRA Sally logs into FD via the UW Web Login service (SSO) using her UW NetID 2 ASTRA Service 5 4 3 ASTRA authorizes FD and returns current FD authorizations for Sally 6

9. Business Rules • Post-entry notifications to grantor and grantee, etc. • No restriction to whom you can give access -- only that the grantee has a UW NetID • Regular status reminders; no automated de-provisioning • Open-books visibility for ASTRA Authorizers and Delegators (currently, authorizations not public; this policy will be reviewed again) • No roll-up of privileges within ASTRA roles e.g. Authorizer does not get User privileges • No self-authorization (audit control)

10. Distributed Management • Distributed management  timely, appropriate access • Different management models for different apps: centralized – distributed continuum • If centrally managed, departmental admins can see what people have and request changes • Future: Approval feature desired by Registrar for some SIS systems

11. Distributed Management: Chain of Command

12. Distributed Management: Ownership • Authority is not tied to authority of the creator • List authorizations you created • Assume responsibility for authorizations someone else created

13. Integration Effort • Most of the development work falls on application teams with ASTRA developers working as consultants • So far, the design has been flexible enough to handle new applications • Challenge: selling the integration to some application teams • Strategy: engage application teams as early in design process as possible, often during build/buy analysis

14. Integration Requirements: API • Web Service (3 applications) • Central IT as well as departmental • X509 Certificate issued by UWCA (Application-specific certs for our shared server farm) • .NET/COM (15 applications) • Use limited to Central IT / Admin Systems • Windows Domain Accounts • Batch provisioning (1 vendor package) • SQL tables • Not a sustainable model – plan is to push these consumers to Web Service

15. AuthZ Elements

16. AuthZ Elements: XML

17. AuthZ Elements: UI

18. AuthZ Element: ASTRA Role/Population • Limited, but sufficient (so far) chain • User • Authorizer • Delegator • Delegator  Authorizer  User • No rollup of permissions; separation of responsibility for audit control • You give something different from what you might have • e.g. I can make you a user of the system without being a user myself • The higher up the chain, the less people wanted the ability to DO • Currently, our API only exposes “User” authorizations, but there is a demand for the rest of the chain, and it will be exposed in the near future • Approval Routing: automated requests to admins requesting they assign people to an approval graph

19. AuthZ Element: Party • Currently, party must have a UW NetID, and consequently a record in our registry • 9,600 UW NetID’s currently managed • Group? • Application?

20. Auth Element: Environment • Multiple environments: dev, eval, train, prod • Different rules in different environments • You can self-authorize in dev, eval • Changes in dev, eval, train don’t generate user notifications • v.2 enhancement • Separate development paths • “Production” standards for pre-production environments

21. Financial Desktop Grants Management Procurement Payroll Work-Leave Course Timetable Space Inventory Equipment Insurance Facilities Work Request … AuthZ Element: Application • ASTRA currently deals with access to administrative applications, not services such as email, file systems, etc.

22. Examples: Principal Investigator Approver Budget Coordinator Student Advisor Helpdesk Timekeeper Payroll Coordinator Dean AuthZ Element: Role

23. AuthZ Element: Role • Desire for cross-application roles • In practice, however, not many agreed-upon, well-managed roles emerged; • Without management of roles, applications invented their own roles • In ASTRA v.2, we are attempting a “role reversal”, and making it possible to define cross-application roles. The challenge will be the management of these roles

24. AuthZ Element: Span-of-Control • Resource, scope, restriction, limit • “what you can act upon” • Flexible, extensible • Mostly institutional vs. idiosyncratic values • Foreign keys to data sources elsewhere • Mostly nightly synchronization of values, some real-time • Local cache needed for efficient display and validation

25. Budget Code Organization Code Payroll Unit Code Facility Number Facility Type Dollar Limit College (SIS) Department (SIS) Major (SIS) Curriculum (SIS) Program (SIS) Span-of-Control: Examples

26. Span-of-Control: Hierarchies • Hierarchies • Convenience: Allows Authorizers to have single parent value, yet assign multiple child values • Examples • Organization Code (6 levels) • Organization/Budget • Facility Type/Facility Number • College/Dept/Major/Curriculum • Ranges • Parent values that give access to a range of child values. • Only store a single value • BUT we have single values such as $500-1000; $1000-2000

27. AuthZ Element: Effective Dates • Currently, revocation of privileges is manual, a responsibility of the Authorizer • We don’t yet have an easy trigger for automated de-provisioning • Focus has been on regular reminders

28. AuthZ Elements: Flexible Model • Application1 • Role1 • Action1 • Span-of-control type1: value • Span-of-control type2: value • … • Span-of-control type<n>: value • … • Action<n> • … • Role<n>

29. AuthZ Elements: Standardization • In decentralized environment, applications get developed with little coordination between app teams • Standardization adds coherence for Users • ASTRA is positioned at a point to see how to simplify & rationalize the management of authority across applications • Resistance by app teams to “policing” • Must repeatedly sell the Middleware vision and end-user benefit

30. AuthZ Elements: Standardization • Standardization  visibility  appropriate access • Allows questions such as “who has access to my stuff?” • The focus of development efforts for ASTRA v.2 has been to improve visibility into the 95,000 authorizations by improve search features

31. Other ways to create authorizations • Proxy • The higher a person is organizationally (e.g. Dean), the less likely she is to use a system like this; hence, a need for someone else to “make it so” • Authority seeded outside of system (emails, memos) • Batch process • Authorizations created from System of Record • Authorizations generated nightly based on system of record: PI’s are given access to their budgets • Agreement must be established regarding new use of source data and management responsibilities • Positive result of new visibility: better maintenance of source data • Future: Reflect authority managed by other systems in ASTRA

32. Visibility: Audit value • Some departments have policies to save/print emails of access requests and access changes; sometimes there is no record • The more this information can be recorded within a system, the more visible and the more auditable • We ask application teams to create a unlimited read only privilege for an Auditor role

33. Benefits • Application teams don’t have to create one-off authorization solutions • Visibility: Administrators can now see who can do what, even when they can’t make changes • Auditability: Auditors like it • With distributed management, administrators keep the authorizations more current and accurate • Single, consistent interface for administrators

34. Future work • Feature: Request for access • Feature: Approval Routing • Feature: Identify my people • Integrate with Groups Directory? • Integrate more applications (Heritage work underway) • Integrate with other services • Reflect Authorizations in Enterprise Directory?

35. Resources http://www.washington.edu/computing/astra/