1 / 17

Authorization BOF @ GGF-6 Grid Authorization Concepts Proposed work item of Authorization WG

Authorization BOF @ 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 lgommans@science.uva.nl. Overview Why a “concepts” work item

nero
Download Presentation

Authorization BOF @ GGF-6 Grid Authorization Concepts Proposed work item of Authorization WG

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Authorization BOF @ GGF-6 Grid Authorization Concepts Proposed work item of Authorization WG Chicago, IL - Oct 15th 2002 Leon Gommans Advanced Internet Research Group University of Amsterdam lgommans@science.uva.nl

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

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

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

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

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

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

  8. Example: ISO 10181-3 Access Control Framework Initiator Target AEF Service User ADF AEF: Access Enforcement Function ADF : Access Decision Function AAA 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 ..

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

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

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

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

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

  14. Example 3: RFC 2903 Generic AAA Architecture Policy Decision 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. Policy Repository Request Decision Policy Enforcement Point The point where the policy decisions are actually enforced. Basic Goal Generic AAA: Allow policy decisions to be made by multiple PDP’s belonging to different administrative domains.

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

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

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

More Related