Authorization GGF-6 Grid Authorization Concepts Proposed work item of Authorization WG Chicago, IL - Oct 15 th 2002 Leon Gommans Advanced Internet Research Group University of Amsterdam

Overview Why a “concepts” work item Similar Authorization Framework RFC2904 for sequences and show them with: Example 1: ISO Access Control Framework Example 2: PERMIS Privilige Management Infrastructure Example 3: RFC 2903 Generic AAA Architecture Conclusion

Goals of concepts workitem There are a many authorization mechanisms… One can think of a number of different classes of differences. Position current authorization mechanisms in a number classes and frameworks based on common concepts. Each class may look at different aspect of authorization for example: communication of ~, representation of ~, handling of ~, securing ~, mapping one ~ into another ~ etc. Describe a common set of issues : sequences, protocols, API’s, trust relationships, mappings, interoperability, contractual relationships, binding of AuthN and AuthZ, domains, etc. Not indented as a detailed analyses but should be adequate to make rough high level design decisions or comparisons.

Example: RFC2904 framework. Framework for authorization communication sequences, roles and functions. Originated from IRTF AAA Architecture Research Group It could be expanded into the Grid when describing authorization sequences between a number of fundamental functional roles (User, AAA entity, Service, User Home Organization etc.) Recognize more roles and functions.

RFC 2904 Generic AAA Framework basic principles 3 fundamentally different user initiated authorization sequences. Note: RFC2904 does not show step 5 – service access. Service AAA User Service AAA User Service AAA User Pull sequence NAS (remote access) RSVP (network QoS) Agent sequence Agents, Brokers, Proxy’s. Push sequence. Tokens, Tickets, AC’s etc

“Roaming” Scenario’s Separating the User Awareness from the Service yield Roaming Models: Example roaming pull model. Service AAA User AAA 3 4 User Home Organization Service Provider

Distributed Services over administrative domains Distributed Services Models allow many types and combination of authorization sequences.. Service AAA User AAA User Home Organization Service Provider A Service AAA Service Provider B AAA Client

Example: ISO Access Control Framework ADF AEF InitiatorTarget AAA Service AEF: Access Enforcement Function ADF : Access Decision Function The dotted boxes are not defined in the ISO framework, but doing so, it may be made to look like the RFC 2904 pull model but also.. User

ISO ADF Target AAA Service AEF: Access Enforcement Function ADF : Access Decision Function.. the RFC 2904 agent model depending in which box you implement enforcement function. Initiator AEF User

Example 2: PERMIS Slides provided by Prof. David Chadwick IS Institute University of Salford, UK

ADF The PERMIS PMI API User Target Submit Access Request Present Access Request Decision Request Decision Retrieve Policy and Role ACs AEF Authentication Service Application Gateway LDAP Directories Source: Dave Chadwick – University of Salford AAA Agent model Service

Features Permis is a Policy driven Role Based Access Control (RBAC) Privilege Management Infrastructure (PMI). Policy is written in XML and stored in a policy X.509 attribute certificates (AC) in the local LDAP directory Credentials (roles) are stored in X.509 AC may be widely distributed Access Control Decision Function (ADF) with 3 simple calls and a constructor: GetCreds, Decision, Finalise –This increases performance for multiple actions per user –It also allows the dynamic changing of the policy Is authentication agnostic. Any mechanism can be used e.g. Kerberos, Un/Pw, digital certificates. The ADF only needs the DN of the authenticated user Source: Dave Chadwick – University of Salford

Supports Push or Pull Modes In pull mode the X.509 ACs are stored in multiple LDAP directories and automatically retrieved by the ADF. This allows the distributed management of roles –Note. To remove a privilege the corresponding X.509 AC needs to be deleted from the LDAP directory In push mode the Application (AEF) passes the X.509 ACs to the ADF. This allows the user to exercise privacy. –Note. ACRLs are not yet supported by the ADF so this mode may be less secure than pull. We currently have a research bid to add this feature Source: Dave Chadwick – University of Salford

Example 3: RFC 2903 Generic AAA Architecture Policy Decision Point Policy Enforcement Point Fundamental idea’s inspired by work of the IETF RAP WG that in RFC 2753 describes a framework for Policy-based Admission Control. Foundation for COPS The point where policy decisions are made. The point where the policy decisions are actually enforced. Request Decision Policy Repository Basic Goal Generic AAA: Allow policy decisions to be made by multiple PDP’s belonging to different administrative domains.

Generic AAA Architecture Application Specific Module Policy Enforcement Point Rule Based Engine Policy Repository PDP = AAA entity Archieve goal by by separating the logical decision process from the application specific parts within the PDP. User * Sequences depend on model described in RFC 2904 and are implemented using some or API * ** Service

Example of Generic AAA Architecture – RFC2903 Application Specific Module Bandwidth Broker Rule Based Engine Policy Repository Application Specific Module Rule Based Engine Policy Repository Users Application Specific Module Rule Based Engine Policy Repository Contracts Budgets Registration Dept.Purchase Dept. Bandwidth Provider AAA Server AAA Server AAA Server (Virtual) User Organization QoS Enabled Network User Service Service Organization

Conclusions Concepts (chapter in) document intended to help get a better (overall) picture. Needs to include existing and emerging (OGSA) mechanisms. It observes and recognizes but does not specify anything. RFC 2904 could be expanded for describing sequences. Other frameworks are needed.