17 Security Considerations for Spatial Web Services

17.1.1 Identity Propagation to the Database

The SpatialWS service in OC4J will propagate the user's identify to the database through one of several options, which are linked to user management in the database, and thus provide administrators with flexibility in controlling user authorization and auditing. The following identity propagation options are available:

• Proxy authentication: Uses a JDBC connection to the database user through a proxy user. For example, user John in the database and user John in OC4J might be set up independently, perhaps even with different passwords; or user John might be set up as an enterprise user shared by OC4J and the database; or database user John can be set up for use through proxy authentication but not through a direct SQL connection.

• Application user management: Manages users in a database table as opposed to through database users, providing more flexibility for administrators. With this approach, when using a virtual private database (see Section 17.2.1), you cannot determine the user's identity by entering SELECT USER FROM DUAL, but must instead query the system context, as follows:

  SELECT SYS_CONTEXT('APP_CTX', 'APP_USER_ID') FROM DUAL;
  

  For example, user John in the database and user John in OC4J might be set up independently, perhaps even with different passwords; or OC4J can be configured to share the application users in the database table.

• Single application user: Uses a single application user for connections to the database. This approach is acceptable if applications do not need to distinguish among specific users, as long as they are authorized to use Spatial Web services. In this case, the specific users use the same credentials of the single application user, and they are not separately audited.

To specify the identify propagation option, insert one of the following subelements in the <Proxy_management> element in the WSConfig.xml file (described in Section 10.3):

• <Proxy_authentication/> to specify proxy authentication

• <Application_user_management/> to specify application user management

• <Fixed_app_user/> to use a single application user

17.1.2 Caching and User Administration

Any handler in the Spatial Web services framework can choose to use caching in OC4J. For example, WFS caches feature tables. The OC4J cache must comply with any authorization restrictions set up in the database, such as the use of a virtual private database (VPD). It is not feasible to replicate the entire database authorization framework locally; therefore, you must verify the applicable authorization restrictions with the database for each query.

For WFS, this means that queries must be by ID values only rather than by actual data values in other columns. For example, a query might specify SELECT id FROM... instead of SELECT col1, col2 FROM... In such cases, the actual data is already cached, and the query just verifies row-level authorization. This approach also usually results in a performance benefit, especially for large data records (as is often the case with spatial data).

However, this approach will not work for some forms of column-level VPDs. For example, column-level VPDs might be configured so that user John can see only generalized geometries, whereas user Jane can see the original detailed geometries. Both users access the same data records, but for John the geometry column level gets "obfuscated," which in this example might mean a geometry generalization. As another example, obfuscation might make Social Security numbers visible only to authorized users, but showing the obfuscated value ********* to other users.

For the Spatial network data model, caching does not verify authorization restrictions (due to performance considerations related to network query patterns). Therefore, the network data model uses the single application user option for identify propagation (see Section 17.1.1), which limits an administrator's options for controlling the authorization of users.

17.2.1 Virtual Private Databases

An administrator can restrict users' access by implementing virtual private databases (VPDs). When proxy authentication or application user management is used for identity propagation (see Section 17.1.1), SOAP requests are executed in the context of VPD policies for the current user, as specified in the WSS section of each SOAP request.

When a single application user is used for identity propagation, SOAP requests are executed in the context of the generic single user, making all SOAP requests fundamentally anonymous to the database. (OC4J will still recognize the user by the user name in the WSS section of the SOAP message, and thus OC4J could be configured for auditing; however, the database does not share that knowledge of the user name.)

17.2.2 Workspace Manager

You can execute any SOAP request in the context of a workspace by specifying the workspace ID in an <SdoRequest> element, as in the following example:

<mdsys:SdoRequest xmlns:mdsys="http://www.oracle.com/2006/mdsys"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <mdsys:SdoRequestHeader workspace_id="OlsWorkspace"/>
  <mdsys:SdoRequestBody>
    <XLS …>
    </XLS>
  </mdsys:SdoRequestBody>
</mdsys:SdoRequest>

