110 likes | 207 Views
Introduction to AzApi. July 30, 2009. 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
E N D
Introduction to AzApi July 30, 2009
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
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
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
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
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
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.
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
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
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)
Next Steps • Code is intended to be starting point of open source development of XACML AzApi. • Details to be provided