ASTRA

1
ASTRA

• Authorization Management at the University of
  Washington
• Rupert Berk (rberk_at_u.washington.edu)Lead,
  Security Middleware
• CAMP, Denver, June 27, 2005

2
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

3
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

4
Goals

• Coherent authorization mechanisms
• One central authorization system
• One Web-based User Interface
• Distributed management

5
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

6
Auth management is happening
7
Auth management is happening

• Academic advising
• E-Procurement
• Grants
• Financial desktop
• Facilities
• Space inventory
• Time and leave
• Payroll update
• Time schedule update

8
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

9
Attribute Authority

• Policy decisions handled in the consuming
  application
• Attributes
• application
• role
• action
• span-of-control
• Hierarchical
• Extensible

10
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
11
Authorization Example
XML auth returned by the ASTRA web service
12
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

13
Span-of-Control Examples

• Budget Code
• Organization Code
• Payroll Unit Code
• Facility Number
• Facility Type
• Dollar Limit

• College
• Department
• Major
• Curriculum
• Program

14
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

15
Distributed Management

• ASTRA roles (populations)
• User
• Authorizer
• Delegator
• Super-Delegator

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

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

18
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

19
ASTRA User Interface
20
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

21
Technical Authentication
22
Technical Delivery of Attributes

• APIs
• Web Service (departmental apps)
• COM (some central apps)
• Batch Provisioning
• Nightly
• Driven by increasing use of vendor packages

23
Technical Delivery of Attributes
24
Benefits

• Visibility Administrators can now see who can do
  what
• With distributed management, administrators keep
  the authorizations more current and accurate
• Application teams dont have to create one-off
  authorization solutions
• Single, consistent interface for administrators

25
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
  cant 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 EVPs backing

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

27
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. whos a
  PI?
• Blurring of lines between group and role e.g.
  Benefits Office

28
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

29
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 (?)

30
Resources

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