Authority Management Systems

1. 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

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

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

4. MACE vs. The Authority Management Problem

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

6. Models: MIT Roles DB AuthZWhy Qualifiers? • Often a person is authorized to perform a function only within an org. area (school, dept., lab, etc.) or within a financial area

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.

8. Stanford Authority Registry

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

10. 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.

11. Ponder from Imperial College, London Entering the Space Age Example domain expression: /A/B/D

12. Ponder

13. Ponder

14. Ponder

15. Ponder download and further information • The Ponder toolkit can be downloaded under a GNU Lesser GPL from Imperial College in London: http://www-dse .doc.ic.ac.uk/Research/policies/index.shtml • Documentation plus several technical papers on Ponder are available at that site as well

16. National Institute of Standards & Technology RBAC Model • Role-based Access Control (RBAC) formal model with provable properties • http://csrc.nist.gov/rbac/

17. Example: Bank Role/Role Associations In NIST RBAC Model

18. 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

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

20. 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

21. A key point of difference between these systems: • They all group objects to create scalable, manageable systems • But each model aggregates at different points:

22. Interop challenge: Gateway(?) for mobile authority information / assertions / policy AGE • 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)

23. Building An Access Token From A Kerberos Ticket • Local Sec Authority buildsaccess token for security context • Server thread impersonates client context Impersonation token Token Server application • Kerberos package gets auth data from session ticket LSA Kerberos • Auth data: • User SID • Group SIDs • Privileges Target Session ticket

24. 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

25. 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