Скачать презентацию Authorization Management at the University of Washington Rupert Скачать презентацию Authorization Management at the University of Washington Rupert

5c09a37f4391703f7c407c781ff62518.ppt

  • Количество слайдов: 35

Authorization Management at the University of Washington Rupert Berk (rberk@u. washington. edu) Lead, Security Authorization Management at the University of Washington Rupert Berk ([email protected] washington. edu) Lead, Security Middleware CAMP, Denver, November 8, 2006

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

Technology Context • Decision to invest in Heritage applications rather than ERP • Mostly 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

Rationale: Why integrated authorization? • Delay between request for access and implementation of access 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

Goal Appropriate access in a timely manner Goal Appropriate access in a timely manner

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

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

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

Business Rules • Post-entry notifications to grantor and grantee, etc. • No restriction to 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 Net. ID • 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)

Distributed Management • Distributed management timely, appropriate access • Different management models for different 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

Distributed Management: Chain of Command Distributed Management: Chain of Command

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

Integration Effort • Most of the development work falls on application teams with ASTRA 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

Integration Requirements: API • Web Service (3 applications) – Central IT as well as Integration Requirements: API • Web Service (3 applications) – Central IT as well as departmental – X 509 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

Auth. Z Elements Grantee Rupert Grantor is authorized by Mary ASTRA Role as a Auth. Z Elements Grantee Rupert Grantor is authorized by Mary ASTRA Role as a USER Application of Financial Desktop Role in the role of Budget Coordinator Action with an action of Inquire Environment in the production environment Span-of-Control on Budget 123456 Effective Dates from 07/01/2006 to 12/31/2006

Auth. Z Elements: XML Auth. Z Elements: XML

Auth. Z Elements: UI Auth. Z Elements: UI

Auth. Z Element: ASTRA Role/Population • Limited, but sufficient (so far) chain – User Auth. Z 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

Auth. Z Element: Party • Currently, party must have a UW Net. ID, and Auth. Z Element: Party • Currently, party must have a UW Net. ID, and consequently a record in our registry • 9, 600 UW Net. ID’s currently managed • Group? • Application?

Auth Element: Environment • Multiple environments: dev, eval, train, prod • Different rules in 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

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

Auth. Z Element: Role Examples: • Principal Investigator • Approver • Budget Coordinator • Auth. Z Element: Role Examples: • Principal Investigator • Approver • Budget Coordinator • Student Advisor • • Helpdesk Timekeeper Payroll Coordinator Dean

Auth. Z Element: Role • Desire for cross-application roles • In practice, however, not Auth. Z 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

Auth. Z Element: Span-of-Control • • • Resource, scope, restriction, limit “what you can Auth. Z 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 realtime • Local cache needed for efficient display and validation

Span-of-Control: Examples • • • Budget Code Organization Code Payroll Unit Code Facility Number Span-of-Control: Examples • • • 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: Hierarchies • Convenience: Allows Authorizers to have single parent value, yet assign multiple Span-of-Control: 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

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

Auth. Z Elements: Flexible Model • Application 1 – Role 1 • Action 1 Auth. Z Elements: Flexible Model • Application 1 – Role 1 • Action 1 – – Span-of-control type 1: value Span-of-control type 2: value … Span-of-control type: value • … • Action – … – Role

Auth. Z Elements: Standardization • In decentralized environment, applications get developed with little coordination Auth. Z 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

Auth. Z Elements: Standardization • Standardization visibility appropriate access • Allows questions such as Auth. Z 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

Other ways to create authorizations Proxy • The higher a person is organizationally (e. 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

Visibility: Audit value • Some departments have policies to save/print emails of access requests 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

Benefits • Application teams don’t have to create one-off authorization solutions • Visibility: Administrators 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

Future work • • • Feature: Request for access Feature: Approval Routing Feature: Identify 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?

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