Authorization Management at the

University of WashingtonRupert Berk

(rberk@u.washington.edu)Lead, Security Middleware

CAMP, Denver, November 8, 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 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

• 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

Proposal

• Single, coherent, web-based management UI

• Distributed management

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

Overview: How it works

ClientSallyFinancial

Desktop User

MaryASTRA User

Client

ASTRA Web App

Financial Desktop Web App

ASTRA Service

ASTRADB

1

54

2

6

3

Sally gets a notification from ASTRA that she has been given access

Sally logs into FD via the UW Web Login service (SSO) using her UW NetID

FD requests Sally’s authority for FD from ASTRA

ASTRA authorizes FD and returns current FD authorizations for Sally

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

Mary, an administrator for the Medical Genetics Unit, uses ASTRA to give Sally access to the Financial Desktop application (FD)

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)

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

Authorizer UserDelegator

Authorizing Agent

ASTRAASTRA

Consuming App

EVP/Provost

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

AuthZ ElementsGrantee 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

AuthZ Elements: XML

AuthZ Elements: UI

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

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?

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

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

AuthZ Element: Role

Examples:• Principal

Investigator• Approver• Budget

Coordinator• Student Advisor

• Helpdesk• Timekeeper• Payroll

Coordinator• Dean

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

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

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: HierarchiesHierarchies

• 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

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

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>

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

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

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 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 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 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/