Increasingly enterprises need to / want to expose their applications to the outside – be it the public internet with consumers or a virtual network of distributed enterprise sites accessing corporate resources.

Either way, to securely expose web applications, it is common practice to offer access via a DMZ which is protected by a firewall on the one hand (which handles network-level security) and an XML application gateway (which handles XML security, message transformation, routing, endpoint virtualization…)

The application gateway also has 2 security-critical missions: (a) authenticate the requestor and (b) authorize the request. The former is easily achieved by integrating with the authentication solution (e.g. an LDAP) and picking up the credentials from the request (username/password, certificates…). The latter has so far often been achieved as a consequence of authentication and of the products used. Authorization would then be a simple role-based access control where roles, user groups, and application groups would all be maintained in the authentication solution.

It is now possible though to fully utilize XACML-based, attribute-based authorization by integrating an application gateway with a XACML PDP engine e.g. the Axiomatics Policy Server. It is – as a matter of fact – what is described in this whitepaper on the integration between the APS and Intel’s SOA Expressway.

The following scribbling summarizes how simple the integration is.

The example in the picture considers a user, Bob, who wants to use a service S within a protected domain. Service S is exposed via a firewall and an application gateway (typically an XML security gateway). Bob requests Service S. The request goes through the firewall and is intercepted by the application gateway. The latter takes the request, extracts Bob’s credentials, and sends them on to the user directory (AD in the picture) for authentication (AuthN) (1). Once this step has completed and Bob has been authenticated, the gateway can now ask for an authorization decision from the XACML PDP (2). This allows for finer-grained authorization than what can be simply achieved with AD roles and groups. The gateway builds the XACML request to which it can add information extracted from

• the incoming request (e.g. the action requested),
• the user directory (e.g. Bob’s job title, clearance level) which then acts as a policy information point
• the context / environment e.g. the time / location of the request

These information bits are converted to XACML attributes and added to the XACML request which is then sent by the gateway to the PDP for an authorization decision. If the decision is PERMIT, then the gateway can route Bob’s request to the service in step (3).

Integration can be easily achieved through the use of the XACML request/response protocol and because application gateways can naturally produce and consume XML messages.