Sunday, 16 February 2014

Securing Layer 7 SOA Gateway with ViewDS Access Sentinel

Managing authorization rules within Layer 7 SOA Gateway may be as easy as making a simple decision or the evaluation of an LDAP group membership lookup. Although some environments will require more demanding authorization rules, including access control models that evolve over time, are highly contextual, or require fine grained attribute or role based access control decisions. 
In such cases, it becomes necessary to use an externalised authorization service that can efficiently make authorization decisions and provide the necessary tools to manage policies and the associated attributes and roles.

ViewDS Access Sentinel offers Layer 7 SOA Gateway users with a scalable and manageable approach for authorization. An externalised authorization service such as Access Sentinel, allows Layer 7 SOA Gateway policies to remain free from messy and complex authorization decision making logic.  

Layer 7 SOA Gateway

The Layer 7 SOA Gateway is a top-of-the-line API Gateway provided by Layer 7 Technologies, a CA Technologies company. The Layer 7 SOA Gateway offers all the RESTful features of the API Proxy plus advanced SOA security and mediation features for backend connectivity to databases, mainframes and applications. It can act as a lightweight enterprise service bus (ESB) with API identity, security and management built in.


ViewDS Access Sentinel

ViewDS Access Sentinel is an authorization server, which allows third party applications to externalize their authorization decision-making. The server is an XACML 3.0 standards based solution that can manage authorization policies to ensure vendor suite applications are faster, easier and safer to use. 


Integration: Layer 7 SOA Gateway using Access Sentinel for authorization

Layer 7 SOA Gateway's native support for XACML 3.0 allows seamless integration with ViewDS Access Sentinel. Rather than unnecessarily complicating the configuration of the gateway with access control code, an authorization service from Access Sentinel can be used instead. 
This post discusses how easily the Layer 7 SOA Gateway can integrate with Access Sentinel.

Components


Within this sample environment, the Layer 7 SOA Gateway is being used to mediate a web API request between a client and a backend web service. The Layer 7 SOA Gateway is fulfilling the role of an XACML PEP by sending the Access Sentinel PDP a SOAP XACML 3.0 authorization request. If Access Sentinel indicates that the web API call is permitted, then the backend web service will be invoked, otherwise the client's request will be denied.

Layer 7 SOA Gateway Policy Configuration

Below is an image of the Layer 7 SOA Gateway Policy for a web API service.




Line 2: Audit Messages in Policy
This Layer 7 SOA Gateway assertion allows the auditing of events that occur while processing this policy, including ability to save requests and responses. 

Line 3: Require HTTP Basic Credentials
Line 4: Request: Authenticate against Internal Identity Provider
Lines 3 and 4 require HTTP Basic authentication to be used, with the credentials validated against an Identity Provider. This example shows the Internal Identity Provider being used, however since Access Sentinel is a compliant LDAPv3 directory, it would be a suitable alternative. 

Line 5: Create XACML 3.0 Request
An XACML 3.0 request can be created by using the Layer 7 SOA Gateway "Create XACML 3.0 Request" assertion. An XACML request contains a collection of attributes that describe the activity that requires an access control decision. The request  can contain as many or few attributes as required and the attribute values can be derived from the HTTP session or web API call. 
Here's a simple example that sets a Subject attribute to be the username established in the HTTP Basic Authentication. 



Firstly, set the following parameters of the Assertion:
  • SOAP Encapsulation: SOAP 1.1
  • Message output: Use a Message Variable so the XACML request can be sent to Access Sentinel in a later policy step. 
An XACML Attribute consists of three components - a category, an identifier, and a data type. You can begin to add an XACML Attribute to the request by right clicking on "Request", at which point you are provided with the ability to add an Attribute Category. You can choose a standardised XACML category from the drop down list. In this example, Access Subject is chosen, which indicates that we'll be adding an attribute about the authenticated user who is attempting to execute the web service activity. 



The next step involves adding an attribute identifier. In this case we'd like to use the Subject ID, which we'll use to uniquely identify the authenticated user within the authorization request. 



Finally, you can add an attribute value. In this example we are adding a value of the user's username, which is referenced by ${request.username}. The attribute's data type will need to be selected from the dropdown list, for which we've used the string data type in this example.


Line 6: Add Audit Details: "${xacmlrequest.mainpart}"
This allows the XACML request to be audited. 

Line 7: Route via HTTPS to https://accesssentinel.viewds.com:3009
The "Route via HTTPS" assertion is used to send the XACML 3.0 request to Access Sentinel. This is a simple assertion to set up. There are three key things that need to be specified; where the request should be sent to, and the context variables that should be used to obtain the request and store the response:
  1. Specify the correct URL for Access Sentinel, including the correct scheme (HTTP/HTTPS), hostname and port number. No path is required. 
  2. Within the Request HTTP Rules tab of the assertion, select the "Request message source" from the drop down list as being "Context Variable: ${xacmlrequest}".
  3. Within the Response HTTP Rules, make the response destination a context variable and give it a name such as "xacmlresponse".


Line 8: Evaluate Response XPATH assertion
Use the Evaluate Response XPATH assertion to extract the decision element(s) from the response and assign them to a variable called 'decision'. 




Line 9: At least one assertion must be true
Line 10: All assertions must evaluate to true
Line 11: Compare Expression: ${decision.result} is a String and is equal to Permit (case sensitive): If Multivalued all values must pass
After the decision is extracted from the XACML response, it will be inspected to determine if the result of the request is Permit. If it is then Line 12 will be executed and the web API request will be routed to the backed service and processed. 
If the decision does not equal Permit, the Layer 7 SOA Gateway processing will fall through to Lines 13 and 14, in which case a standard templated response will be returned to the user indicating that they are not permitted.


This post shows how the Layer 7 XACML 3.0 PEP can be used to interact with Access Sentinel to obtain and enforce an authorization decision. There are a number of additional XACML features that Access Sentinel supports, which a Layer 7 SOA Gateway implementation can make use of in order to obtain a richer authorization experience, including the use of Obligations and Advice. 



1 comment:

  1. CA Layer 7 Online Training
    For Enquiry - http://www.21cssindia.com/courses/ca-layer-7-online-training-275.html
    Introduction
    Product introduction and overview
    Product capabilities
    Architectural Overview
    Gateway Extensibility
    Product Demonstration
    General configuration
    21st Century Software Solutions

    ReplyDelete