Category Archives: XML Gateway

Securing Layer 7 Policies with Axiomatics

18 Monday Jul 2011

Posted by in Authorization, Axiomatics, Layer 7 Technologies, XACML, XML Gateway

≈ 1 Comment

Tags

, , , , , ,

The Extensible Access Control Markup Language (XACML) is a general-purpose Access Control Language providing context-aware authorization decisions.  In this blog we will demonstrate how the Layer 7 XML Networking Gateway can provide centralised fine-grained access control using the Axiomatics Policy Server (APS).

In this scenario we will be using the APS Policy Decision Point (PDP) via the SOAP XACML PDP Service.  The APS PDP evaluates XACML Access Requests against XACML Policies, providing permit/deny authorization decisions.  The Layer 7 XML Networking Gateway will act as Policy Enforcement Point (PEP), capturing service requests, transforming request context into XACML Requests, interpreting XACML Responses and enforcing authorization decisions.

Below is the Layer 7 Policy for the RESTful Broker Service. The Broker Policy provides in-policy authentication and invokes the Evaluate Request using XACML SOAP PDP Policy Fragment to provide the XACML fine-grain authorization.  Fragmenting the XACML Authorization keeps the core policy simple; whilst providing a reusable XACML Authorization Fragment.

The policy secures the Broker Service using SSL (line 2); this protects the credentials used to authenticate to the Gateway.  Service clients are required to provide a username/password via Basic Authentication (line 3); the credentials provided are verified against the Gateway’s Internal Identity Provider (line 4).  Optionally we could replace the Internal Identity Provider with LDAP or a Federated Identity Provider.

In line 6 we have included the Audit Messages in Policy Assertion.  As shown below, we’ve set the Audit Events level to Warning and saved the Broker Requests and Reponses. This provides a simple method to test and debug our policy. Note: auditing settings should be limited to development and problem resolution.

Policy lines 8-11 set the input parameters for the Policy Fragment; line 8 sets the APS instance we’ll use to evaluate the XACML Request. Whilst lines 9-11 set parameters we’ll be using to build the XACML Request. In this case we are using the authenticated user as the Subject of the XACML Request, the Service’s Gateway URL as the XACML Request Resource and the HTTP Method as the XACML Request Action.  When securing SOAP Policies via XACML, implementers should consider setting the XACML Action to the SOAP Action.

Once the parameters for the XACML Request have been provided the Evaluate Request using XACML SOAP PDP Policy Fragment at line 13 is invoked.  If the Policy Fragment determines access is denied a HTTP Error Code of 403 (Forbidden Access) is returned to the service client; execution of the Policy terminates within the Policy Fragment and the client’s request is not routed to the backend.  If however the Policy Fragment determines access to the Broker Service is permitted, execution continues on line 15 and the client’s request is routed to the backend Broker Service.

The illustration below shows the composition of the Evaluate Request using XACML SOAP PDP Policy Fragment.

The Policy Fragment contains several Add Audit Details Assertions used audit the XACML Request/Response and SOAP Service Request/Response.  When using the aforementioned settings for the Audit Messages in Policy Assertion the output of these Audit Messages can be viewed via the Policy Manager’s Gateway Audit Events dialog.

The Set Context Variable Assertion in line 3 uses the xacml-subject, xacml-resource and xacml-action context-variables (see Policy lines 9-11) to create an XACML Request.  The XACML Request is stored to the xacml-request context variable.

The XACML Request is then wrapped in SOAP Envelope and stored within the soap-request Message context-variable (line 5).  Storing the soap-request variable as a Message allows use to use the SOAP Request as a HTTP Request for a Route via HTTP(S) Assertion.  The generated SOAP Request uses the InstanceAccessQuery2 SOAP Action; the xacml-instance context variable is provided to identity the APS Instance to evaluate the XACML Request.

The constructed SOAP request is sent the APS SOAP PDP using the Route via HTTP(S) Assertion (line 9).  The result of the Routing Assertion is stored within the soap-response context variable.

In line 10 we use the Evaluate XPath Response Assertion against the soap-response context variable to extract the XACML Response from its SOAP Response wrapping.

Using the responseXpath.element context-variable set by the XPath Assertion we then store the XACML Response within the xacml-response context variable (line 11).  In this example we log the xacml-request and xacml-responses as audit messages; real-world policies should take care to examine XACML Responses for obligations.  Depending on the nature of the obligation, handling could occur in-policy or be off loaded to file, email, JMS or obligation service.