See also oracle.spatial.ws.svrproxy.TestYPWithWorkspace.java under src/oracle/spatial/ws/svrproxy/ in the wsclient.jar demo file (described in Section 10.4).

17.3.1 Adding Spatial Service Handlers

By default, Spatial Web services include support for CSW, OpenLS, and WFS. However, you can add support for additional service handlers by implementing and deploying an interface for each desired handler.

To include support for a service handler, implement the interface oracle.spatial.ws.SpatialWSHandler and deploy it into a .jar file. The implementation contains the following function that determines whether the current request is meant for this service:

public boolean canHandle(Element request)

To deploy the interface, perform the following actions. (You can perform the steps in any order.)

1. Make the .jar file accessible to OC4J. The administrator might do so by creating a new shared library (see the information in Section 17.3 about updating server.xml and application.xml), or by adding the .jar file to the existing shared sdows library (a quick approach).

2. Declare the service in a <Handlers> element in the WSConfig.xml file, which includes specifying the implementation class name. (See the example for the OpenLS and Network handlers in Section 17.3.)

3. Declare the data source in a <native-data-source> element in the data-sources.xml file, which includes specifying the connection JNDI name. (See the example for jdbc/NdmProxyConnectionCoreDS in Section 17.3.) The implementation contains the following function that determines the connection JNDI name:

   public String getConnectionJndiName()
   

   This name must match the JNDI name specified in the data-sources.xml file.

17.4.1 SOAP/WSS Interface

The SOAP/WSS interface is probably the best choice in most cases for accessing Spatial Web services. This interface offers the end-to-end security of WSS, and integration with other Web services. However, a simple XML interface is also available as an alternative, as explained in Section 17.4.2.

The default URL for the SOAP/WSS interface has the following form:

http://hostname:port/SpatialWS-SpatialWS-context-root/SpatialWSSoapHttpPort

17.4.2 XML (Non-SOAP) Interface

Sometimes you might prefer the simple non-SOAP XML interface to Spatial Web services. Specifically, this XML interface:

• Integrates easily with existing software. For example, it is easier to make JMeter connect to an XML servlet than to SOAP, particularly when WSS is used.

• Provides better performance through lower overhead. SOAP adds overhead for parsing and for encryption/signing, due to WSS. (However, the overhead is reduced if the XML service is accessed through SSL.)

The default URL for the non-SOAP XML interface has the following form:

http://hostname:port/SpatialWS-SpatialWS-context-root/SpatialWSXmlServlet

This XML interface is set up to not expect a user identity or authentication. Consequently, for XML requests, the SpatialWS service will connect to the database under a generic identity, common to all XML users. This identity is defined in the WSConfig.xml file as <Anonymous_xml_user>.

This approach is similar to using the <fixed_app_user> option in the WSConfig.xml file, which causes OC4J to keep the user anonymous as far as the database is concerned. That is, OC4J could still perform auditing or JAAS-based authorization restrictions, but database-side user authorization and auditing are limited. However, for the non-SOAP XML interface, the user is anonymous even to OC4J.

17.4.3 PL/SQL Interface (OpenLS Only)

OpenLS has a PL/SQL interface, in addition to SOAP and non-SOAP XML interfaces. If you connect through SQL and use the PL/SQL API directly, the following security considerations are different than for the apply differently than for the SOAP and non-SOAP XML APIs:

• Proxy authentication and application user management are not required, because the connection is directly between the user and the database.

• OC4Jauthentication, authorization, and caching are not required, because OC4J is not involved.

17.4.4 Level of Security, by Interface

The PL/SQL interface provides the same level of security as the SOAP interface, but in different environments. However, the non-SOAP XML provides a lower security (less secure) level, mainly because users remain anonymous to the database (except as the generic APP_USER). The non-SOAP XML interface could be used with SSL and user authentication and authorization, thus enabling identity propagation to the database; however, this would probably outweigh any perceived advantages to choosing the simple XML interface option.

If you do not need the non-SOAP XML interface and want to make it unavailable for use, you can deactivate the servlet at a URL in the following form:

http://hostname:port/SpatialWS-SpatialWS-context-root/SpatialWSXmlServlet