Interoperability Testing Issues GEOAXiS PEP with con terra and Secure Dimensions PDP

Copyright © 2013 Open Geospatial Consortium 16

5.7.1 GEOAXiS PEP with con terra and Secure Dimensions PDP

In support of interoperability, connectivity testing was performed between ESRI, GEOAxIS, Carbon Services, Conterra, Interactive Instruments and Secure Dimensions to identify and correct any network and firewall related issues. Connectivity with WFS providers was demonstrated using simple invocations of GetCapabilities and GetFeature WFS requests for each service provider. During this effort the visualization application was tested to determine that it could successfully authenticate with the GEOAxIS infrastructure and maintain session state. Without this capability, user identity could not be propagated and security policy enforcement would ultimately fail. Client applications need to support HTTP redirects 302 as well as session persistence mechanisms with cookies and headers. It was discovered that the ESRI client was not able to support this protocol. As a result, an instance of a SilverLight client was modified to act as the visualization application. Additional testing was conducted to ensure that XACML request and response messages could be exchanged and successfully processed by partners.

5.7.1.1 Interoperability Testing Issues

During testing, it was discovered that PEP clients needed to understand the encoding scheme of their PDP partners. Specifically, PEP and PDP needed to agree upon the format of data contained within the Resource and Action elements in the XACML request messages. If a PEP client did not encode the data in a manner that the PDP expected, the result would either be a XACML Deny or NotApplicable response. These were the only two instances where this situation was encountered during testing, however, there may be other instances if additional XACML components are configured. In this case, it appears that the encoding scheme provides the PDP with the ability to parse the input strings in a consistent manner and map them to internal data structures, stored policies and resources. This discovery resulted in development of custom transformations implemented at the GEOAxIS PEP to accommodate the various data encoding requirements of the participating PDPs. Transformations were performed on both inbound and outbound XACML message flows to reconcile these structural differences. Although this situation was encountered in a small test environment with limited impact, in a large scale enterprise deployment, this could have considerable impacts on scalability, performance and maintainability of an enterprise security solution that relies heavily on XACML. According to the XACML standard, there is the concept of a Context Handler. The context handler, as identified in Figure 1 in the XACML standard, is described as a component that sits between any interface with a PDP. The interface could be a resource, a PEP, or a PIP. Copyright © 2013 Open Geospatial Consortium 17 According to the XACML specification, the Context Handler is the system entity that converts decision requests in the native request format to the XACML canonical form and converts authorization decisions in the XACML canonical form to the native response format. Within the scope of this exercise, the Context Handler function is provided by the GEOAxIS PEP. However, it does not conform to the strict definition of the Context Handler within the specification. It does not perform translation from non‐XACML authorization requests to XACML, but rather, is responsible for initiating the the interaction to the PDP by generating XACML request messages and forwarding them onto the PDP and enforcing decision responses. Additionally, the GEOAxIS PEP is responsible for performing translation services for each PDP it interacts with. It also provides application and protocol translation, for example, converting OGC RESTful formatted request messages to SOAP messages. Based upon insight gained during this effort, GEOAxIS believes that the XACML standard should be enhanced to provide guidance on how to resolve such interoperability issues. Options to address this issue in the XACML standard include: ฀ Require PDP service providers to include data and encoding constraints in a service definition Copyright © 2013 Open Geospatial Consortium 18 ฀ Provide guidance on a common data structure format that PDP providers can publish to PEPs to reduce or eliminate exposing internal data mapping schemes to PEP consumers ฀ Expand the description of the Context Handler to introduce a translation service component that provides, among other things, message structure translation capability, protocol translation services and syntax or semantics checking

5.7.1.2 Obligation Processing