Sunday, 20 July 2014

Externalise authorization in your Axway API Gateway

This post discusses how easily Axway's API Gateway and ViewDS's Access Sentinel can integrate, allowing Axway API Gateway users to experience the flexibility of XACML and the ability to perform fine grained attribute based access control. 

API Security breaches can cause brand damage, revenue loss, and compliance penalties. Axway API Gateway provides comprehensive API security and pre-built identity management integrations, including an ability to integrate with XACML 3.0 authorization servers such as ViewDS Access Sentinel. 

Complicated authorization policies can be abstracted away from the Axway policy configuration to a dedicated Access Sentinel server. Since Access Sentinel is a purpose built solution, it will offer greater ease and flexibility when it comes to managing policies and offer greater performance and scalability when complex authorization rules are required. 

A simple example of when Access Sentinel can be used with API Gateway is when you would like to authorize a client's access to an API. 

Axway API Gateway is a next-generation technology that enables enterprises to standardize the API development and delivery capabilities required to provide business services via cloud, mobile and partner channels. Encapsulating application gateway, cloud service broker and identity middleware functionality in a unified platform, it provides an agile API environment that leverages existing back-end applications, services and data to help speed time-to-market for new business services while ensuring high security, performance and availability. 

ViewDS Access Sentinel is an authorization server that is designed to allow 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. 

Access Sentinel can be invoked from within your API Gateway at any stage throughout your policy processing. 

To begin, locate the XACML PEP authorization filter and place it into your policy. 

XACML PEP Filter Configuration
XACML Version
Select XACML version 3.

XACML Attributes
Add the desired attributes to the request. For example: 
Add the authenticated user's username as the subject identifier

Add the requested uri as the resource identifier
Add the HTTP verb as the action identifier

XACML Response 
Identify that a Permit response is required to allow processing to continue down a Success Path.

In this next step, we simply need to supply the URL that Access Sentinel is offering an authorization service on. By default, Access Sentinel provides this service on port 3009. 
The advanced setting of the XACML PEP filter allow aspects of SOAP message to be configured. In this example, we will adhere to the SAML 2.0 Profile of XACML 3.0, whereby we'll use SOAP 1.1 and encapsulate the XACML Authorization Request within XACMLAuthzDecisionQuery.

When you click Finish the configuration of the XACML PEP will be complete and usable within your API policy. 

In this example, we've configured the XACML PEP filter to send Access Sentinel an authorization request, indicating that a specific user is attempting to access a URI using a specific HTTP verb (E.g. POST, GET, etc). Access Sentinel will then be able to respond with an authorization decision (Permit or Deny) that will be based upon its authorization policies and any additional information that it has regarding the subject and resource. Since Access Sentinel maintains information about users and resources, it will use this information efficiently when making a decision, saving you the time end effort of obtaining this information from external data sources within your API policy and hand crafting access control decision logic yourself. 

Sunday, 11 May 2014

Integrated Attribute Storage

A notable difference between Access Sentinel and other XACML authorization solutions is that Access Sentinel has an integrated attribute store. In fact, we began with a secure attribute store and then built authorization services into it.  

The reason for this is that XACML is fundamentally an Attribute-Based Access Control (ABAC) system, which requires access to attributes to make access control decisions. To achieve high performance, one must bring the authorization attributes as close to the authorization service as possible. To ensure security, the integrity and trustworthiness of attributes is paramount as an ability to manipulate attributes will change the outcome of access control decisions. 

When considering the deployment of an attribute-based authorization solution, the manner in which attributes are accessed must be considered. 

Accessing information at its source will affect the performance, reliability and complexity of the authorization service while raising many questions about the security and trustworthiness of the information. 

Many optimisations can be made to help improve the situation, such as the use of virtual or meta directory based solutions, however doing so may result in a more complex and costly solution. 

Access Sentinel

Access Sentinel is a self contained solution that allows applications to externalise authorization decisions. Access Sentinel includes: 

  • an attribute synchronization service to consume necessary attributes from existing data sources
  • a robust repository to store policies and attributes
    • Attributes may be synchronized from existing systems or defined locally for the purpose of providing an authorization service
    • Access to attributes are secured using XACML policies
  • an authorization service that obtains attributes and policies through high speed internal function calls

The consolidation of all of the required components (attribute storage and synchronization, policies and an authorization service) makes Access Sentinel a simple, effective, and high performance authorization solution. The Access Sentinel solution can be deployed and distributed throughout an enterprise to simplify policy and attribute requirements.

For more information about Access Sentinel and the importance of attributes in your authorization strategy, please read our latest whitepaper: 

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.


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

Sunday, 9 February 2014

Facebook bug prevents users from managing app privileges

Developers from MyPermissions have identified what they believe to be a bug in Facebook that can prevent users from revoking an application's access privileges.
This bug exhibits itself when a user attempts to revoke an app's privileges through the Facebook mobile app or mobile web interface after having previously granted the application access to their Facebook information.

As indicated within the announcement by MyPermissions, Facebook has been notified about the potential bug and are looking into it. It's not clear to me whether Facebook have yet accepted that this is a bug as there are many differing reports in relation to this, although having been able to reproduce the described behaviour I'm confident that what MyPermissions have found is real.
I'm surprised that this bug hasn't been noticed and/or reported earlier, since one of my installed apps (a very trustworthy, popular and legitimate app) exhibits this problem and is in no way operating maliciously.

It's relieving that the problem doesn't exhibit itself through the regular desktop interface, as this would suggest that there isn't an issue with Facebook's underlying access controls or the way that it evaluates an application's permissions. Users can rest assured that the desktop interface is a working solution for removing applications that should no longer have access to their information.

As a vendor of externalised authorization software, hearing stories such as this really highlights to me the importance of implementing secure and robust security solutions. Even in the case of a simple user interface issue, the ability for attacker to be able to exploit a bug to obtain irrevocable account access is quite alarming.

This is simply another good reason for ISV's to consider a standardised authorization service, rather than invent and implement a proprietary access control model on an application by application basis. Technologies such as XACML promote the separation of authorization away from being hard coded within an application towards being a policy driven authorization service. At ViewDS we provide Access Sentinel, which is an example of an XACML authorization solution that can be used by applications to govern their access control decisions.