To determine the decision from the XACML Response, we use an XPath Assertion to find the content of the Decision element within the SOAP XACML Response (line 13).  Then using the responseXpath.result context variable (set by the XPath Assertion), we store the decision within xacml-decision context variable (line 14).

Now we’ve retrieved the decision from the XACML Response, we need to determine if the policy should continue execution and allow access to the backend service, or terminate execution returning a forbidden access error/message.  At line 16 we include an At least one assertion evaluate to true Assertion; within this we nest two All assertions must evaluate to true Assertions.

The first All Assertion branch uses the Compare Expression Assertion to verify the XACML decision is not permit.  This All Assertion branch will evaluate to true if the XACML decision is either deny or indeterminate; if this occurs the Customize Error Response Assertion sets the HTTP Error Code to 403 and HTTP Response Message to access forbidden.  The Stop Processing Assertion then terminates the policy.

Alternately if the XACML decision is permit, the first All Assertions branch will fail.  At this point the second All Assertion branch is evaluated, the Compare Expression Assertion will return true.  This satisfies the All Assertion branch and At least one Assertion branch allowing execution of the Policy Fragment and Policy to continue.

Lastly at end Policy Fragment we export any context variables we’d like to make available to the main Policy.

You’ve now seen how you can create a Layer 7 XML Networking Gateway PEP to secure your services using the Axiomatics Policy Server PDP.

This example could easily be extended to include PEP caching of XACML decisions using the Look Up in Cache and Store to Cache Assertions.  Additional enhancements could also include usage of obligation handling services and authentication services.

Securing Layer 7 Policies with OpenAM RESTful Services

18 Monday Jul 2011

Posted by in Authorization, Layer 7 Technologies, OpenAM, XML Gateway

≈ Leave a Comment

Tags

, , , ,

Recently I’ve been looking into ForgeRock’s OpenAM; ForgeRock maintain and distribute OpenAM; OpenAM is of Sun MicroSystems OpenSSO open-source heritage.

