1 / 11

Enhancing Authorization with AzApi: A Comprehensive Overview of XACML Capabilities

This document outlines AzApi, developed to integrate XACML capabilities into the general authorization environment. It aims to simplify the addition of a XACML PDP, unify the authorization framework, and separate applications from technical infrastructure complexities. By leveraging existing authorization provider infrastructure, AzApi addresses gaps observed during the 2008 RSA Interop show. Key concepts include the super-set capabilities of XACML and its main use cases, including Policy Enforcement Points (PEPs) and Policy Information Points (PIPs). This comprehensive guide also highlights AzApi's architecture and next steps for open-source development.

tommy
Download Presentation

Enhancing Authorization with AzApi: A Comprehensive Overview of XACML Capabilities

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. Introduction to AzApi July 30, 2009

  2. Motivation • Provide XACML capabilities to the general authorization (az) environment • Make it easy to add a XACML PDP • Unify the general az environment • Separate applications from any technical details of az infrastructure • Capitalize current investment by building around existing az provider infrastructure • 2008 RSA Interop showed lack of available solns to address this area –adhoc soln needed to be built

  3. Key Concepts 1 • XACML is generally a superset of existing az provider functionality • XACML Request/Response API is generally a superset of existing az APIs (checkPermission, isAccessAllowed, others) • XACML PDP is superset of policy capabilities of existing az Providers • Az providers generally provide an SPI for enhanced/alternative providers

  4. Key Concepts 2 • Authorization basically reduces down to evaluating a set of Attributes • APIs and SPIs only need to pass Attributes • XACML representation of Attributes is general enough to map to and from existing APIs and SPIs

  5. AzApi use cases • PEP: AzApi used to build PEP within container to issue az requests for container or for application • PIP: AzApi used to obtain Attributes (tbd) • PDP: AzApi used to enhance functionality of existing az providers

  6. Application Container / Platform Container Controlled Application Access (PEP) Container Provided Application Services (Files, Externals, …) Application AzApi: XACML Upper Level (PEP) Platform Az API (checkPermission, isAccessAllowed, …) Built-in Platform Az Provider Platform Az SPI (Policy.implies, AccessDec.isAccAllowed, …) Extended Platform Az Provider AzApi: XACML Lower Level (PEP) Internal XACML PDP AzProvider External XACML PDP AzProvider AzApi Architecture

  7. Architecture Diagram Notes • Arrows represent possible call/return paths • The “red” XACML AzApi represents the places where modules can be placed. • The arrow joining upper and lower AzApi represents a direct path to XACML PDP w no building around existing az provider. • Removing the “red C” effectively is where things are today w/o AzApi.

  8. What’s in AzApi (-V3-1-8e.zip) • Prototype Java code and javadoc for AzApi lower lever interface • To get javadoc, unzip to <dir>, then open <dir>/AzApi-V3/doc/index.html • Should load directly into eclipse • Prototype proof-of-concept test code to implement interface • Sample program to use test interface

  9. Notable Design Objectives • Generics-based type safety for XACML Attribute DataTypes and Categories. • Strict compliance in test impl forced some unnecessary verboseness in interfaces which can be consolidated • XACML 2.0 support, 3.0 readiness • AzService.query( ), .queryVerbose( ) intended for “what is allowed” type requests • Hierarchical factory-created objects

  10. Structure of AzApi • Hi level architecture described in org.example.azapi package description • Major classes: • AzService (.decide( ), .queryVerbose( ) ) • AzRequestContext, AzResponseContext • AzEntity (AzCategory) (collection of attrs) • AzAttribute (AzCategory) • AzAttributeValue (AzCategory, AzDataType)

  11. Next Steps • Code is intended to be starting point of open source development of XACML AzApi. • Details to be provided

More Related