introduction to azapi, openaz december 10, 2009. motivation provide xacml capabilities to the...

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 ArchitectureApplication Container / Platform

AzApi: XACML-compliant PEP

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

InternalXACML PDP Az Provider

ExternalXACML 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 ArchitectureApplication Container / Platform




Container Controlled Application Access (PEP)


ApplicationClient Request/ Response

Add XACML to Existing ArchitectureApplication Container / Platform







Application

Internal SunXACMLXACML PDP Az Provider


SunXACML Api: Impl

Client Request/ Response

External XACMLApi: Impl

External XACMLApi: Impl








Application



AzApi: Impl Config Az

AzApi: Impl Config Legacy

AzApi: Impl Config External

SunXACML AzApi: Impl Config Internal

AzApi: V3-1-08


AzApi: V3-1-08



AzApi V3-1-08

AzApi “EZ” ArchitectureApplication Container / Platform







Application







AzApi: V3-1-08


EZ-Appl-PEPEZ-Ctnr-PEP

AzApi: V3-1-08



AzApi V3-1-08








Application

SunXACMLXACML PDP Az Provider








AzApi: V3-1-08


EZ-Appl-PEPEZ-Ctnr-PEP

1. 1 1.2 1. 3

2. 12. 2

2. 32. 4

2. 5

3. 1 3. 2 3.3 3. 4

4. 1

5. 1

5.2

AzApi: V3-1-08 AzApi V3-1-08

2.1.1 2.3.1

AzApi Arch Interface DefnsEach 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

1. 1.1 Client sends request, container returns response2. 1.2 Container calls appl, appl returns response3. 1.3 Appl calls container services, services return response

2. Container/Appl to Az interface1. 2.1 Container calls AzApi directly (Migrate container to AzApi)

2.1.1 Container calls AzApi thru simplified EZ-Ctnr-PEP module2. 2.2 Container calls platform legacy Api (Current container state)3. 2.3 Appl calls AzApi directly (Migrate appl to AzApi)

2.3.1 Appl calls AzApi thru simplified EZ-Appl-PEP module4. 2.4 Appl calls platform legacy Api (Current appl state)5. 2.5 Container services use platform legacy Api for files, etc.

3. AzApi Impl to Az Provider Api1. 3.1 AzApi Container Impl calls any configured PDP2. 3.2 AzApi Container Impl calls platform legacy Api3. 3.3 AzApi Appl Impl calls any configured PDP4. 3.4 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 AzApi1. 4.1 Enhanced policy provider (implementing platform SPI) calls the AzApi2. 4.2 (next slide) Non-XACML policy provider calls Non-XACML PDP3. 4.3 (next slide) Default policy provider uses java.policy file: J2SE std provider

5. Full AzApi Impl to Az PDP1. 5.1 AzApi Impl calls externally deployed 3rd party XACML PDP2. 5.2 AzApi Impl calls internally deployed SunXACML PDP3. 5.3 (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

1. 2.1.* -> 3.1 Container uses AzApi, which in turn connects to XACML provider, bypassing platform legacy provider.

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

3. 2.1.* -> 3.1,3.2 Container uses AzApi, impl may dispatch some calls to legacy, some to new providers.

2. Appl to AzApi1. 2.3.* -> 3.3 Appl uses AzApi, which in turn connects to XACML provider,

bypassing platform legacy provider.2. 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.3. 2.3.* -> 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:1. 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. 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)

3. 2.3.* -> 3.3 –> 5.* Appl uses AzApi to call any XACML PDP (same note as #1 above)

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

AzApi Deployment ArchitectureApplication Container / Platform




Application






EZ-Appl-PEP

1. 1 1.2 1. 3

2. 12. 2

2. 32. 4

2. 5

3.3 3. 4

4. 1



EZ-Ctnr-PEP

AzApi: V3-1-08 AzApi V3-1-08

2.1.1 2.3.1

J2SE Default Az Provider

java.policygrant stmts

InternalNon-XACML PDP Az Provider

Non-XACML Az Provider

4.34.2

AzApi: Impl Config Non-XACML


AzApi: Impl Config SunXACML

AzApi: V3-1-08

5. 1

5.2 5.3




3. 1 3. 2

Provider strategy\pdp-proj\doc\org\openliberty\openaz\azapi\package-summary.html

AzApi: Impl Config SunXACML


AzApi: full interface (AzApi V3-1-08*)

AzService-Impl

AzRequestContext-Impl

AzResponseContext-Impl

AzEntity<T>-Impl

T: AzCategoryId

AzAttribute<T>-Impl

T:AzCategoryId

AzAttributeValue<U,V>-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 AzApiProvider Impl

RemotePolicyEngine

SUNXACMLLibrary

JavaPermissions

EZ SpringPEP

EZ JSFPEP

EZ ADFPEP

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

introduction to azapi, openaz december 10, 2009. motivation provide xacml capabilities to the...

Documents