Authorization: Welcome to the Funhouse RL “Bob” Morgan, University of Washington Internet2/Educause Advanced CAMP Boulder, Colorado July 2003

Copyright RL ‘Bob’ Morgan, This work is the intellectual property of the author. 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.

Topics Authorization challenges Authorization models Campus example(s)

Authorization defined A high-level definition: “configuration and operation of systems so actions in support of organization goals are permitted and other actions are prohibited” representation and enforcement of organizational policy in software “organizational” policy includes personal policy, e.g.: set my calendar so colleague can see it Authorization phases/components policy expression (aka authorization data management) decision-related data gathering and transformation request evaluation, decision enforcement

Authz challenges Requirements advancing in all directions more systems, more functions, more users more fundamental processes automated, more interconnection Where is the pain today? (a partial list...) too much work to establish/remove services, user permissions shared userids to work around authz failures each new app requires too much analysis policies hidden in system-specific expressions management of authority itself is mysterious multi-campus/extra-campus reqs reveal internal assumptions

Authorization infrastructure? Obvious benefits to some kinds of infrastructure ubiquitous IP networking (but: firewalls, NATs...) authentication service database/data-management web UI/front-end But authorization infrastructure seems slipperier few successful examples application structures, requirements are diverse models, terms, concepts don't seem universal how do we assess benefits of infrastructure?

Policy expressions Policy expressions are at many levels of abstraction organizational goals, guidelines, compliance rules per-system operational policies and business rules atomic per-resource controls expressions at different levels of abstraction often contribute to single access control decision An authorization infrastructure success metric: how much human effort and elapsed time does it take to implement a high-level policy change

Policy translation In simple terms... machine-processable policy is expressed at some level of abstraction and this policy is used when evaluating requests at run-time but this is only in the simplest of cases –eg, “give user X access to this file” Typically policy translation happens often by ad-hoc human processes sometimes by various semi-connected automated processes sometimes at run-time by decision function often translated intermediate forms are the stuff of authz data mgt

PEP-PDP Model Policy Enforcement Point Policy Decision Point Request Resource Decision Request Decision Response Policy Store(s) Attribute Store(s) Context

Authz API Model

Provisioning Model If apps/systems aren't structured to rely on external services, then “provision” them i.e., jam policy/settings into slots where app expects them implies “adapter” component of central service to translate central policy expressions to application format implies turning off application-internal knobs often associated with “metadirectory”-style central service

Role-based Access Control (RBAC) “Role” organizationally... job function in organizational context with rights/responsibilities and identified role occupants “Role” as data structure associated with users/subjects associated with system/object permissions associated with other roles (hierarchically or otherwise) RBAC is about managing policy expressions... and is often deployed in provisioning model

Group management For many loosely-coupled apps, “groups” service is seen as the useful central service more generally, user attributes service process-driven / institutional / ad-hoc / hierarchical see mace-dir-groups work for details... appealing since apps/systems often regard resource-based policies as “internal”, and user definition as “external”

Distributed authorization How a PDP... finds policies and attributes in distributed stores validates applicability/authenticity of those policies/attributes generates “decision objects” (rights/capabilities/tokens) that can be held by untrusted parties does all this optimally / efficiently / privately How a requestor... gathers attributes, knows which to send How a resource or policy administrator... manages authority in loosely-coupled multi-authority world

Use cases from a campus Authorization infra services at U Washington: ASTRA: administrative applications policy management Person Registry “authz directory” course directory white pages directory admin Windows domain groups Catalyst (LMS) groups

ASTRA Context many new independent but related administrative web-based apps –grants & contracts, salary distribution, hiring, time reporting, etc no ERP, just “heirloom” mainframe apps for HR, finance, etc “Integrated Authorization Project” had grand scope –departmental apps, admin/academic, campus-wide roles, etc –but we weren't ready for that level of infrastructure Design goals support central repository of per-app, per-user permissions common web UI for admins of all apps support standard central admin app environment (Windows-based)

ASTRA, cont'd Limitations no aggregation of permissions among apps no assignment of permissions to user groups supports Windows-based apps only... but still much better than each app doing its own

Person Registry Central database of all-people-of-interest one entry per person, as much as possible represent multiple affiliations per person, with affiliation state provide access via Directory (more or less) As authz source... basic faculty/staff/student attributes (but what do affil states mean?) some murky per-source fields (major, home dept, service category) appealing because everyone's in it, more or less “department” still the slippery concept

the nice thing about directories... “authz directory” web UI for maintenance of groups in LDAP directory used internally to Computing dept “course directory” represents membership of students in courses (aka classes) primarily used by homegrown LMS “white pages directory” use it because it's there, even if it doesn't have the data you want...

Groups main central Windows domain (“Nebula”) supports user-managed groups now some 900 of them... but what do they mean, when do they go away,... Catalyst, homegrown LMS supports group defs now some 1500 of them... now exporting group defs to other systems but what do they mean, when do they go away...

Conclusions? How to proceed architecturally on campus? choose your battles don't sell complete integration, since it's unlikely seek experiments to try new approaches evaluate success, evaluate organizational costs/pain figure out what works for everyone else keep working the organizational aspects