cumrec, 2004 copyright: ian taylor, rupert berk, heidi berrysmith; 2004. this work is the...

CUMREC, 2004

Copyright: Ian Taylor, Rupert Berk, Heidi Berrysmith; 2004. This work is the intellectual property of the authors. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

After Pubcookie, Now What?

The Authorization Layer at the

University of Washington

Ian Taylor, Rupert Berk, Heidi Berrysmith

Pubcookie

• Single sign-on to all Web resources• a.k.a. WebISO• http://www.pubcookie.org/

University of Washington

• Public research institution• 3 campuses• Student Enrollment (Autumn 2003) of 42,757 (39,136 on Seattle campus)• 23,462 Faculty and Staff• Decentralized administration• No mandating of standard authorization

practices• No Office of Access & Data Management

Authorization history

• Scores of administrative applications• Most created by Computing &

Communications• Dating from 1970 & each decade since• As the technology changed, new applications

tended to re-invent Authorization• Result: multitudes of mechanisms &

procedures• Headaches for Administrators & others• Now: vendor apps increasingly popular…

Integrated Authorization Project

Goals: • Coherent Authorization mechanism• Central system• Distributed management• Single point of entry on the web

Integrated Authorization Project

Timeline• August 2000: Integrated Authorization Project

kickoff• IAP Planning Group: visions, rules, designs, 9

months.• May 2001: First developer hired . . .• September 2002: Second developer hired . . .• Result: ASTRA: Access to Systems, Tools,

Resources and Applications• January 2003: ASTRA v. 1.00.00 released to

production

ASTRA Approach to Development

• Meet the local needs first; don’t ignore approaches and solutions at other institutions

• Take an incremental, stepping-stone approach

• Continue to respond to the changing needs of the community of users (application developers, campus users, etc.)

ASTRA Authority Attributes

• Initial Theory– Party– Domain

(affiliation)– Role– Privilege– Action

• Current Practice– Party– Privilege

(application)– Role– Action– Span of Control– Qualifier

ASTRA Concepts & Rules

• An Attribute Authority service• “Consuming applications”• No self-authorization allowed• Distributed Management of Authorization

– User: uses the consuming application– Authorizer: uses ASTRA to create Users– Delegator: uses ASTRA to create Authorizers

• Post Entry Review Messages (PERMs)

ASTRA Concepts & Rules

• Complete history of authorization activity preserved for an audit trail

• Spans of Control (access restrictions)– Budget Numbers, Payroll Unit Codes,

Curriculum Codes, Facility Numbers, etc.– Source is always external to ASTRA – Encourage use of shared, institutional sets

of values vs. private, idiosyncratic sets

ASTRA Demo

Over to Heidi …

Technical: Architecture

• Web user interface– Microsoft ASP– J++ COM+

• Data store– SQL Server

• API’s– Campus-wide

• Web service (.NET)– Trusted server farm environment

• COM• .NET/COM+• Batch export

Technical: Architecture

Con

sum

ing

Web

App

lica

tion

UWNetid/Password

ASTRA Service

Web

Se

rver UWNetid

ConsumingApplication

User

ConsumingApplicationAuthorizer

Client Browser

ConsumingApplicationDelegator

Client Browser

Client Browser

ASTRADB

Pub

Co

okie

Web

Se

rver

Pub

Co

okie

AS

TR

A W

ebA

pplic

atio

n

UWNetid/Password/

Securid

UWNetid/Password/

Securid

UWNetid

App Credential(certificate)UWNetid

AUTHENTICATION AUTHORIZATION

Technical: API’s

ASTRA WebService

SSL

AstraProvider(.NET) AstraDB

Computing & Communications Server Farm Trust Environment

ET

L (B

atc h

)

IAP_AuthCom(COM)

ConsumingApplication

1

32 4

ConsumingApplication

ConsumingApplication

ConsumingApplication

UWSCACertificate

UW Campus

Technical: Security

• User Authentication– PubCookie (Authentication Service)– Two-factor authentication (SecurID) required by

web interface

• Application Authentication– X.509 certificate authentication required by web

service (UWSCA)– Domain name authentication required by COM+

API

• Applications retrieve only data to which they are authorized

Technical: Performance

• Performance is sufficient for now• Recommended usage of ASTRA

service: one request per user session. Applications are asked to cache that data.

• Future: Push authorization data to an LDAP store for improved speed and availability

What Did it Take to build ASTRA?

• Resources, effort, staffing– 1-3 developers– 1 part-time project manager– 1 part-time business analyst– 1 very part-time UI designer

• Infrastructural support: System and DB administration provided

• Funding

What Did it Take to implement ASTRA?

• High level buy-in from the Administration• Training: jointly with Application Client

Support teams• ASTRA Client Support: low level of activity• Empowerment and education: rights and

responsibilities of Authorizers/Delegators• Open Door Approach: invite & encourage

applications to participate

Lessons learned

• Evolutionary path, incremental development, adaptive approach: this works

• Don’t let the technology overwhelm the business realities (e.g. the Roles issue)

• Sell the big picture and the long-term perspective to application developers

• Authorization is difficult to talk about• Need successful partnerships

Results

• After 15 months in production, 8 client applications– In active development: 3– In discussion: 15– Prospective: 14

• 6 Delegators• 314 Authorizers• 4464 Users

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

0

1000

2000

3000

4000

5000

6000

Jan-03

Feb-03

Mar-03

Apr-03

May-03

Jun-03

Jul-03

Aug-03

Sep-03

Oct-03

Nov-03

Dec-03

Jan-04

Feb-04

Mar-04

Delegators

Authorizers

Users

Benefits

• No attempt yet to measure cost or time savings

• Developers: no need to invent access control for their applications

• Administrators: single point of entry, more control, more visibility of authorizations

• University enterprise: auditable, accessible data

• Future: Personalized MyWork portal

The Future

• So bright …• More consuming

applications• More application

features• Shibboleth, and so on

…

Contacts and Resources

www.washington.edu/computing/astra

astra@washington.edu

Contributors

• Ian Taylor • Rupert Berk • Ann Testroet • Heidi Berrysmith

• Gabe Florentino • Alexis Raphael • Tracy Monaghan• Advisory

Committee