ASTRA Authorization Management at the University of Washington Rupert Berk ([email protected])...
-
Upload
blaze-marshall -
Category
Documents
-
view
215 -
download
0
Transcript of ASTRA Authorization Management at the University of Washington Rupert Berk ([email protected])...
ASTRA
Authorization Management at the University of Washington
Rupert Berk ([email protected])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/