1 / 30

ASTRA

ASTRA. Authorization Management at the University of Washington Rupert Berk (rberk@u.washington.edu) Lead, Security Middleware CAMP, Denver, June 27, 2005. Public research institution 3 campuses Student Enrollment (Autumn 2004) of 43,619 (39,864 on Seattle campus)

dustinh
Télécharger la présentation

ASTRA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ASTRA Authorization Management at the University of Washington Rupert Berk (rberk@u.washington.edu)Lead, Security Middleware CAMP, Denver, June 27, 2005

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

  3. 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 Rationale: Why integrated authorization?

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

  5. 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 Timeline

  6. Auth management is happening…

  7. Auth management is happening… • Academic advising • E-Procurement • Grants • Financial desktop • Facilities • Space inventory • Time and leave • Payroll update • Time schedule update • …

  8. 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

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

  10. Authorization Example

  11. Authorization Example XML auth returned by the ASTRA web service

  12. 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

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

  14. 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

  15. Distributed Management • ASTRA roles (“populations”) • User • Authorizer • Delegator • Super-Delegator

  16. 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?

  17. 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

  18. 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

  19. ASTRA User Interface

  20. 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

  21. Technical: Authentication

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

  23. Technical: Delivery of Attributes

  24. 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

  25. 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

  26. 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) • …

  27. 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

  28. 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

  29. 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 (?)

  30. Resources • http://www.washington.edu/computing/astra/

More Related