Embed Size (px)
Citation preview
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
…
Contributors
• Ian Taylor • Rupert Berk • Ann Testroet • Heidi Berrysmith
• Gabe Florentino • Alexis Raphael • Tracy Monaghan• Advisory
Committee
