1 / 25

Introduction to AzApi, OpenAz

Introduction to AzApi, OpenAz. December 10, 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

hope
Download Presentation

Introduction to AzApi, OpenAz

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, OpenAz December 10, 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) Application Platform Az API (checkPermission, isAccessAllowed, …) Built-in Platform Az Provider Platform Az SPI (Policy.implies, AccessDec.isAccAllowed, …) Internal XACML PDP AzProvider External XACML PDP AzProvider AzApi Architecture Container Provided Application Services (Files, Externals, …) AzApi: XACML-compliant PEP Extended Platform Az Provider AzApi: XACML-compliant PEP

  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 OpenAZ AzApi (-V3-1-59) • Prototype Java code and javadoc for AzApi lower lever interface • Prototype proof-of-concept test code to implement AzApi interface • Prototype Java code and javadoc for “EZ”PepAPI built on AzApi • Sample programs to use, test interfaces

  9. Notable AzApi 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. Notable “EZ” Pep Api Design Objectives • Allow developers to use AzApi with easy (“EZ”) Pep interface, requiring input no more complicated than checkPermission • Allow same simple interface to be used in multiple container environments (J2SE, JEE, Spring, ADF, etc.) • Enable container-specific objects to be used directly with the Pep interface • Extend simple interface for multiple requests (box-carring) and query

  12. Structure of EZ PepApi • Major classes: • PepRequestFactory. • newPepRequest(String subject, String action, String resource) • newPepRequest(Object subject, Object action-resource, Object env) • newBulkPepRequest(Object subject, List action-resource, Object env) • newQueryPepRequest(Object subject, Object env, String scope, QueryType queryType) • PepRequest. • decide( ) • getAzRequestContext() • PepResponse. • allowed() • getObligations() • next(), getAction(), getResource() • getAzResponseContext()

  13. Client Request/ Response Application Container / Platform Container Controlled Application Access (PEP) Application Platform Az API (checkPermission, isAccessAllowed, …) Built-in Platform Az Provider Platform Az SPI (Policy.implies, AccessDec.isAccAllowed, …) Existing Architecture Container Provided Application Services (Files, Externals, …)

  14. Client Request/ Response Application Container / Platform Container Controlled Application Access (PEP) Application Platform Az API (checkPermission, isAccessAllowed, …) Built-in Platform Az Provider Platform Az SPI (Policy.implies, AccessDec.isAccAllowed, …) Extended Platform Az Provider Internal SunXACML XACML PDP AzProvider External XACML PDP AzProvider Add XACML to Existing Architecture Container Provided Application Services (Files, Externals, …) External XACMLApi: Impl External XACMLApi: Impl SunXACML Api: Impl

  15. Client Request/ Response Application Container / Platform Container Controlled Application Access (PEP) AzApi V3-1-08 Application AzApi: Impl Config Az AzApi: Impl Config Legacy Platform Az API (checkPermission, isAccessAllowed, …) Built-in Platform Az Provider Platform Az SPI (Policy.implies, AccessDec.isAccAllowed, …) Extended Platform Az Provider AzApi: V3-1-08 AzApi: Impl Config External AzApi: Impl Config SunXACML External XACML PDP AzProvider Internal SunXACML XACML PDP AzProvider AzApi Architecture Container Provided Application Services (Files, Externals, …) AzApi: V3-1-08 AzApi: Impl Config Az AzApi: Impl Config Legacy

  16. Client Request/ Response Application Container / Platform Container Controlled Application Access (PEP) AzApi V3-1-08 Application AzApi: Impl Config Az AzApi: Impl Config Legacy Platform Az API (checkPermission, isAccessAllowed, …) Built-in Platform Az Provider Platform Az SPI (Policy.implies, AccessDec.isAccAllowed, …) Extended Platform Az Provider AzApi: V3-1-08 AzApi: Impl Config External AzApi: Impl Config SunXACML Internal SunXACML XACML PDP AzProvider External XACML PDP AzProvider AzApi “EZ” Architecture Container Provided Application Services (Files, Externals, …) EZ-Ctnr-PEP EZ-Appl-PEP AzApi: V3-1-08 AzApi: Impl Config Az AzApi: Impl Config Legacy

  17. Client Request/ Response Application Container / Platform Container Controlled Application Access (PEP) Application Platform Az API (checkPermission, isAccessAllowed, …) Built-in Platform Az Provider Platform Az SPI (Policy.implies, AccessDec.isAccAllowed, …) Extended Platform Az Provider AzApi: V3-1-08 AzApi: Impl Config External AzApi: Impl Config SunXACML SunXACML XACML PDP AzProvider External SunXACML XACML PDP AzProvider AzApi Architecture 1. 1 1.2 1. 3 Container Provided Application Services (Files, Externals, …) 2.1.1 2. 1 2.3.1 2. 3 2. 2 2. 4 2. 5 EZ-Ctnr-PEP EZ-Appl-PEP AzApi: V3-1-08 AzApi V3-1-08 AzApi: Impl Config Az AzApi: Impl Config Legacy AzApi: Impl Config Az AzApi: Impl Config Legacy 3. 1 3. 2 3.3 3. 4 4. 1 5.2 5. 1

  18. AzApi Arch Interface Defns Each interface is from the perspective of the box it is attached to, calling the box the adjacent double arrow points to. • Client to appl level • 1.1 Client sends request, container returns response • 1.2 Container calls appl, appl returns response • 1.3 Appl calls container services, services return response • Container/Appl to Az interface • 2.1 Container calls AzApi directly (Migrate container to AzApi)2.1.1 Container calls AzApi thru simplified EZ-Ctnr-PEP module • 2.2 Container calls platform legacy Api (Current container state) • 2.3 Appl calls AzApi directly (Migrate appl to AzApi)2.3.1 Appl calls AzApi thru simplified EZ-Appl-PEP module • 2.4 Appl calls platform legacy Api (Current appl state) • 2.5 Container services use platform legacy Api for files, etc. • AzApi Impl to Az Provider Api • 3.1 AzApi Container Impl calls any configured PDP • 3.2 AzApi Container Impl calls platform legacy Api • 3.3 AzApi Appl Impl calls any configured PDP • 3.4 AzApi Appl Impl calls platform legacy Api

  19. AzApi Arch Interface Defns (cont) Each interface is from the perspective of the box it is attached to, calling the box the adjacent double arrow points to. • Enhanced policy provider to full AzApi • 4.1 Enhanced policy provider (implementing platform SPI) calls the AzApi • 4.2 (next slide) Non-XACML policy provider calls Non-XACML PDP • 4.3 (next slide) Default policy provider uses java.policy file: J2SE std provider • Full AzApi Impl to Az PDP • 5.1 AzApi Impl calls externally deployed 3rd party XACML PDP • 5.2 AzApi Impl calls internally deployed SunXACML PDP • 5.3 (next slide) AzApi Impl calls Non-XACML PDP

  20. AzApi: Purpose of Specific Combos Refer to diagram for interface pairs. Each pair represents a specific strategy. • Container to AzApi • 2.1.* -> 3.1 Container uses AzApi, which in turn connects to XACML provider, bypassing platform legacy provider. • 2.1.* -> 3.2 Container uses AzApi, which simply calls legacy provider – this is case where converting container api, but new providers not available yet. • 2.1.* -> 3.1,3.2 Container uses AzApi, impl may dispatch some calls to legacy, some to new providers. • Appl to AzApi • 2.3.* -> 3.3 Appl uses AzApi, which in turn connects to XACML provider, bypassing platform legacy provider. • 2.3.* -> 3.4 Appl uses AzApi, which simply calls legacy provider – this is case where converting container api, but new providers not available yet. • 2.3.* -> 3.3,3.4 Appl uses AzApi, impl may dispatch some calls to legacy, some to new providers.

  21. AzApi: Purpose of Specific Combos (cont) Refer to diagram for interface sets. Each interface set represents a specific strategy. • Top to bottom strategies: • 2.1.* -> 3.1 –> 5.* Container uses AzApi to call any XACML PDP (note that AzApi impls must collect all context attrs for PDP). • 2.1.* -> 3.2 -> 4.1 -> 5.* Container uses AzApi to call Platform Legacy Api to Extended Provider SPI to any XACML PDP (this strategy is that AzApi uses the Legacy Api facilities to collect context some context attrs, ex. J2SE JAAS Subject, J2SE codebase, JSR-115 appl context, etc, which can be used by extended provider to supply attributes to the AzApi to then send to XACML PDPs) • 2.3.* -> 3.3 –> 5.* Appl uses AzApi to call any XACML PDP (same note as #1 above) • 2.3.* -> 3.4 -> 4.1 -> 5.* Container uses AzApi to call Platform Legacy Api to Extended Provider SPI to any XACML PDP (same note as #2 above)

  22. Client Request/ Response Application Container / Platform EZ-Ctnr-PEP Container Controlled Application Access (PEP) AzApi: V3-1-08 Application AzApi: Impl Config Az AzApi: Impl Config Legacy Platform Az API (checkPermission, isAccessAllowed, …) Built-in Platform Az Provider Platform Az SPI (Policy.implies, AccessDec.isAccAllowed, …) J2SE Default Az Provider Extended Platform Az Provider AzApi: V3-1-08 AzApi: Impl Config External AzApi: Impl Config SunXACML AzApi: Impl Config Non-XACML java.policygrant stmts External XACML PDP AzProvider Internal SunXACML XACML PDP AzProvider Non-XACML AzProvider Internal Non-XACML PDP AzProvider AzApi Deployment Architecture 1. 1 1.2 1. 3 Container Provided Application Services (Files, Externals, …) 2.1.1 2. 1 2.3.1 2. 3 2. 2 2. 4 2. 5 EZ-Appl-PEP AzApi V3-1-08 AzApi: Impl Config Az AzApi: Impl Config Legacy 3. 1 3. 2 3.3 3. 4 4. 1 4.2 4.3 5.2 5.3 5. 1

  23. AzApi: full interface (AzApi V3-1-08*) AzApi: Impl Config SunXACML AzApi: Impl Config External Provider strategy\pdp-proj\doc\org\openliberty\openaz\azapi\package-summary.html AzRequestContext-Impl AzAttributeValue<U,V>-Impl U: AzDataTypeId*V: AzData* AzAttribute<T>-Impl T:AzCategoryId AzEntity<T>-Impl T: AzCategoryId AzService-Impl AzResponseContext-Impl Provider impl -> <- Default Impl Providers will likely implement from left to right. The default impl is more likely to be used from right to left.

  24. EZ SpringPEP EZ JSFPEP EZ ADFPEP Java AzApi Provider Impl RemotePolicyEngine SUNXACMLLibrary JavaPermissions

More Related