In this blog I will demonstrate how to integrate the Layer 7 XML Networking Gateway with ForgeRocks OpenAM.  In this scenario we will be using the OpenAM RESTful Services to provide externalized service authentication and authorization.  More information on the OpenAM RESTful Services API can be found at ForgeRock (http://openidm.forgerock.org/confluence/display/openam/Use+OpenAM+RESTful+Services).

Integrating OpenAM’s previous incarnations OpenSSO and SJSAM both have well documented integrations:

http://www.layer7tech.com/tutorials/open-sso-iam-integration
http://developers.sun.com/identity/reference/techart/xmlgatewayopensso.html

Below is the Layer 7 Policy for the RESTful Investing Service.

The policy secures the Investing Service requests/responses using SSL (line 2); this protects the credentials and cookie used to authenticate to the Gateway.  Service clients are required to either provide a session cookie containing a valid OpenAM token (line 10) or provide a username/password via Basic Authentication (line 11).  The session cookie’s token is validated against OpenAM using the /identity/isValidToken RESTful service; whilst username/password credentials are validated against the OpenAM’s /identity/authenticate RESTful service.

In line 3 we have included the Audit Messages in Policy Assertion.  We have set the Audit Events level to Warning and saved the Investing Requests and Reponses. This provides a simple method to test and debug our policy. Note: auditing settings should be limited to development and problem resolution.

Lines 13-33 handle authentication for the Investing Policy.  The At least one assertion must evaluate to true Assertion shown below requires cookie based user verification (line 14-23) or username/password authentication (lines 24-29).  Failing session verification/user authentication an Unauthorised HTTP Error Code and message are returned (lines 30-33).

The All assertions must evaluate to true Assertion in line 14 attempts to extract an OpenAM session token from a session cookie, once extracted the session token is validated against OpenAM to assert access.

Note: The OpenAM C66Encode setting is required to store our OpenAM session tokens to cookies and use tokens with the OpenAM RESTful Services.  The c66Encode setting replaces the OpenAM token ‘#’, ‘@’ and ‘=’ characters with the URL encoding friendly ‘.’ and ‘*’ characters.

The request.http.header.Cookie context variable contains the cookies presented to the Gateways Investing Service Policy.  The Compare Expression Assertion (line 16) checks the request.http.header.Cookie context variable for a session cookie.  If the session cookie is present within the context variable we then use the Evaluate Regular Expression Assertion (line 17) to extract the OpenAM token from the session cookie.

The Regular Expression Assertion stores the extracted token into the tokens context variable array.  We then use the Set Context Variable Assertion (line 18) to set the token context variable from the tokens array.  If either the session cookie does not exist or isn’t populated the All Assertion branch at line 14 returns false; this then requires username/password authentication or returns unauthorized access.

The All Assertions’ Route via HTTP(S) Assertion (line 21) uses the/identity/isTokenValid RESTful Service to validate the extracted session token against OpenAM.  The Routing Assertion uses a predefined emptyrequest context variable as the routing HTTP Request; this ensures we are not routing sensitive backend service requests to OpenAM.  The Routing Assertions HTTP Response is stored to the openamValidateResponse context variable.

The OpenAM /identity/isTokenValid Service returns a simple boolean=true or boolean=false response.  Using a Regular Expression Assertion (line 22) we evaluate the OpenAM HTTP Response contained within the openamValidateResponse context variable.

If the openamValidateResponse context variable contains boolean=true then the OpenAM session token was successfully validated and policy execution continues to authorization.  If the Routing Assertion fails to retrieve a response or the Regular Expression Assertion fails to determine a valid session token then the All Assertion branch at line 14 fails.  In event of All Assertion branch failure the Policy falls back to OpenAM Authentication and then to UnAuthorized.

The first time a client invokes Investing Service; the All Assertion at line 14 will fail.  The Cookie based authentication provided by the aforementioned All Assertion only takes place after successful credential authentication.  The All Assertion ordering is important, the cookie All Assertion appears before the username/password All Assertion to ensure previously authenticated clients are validated via cookie rather than re-authentication.

The All Assertion in line 24 uses the username and password credentials with the /identity/authentication RESTful Service to authenticate clients whilst establishing a session token.

The All Assertion branches Routing Assertion uses the emptyrequest context variable as  the HTTP Request and stores the HTTP Response to the openamAuthResponse context variable.

Upon successful authentication the /identity/authentication RESTful Service returns the OpenAM session token within the HTTP Response.  Using the Regular Expression Assertion (line 27) we extract the returned session token from the HTTP Response; this session token is then stored within the token context variable using the Set Context Variable Assertion.

If the All Assertion authentication Routing fails to retrieve a response or the Regular Expression Assertion fails to retrieve session token then the All Assertion branch at line 24 fails.  In event of All Assertion branch failure both authentication mechanisms have been exhausted; an authorized HTTP Error Code and Message are returned to the client using the Customize Error Response Assertion (see All Assertion line 30).

In the event the All Assertion at line 24 was successful policy execution continues to authorization.  If authorization is successful the session token is later returned to the client using a Set-Cookie statement on the HTTP Response.

Lines 35-44 handle authorization for the Investing Service Policy.

The At Least Assertion at line 35 requires resource access to be granted via OpenAM; otherwise, a forbidden HTTP Error Code and Message are returned to the client.  The All Assertion at line 36 uses the OpenAM /identity/authorize RESTful Service together with the previously acquired session token, URL and HTTP Method of the requested resource to determine access.  Like the /identity/isValidToken Service the /identity/authorize Service returns a simple boolean=true or boolean=false result.

Note: When applying OpenAM authorization to SOAP Services consider using the SOAP Action as the authorization request action.  In the case of RESTful services the HTTP Method reflects the type of RESTful service operation.

Using a Regular Expression Assertion (similar to the isValidToken Service Regex Assertion) we validate the HTTP Response returned by the Authorize Service is grants access (HTTP Response equals boolean=true).

Providing the All Assertion at line 36 holds we consider access to the backend is granted, and execution continues to backend routing.  If either the Routing Assertion (line 38) or Regular Expression Assertion (line 39) fails, then a HTTP Error Code and Message are returned via Customize Error Response Assertion at line 43.

The Route via HTTP(S) Assertion at line 46 sends the clients request to the backend and returns the result.  In addition to returning the backend result we customize the HTTP Headers returned to the client, setting OpenAM token within the Session Cookie. We also set the domain of the Cookie to the Gateway hostname using the request.url.host context variable.  The Cookie scope could also be restricted a specific Service Policy using the Cookie Path attribute.

Now you know now how to integrate your Layer 7 XML Gateway Policies with the OpenAM RESTful Authentication and Authorization Services.