ASTRA

Authorization Management at the University of Washington

Rupert Berk (rberk@u.washington.edu)Lead, Security MiddlewareCAMP, 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…

ASTRA Consuming ApplicationsNumber of Users, Authorizers, and Delegators By Month

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

Feb

-03

Apr

-03

Jun-

03

Aug

-03

Oct

-03

Dec

-03

Feb

-04

Apr

-04

Jun-

04

Aug

-04

Oct

-04

Dec

-04

Feb

-05

Apr

-05

Delegators

Authorizers

Users

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

Grantor Mary

Grantee John

Application My Financial Desktop

Role Designee

Action Inquire

Span-of-Control Budget: 123456

Effective Begin Date 07/01/2005

Effective End Date 06/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 $500-1000; $1000-

2000

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

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

Co

nsu

min

g W

eb

Ap

plic

atio

n

UWNetid/Password

ASTRA Service

We

b S

erv

er UWNetid

ConsumingApplication

User

ConsumingApplicationAuthorizer

Client Browser

ConsumingApplicationDelegator

Client Browser

Client Browser

ASTRADB

Pu

bC

oo

kie

We

b S

erv

er

Pu

bC

oo

kie

AS

TR

A W

eb

Ap

plic

atio

n

UWNetid/Password/

Securid

UWNetid/Password/

Securid

UWNetid

App Credential(certificate)UWNetid

AUTHENTICATION AUTHORIZATION

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

ASTRA WebService

SSL

AstraProvider(.NET) AstraDB

Computing & Communications Server Farm Trust Environment

ET

L (B

atch

)

IAP_AuthCom(COM)

ConsumingApplication

1

32 4

ConsumingApplication

ConsumingApplication

ConsumingApplication

UWSCACertificate

UW Campus

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

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