ASTRA Authorization Management at the University of Washington Rupert Berk Lead, Security Middleware CAMP, Denver, June 27, 2005

Context: University of Washington  Public research institution  3 campuses  Student Enrollment (Autumn 2004) of 43,619 (39,864 on Seattle campus)  27,228 Faculty and Staff  Decentralized administration  No mandating of standard authorization practices  No Office of Access & Data Management

Rationale: Why integrated authorization?  Scores of administrative applications, dating from 1970's, often with differing authorization mechanisms and procedures  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

Goals  Coherent authorization mechanisms  One central authorization system  One Web-based User Interface  Distributed management

Timeline  Aug 2000 : “Integrated Authorization Project” Kickoff  May 2001 : First developer hired  Sep 2002 : Second Developer hired  Jan 2003 : ASTRA v.1.0 released to production “Access to Systems, Tools, Resources, and Applications”  Jan 2004 : Security Middleware formed  Jan 2005 : Formal delegation initiated

Auth management is happening…

 Academic advising  E-Procurement  Grants  Financial desktop  Facilities  Space inventory  Time and leave  Payroll update  Time schedule update  …

Integration with UWNetid system  All ASTRA authorizations require a UWNetid  Relies upon authentication via another system  Currently all apps are web apps and use our WebISO (PubCookie) for authentication

Attribute Authority  Policy decisions handled in the consuming application  Attributes  application  role  action  span-of-control  Hierarchical  Extensible

Authorization Example GrantorMary GranteeJohn ApplicationMy Financial Desktop RoleDesignee ActionInquire Span-of-ControlBudget: Effective Begin Date07/01/2005 Effective End Date06/31/2006

Authorization Example XML auth returned by the ASTRA web service

Span-of-Control  Resource, scope, context, access restriction  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

Span-of-Control: Examples  Budget Code  Organization Code  Payroll Unit Code  Facility Number  Facility Type  Dollar Limit  College  Department  Major  Curriculum  Program

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 $ ; $

Distributed Management  ASTRA roles (“populations”)  User  Authorizer  Delegator  Super-Delegator

Distributed Management  Differential models of management  Centralized works well for many small apps  Centralized can be a starting point for distributed  For large, widely distributed apps, distributed management makes sense  Concerted effort to identify authority at the UW  Authority seeded retroactively by EVP and Provost  Overlap with Org Chart?

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 ( s, 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

Business Rules  No self-authorization (audit control)  Post-entry review memos (PERM's) vs. approval-routing  Audit Trail  No restriction on whom you can give access to... only that they have a UWNetid  No automated de-provisioning; no lockout; separation causes notification to authorizer and, possibly, delegator  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

ASTRA User Interface

Technical: Authentication  User Authentication to ASTRA Web UI  PubCookie (WebISO Service)  Two-factor authentication (SecurID token)  Application Authentication to ASTRA service  X.509 certificate authentication required by web service (UWSCA) OR  Domain name authentication required by COM+ API

Technical: Authentication

Technical: Delivery of Attributes  API’s  Web Service (departmental apps)  COM (some central apps)  Batch Provisioning  Nightly  Driven by increasing use of vendor packages

Technical: Delivery of Attributes

Benefits  Visibility: Administrators can now see who can do what  With distributed management, administrators keep the authorizations more current and accurate  Application teams don’t have to create one-off authorization solutions  Single, consistent interface for administrators

Lessons learned  Administrators like it  Demand for more applications (esp. Heritage)  Demand for more features  Support cost of distributed management  Training and support model requires cooperation: where is the division of responsibility? “Why can’t she access …?”  Hard to talk about e.g. delegation/authorization  Technical support e.g. browser issues  Importance of high-level support  Delegation with and without the EVP’s backing

Lessons learned  Challenges of centralization and standardization  Differential use of attributes  Why care about standardization of attribute values?  Spans-of-control  Cleansing of institutional values  Example: Organization Codes (source, downstream pollution)  Example: Budget Codes (3 kinds due to uniqueness problem)  …

Lessons learned  Challenges of centralization and standardization  Roles  Archetype: Payroll Coordinator  Other promising candidates: Budget Coordinator, Academic Advisor, Timekeeper, Principal Investigator  In reality, not many agreed-upon, well-managed roles  Problems with sharing authorizations e.g. who’s a PI?  Blurring of lines between group and role e.g. Benefits Office

Lessons learned  Challenges of centralization and standardization (cont)  Resistance from application teams: Luddites?  Example: Budget Coordinator  Sell the “Middleware vision” repeatedly  Engage early with business clients and developers  Keep the technology accessible  Web Service usage with X509 certificates

Future work  More granular inquiries (in progress)  Access Request Process / Approval Routing  Integration with Heritage Applications  Integration with group service  Integration with Shibboleth  Integration with our Enterprise Directory Service  Integration with organizational registry (?)  Collaborate with other Institutions (?)

Resources 