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 –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

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

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 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” Pep API built on AzApi Sample programs to use, test interfaces

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

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)

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

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()

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

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

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

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

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

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. 1.Client to appl level Client sends request, container returns response Container calls appl, appl returns response Appl calls container services, services return response 2.Container/Appl to Az interface Container calls AzApi directly (Migrate container to AzApi) Container calls AzApi thru simplified EZ-Ctnr-PEP module Container calls platform legacy Api (Current container state) Appl calls AzApi directly (Migrate appl to AzApi) Appl calls AzApi thru simplified EZ-Appl-PEP module Appl calls platform legacy Api (Current appl state) Container services use platform legacy Api for files, etc. 3.AzApi Impl to Az Provider Api AzApi Container Impl calls any configured PDP AzApi Container Impl calls platform legacy Api AzApi Appl Impl calls any configured PDP AzApi Appl Impl calls platform legacy Api

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. 4.Enhanced policy provider to full AzApi Enhanced policy provider (implementing platform SPI) calls the AzApi (next slide) Non-XACML policy provider calls Non-XACML PDP (next slide) Default policy provider uses java.policy file: J2SE std provider 5.Full AzApi Impl to Az PDP AzApi Impl calls externally deployed 3 rd party XACML PDP AzApi Impl calls internally deployed SunXACML PDP (next slide) AzApi Impl calls Non-XACML PDP

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

AzApi: Purpose of Specific Combos (cont) Refer to diagram for interface sets. Each interface set represents a specific strategy. 3.Top to bottom strategies: * -> 3.1 –> 5.* Container uses AzApi to call any XACML PDP (note that AzApi impls must collect all context attrs for PDP) * -> 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) * -> 3.3 –> 5.* Appl uses AzApi to call any XACML PDP (same note as #1 above) * -> 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)

AzApi Deployment Architecture Application Container / Platform Extended Platform Az Provider Container Controlled Application Access (PEP) Container Provided Application Services (Files, Externals, …) Application Internal SunXACML XACML PDP Az Provider External XACML PDP Az Provider AzApi: Impl Config Az AzApi: Impl Config Legacy Client Request/ Response EZ-Appl-PEP AzApi: Impl Config Az AzApi: Impl Config Legacy EZ-Ctnr-PEP AzApi: V AzApi V J2SE Default Az Provider java.policy grant stmts Internal Non-XACML PDP Az Provider Non-XACML Az Provider AzApi: Impl Config Non-XACML AzApi: Impl Config External AzApi: Impl Config SunXACML AzApi: V Platform Az API (checkPermission, isAccessAllowed, …) Platform Az SPI (Policy.implies, AccessDec.isAccAllowed, …) Built-in Platform Az Provider

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

Java AzApi Provider Impl Remote Policy Engine SUN XACML Library Java Permissions EZ Spring PEP EZ JSF PEP EZ ADF PEP

Next Steps OpenAz project to formalize PepApi as part of AzApi OpenAz project to implement SunXACML AzApi Impl OpenAz project to work on configuration strategy OpenAz project to work on XML strategy