Authority Management Systems Keith Hazelton, Senior IT Architect, Univ. of Wisconsin-Madison Middleware Architecture Committee for Education, Internet2 Internet2 Fall Member Meeting, Los Angeles, 29-Oct-02 Keith Hazelton, Senior IT Architect, Univ. of Wisconsin-Madison Middleware Architecture Committee for Education, Internet2 Internet2 Fall Member Meeting, Los Angeles, 29-Oct-02

29-Oct-02 2 Authority Mgmt System Topics Audience: Authority Management System champions in the making – and their victims Glimpses of some real-world Authority Management Systems Dimensions of difference & similarity Interoperation of Authority Management systems

29-Oct-02 3 Focus on first of two fundamental aspects of Authorization: “Build-time:” Edit, compile, transform and propagate authority information relating to authorization & policy vs. “Run-time:” Access control decisions by resource (manager) at time of actual request based on system-specific data/processes

29-Oct-02 4 MACE vs. The Authority Management Problem

29-Oct-02 5 Models: MIT Roles DB AuthZ Triples Authorization [Authority] = Person + Function + Qualifier (for OKI, a “person” will be generalized to an “agent”) Lets someone do something somewhere: Who? =Person What? =Function Where? =Qualifier

29-Oct-02 6 Models: MIT Roles DB AuthZ Why Qualifiers? Often a person is authorized to perform a function only within an org. area (school, dept., lab, etc.) or within a financial area PERSONFUNCTIONQUALIFIER JoeReview SalariesDept. of Biology SallyCreate RequisitionsAcct FredApprove Reqs.Accts. in Biology AnnGrade StudentsCourse 6.001

29-Oct-02 7 Stanford Authority Registry An Authority Registry -- a managed repository of authority assignments -- not a run-time Access Control System. Authority is defined first in business terms, without reference to any specific system or application. The Authority Registry separates user visible portions of authority management, expressed in business terms, from internal system components expressed in technical terms. Applications must read and translate authority information into local terms.

29-Oct-02 8 Stanford Authority Registry

29-Oct-02 9 Stanford Authority Registry Functions The basic unit of Business work. A person’s job will consist of one or more Functions. Authority assignments are at the Function level. Functions consist of one or more Tasks. Tasks A discrete unit of work, typically a piece of what is needed to accomplish a function. Represents a set of privileges that must be be set together. Are reusable

29-Oct Stanford Authority Registry Entitlements Atomic unit of authority control. An abstraction of system specific privileges, but not in any system’s specific language. What applications read to set their internal security.

29-Oct Ponder from Imperial College, London Entering the Space Age Example domain expression: /A/B/D

29-Oct Ponder

29-Oct Ponder

29-Oct Ponder

29-Oct Ponder download and further information The Ponder toolkit can be downloaded under a GNU Lesser GPL from Imperial College in London: Documentation plus several technical papers on Ponder are available at that site as well

29-Oct National Institute of Standards & Technology RBAC Model Role-based Access Control (RBAC) formal model with provable properties

29-Oct Example: Bank Role/Role Associations In NIST RBAC Model

29-Oct NIST RBAC Model Reference implementation including management tools for role engineering NIST seeking to promote this as a standard: A Proposed Standard for Role-Based Access Control David F. Ferraiolo National Institute of Standards and Technology Ravi Sandhu George Mason University Serban Gavrila VDG Incorporated D. Richard Kuhn and Ramaswamy Chandramouli National Institute of Standards and Technology December 18, 2000

29-Oct UWisc Project Planning: Cascading phrases re controlled access to resources Systems of record Identify Persons Affiliations / Attributes Entitlements Services Service Providers Who have That are mapped to That determine eligibility for That are offered by

29-Oct UWisc: Separates policy from technical architecture and implementation Ask the technologists To build a system that can easily accommodate new sources, people, services & mappings. Ask the stakeholders (sponsors, service providers,…) To agree on policies & procedures in terms of this cascading diagram Yields a cleaner separation of the two activities User visible vis-à-vis system internal a la Stanford Gives the two groups a shared language

29-Oct A key point of difference between these systems: They all group objects to create scalable, manageable systems But each model aggregates at different points: MODELPOINT(S) OF AGGREGATIONExample MIT Roles DBQualifierDept. of Biology Stanford AuthorityTask, Function {, Role}Office Admin PonderSubject & Target “Domains”/faculty/physics NISTRole HierarchiesSurgeon Doctor

29-Oct Interop challenge: Gateway(?) for mobile authority information / assertions / policy SAML, XACML (Security Assertions Markup Language, eXtensible Access Control Markup Language (OASIS standards body) Permis Attribute Certificates Grid Proxy Certificates SPKI, SDSI Certificates MS Kerberos PAC (Authorization data) in Session ticket (see next slide) AGE

29-Oct Target Auth data:  User SID  Group SIDs  Privileges Kerberos LSA Session ticket Server application Building An Access Token From A Kerberos Ticket Kerberos package gets auth data from session ticket Impersonation token Token Local Sec Authority builds access token for security context Server thread impersonates client context

29-Oct Do AuthInfo systems themselves ever need to interoperate? Well, we do want low-impedance resource access across administrative boundaries But do we need to manage Authority Information across those boundaries? REALLY hard, especially if the underlying models aren’t commensurable Minimalist approach: Net out AuthorityInfo to entitlements and move entitlements between domains

29-Oct Conclusion; “Back to you, RL.” We’re still throwing a little salt, circling in the arena… But the payoff for middleware services investment really seems to lie in the authorization (authority management + access control management) space