For Spatial Web services, you will want to make the connection to the database as secure as possible. Security in this context includes the following considerations:
Confidentiality: a guarantee that no third party can intercept and decrypt messages between a user and the server
Authenticity: a guarantee that no third party can convincingly impersonate another user when connected to the server
Integrity: a guarantee that no third party can alter a message between a user and the server without the alteration being detected
After authentication reliably determines each user's identity, users also expect flexible and fine-grained authorization, limiting their access to data and features based on their identity and any privileges associated with that identify. However, many current XML and SOAP interfaces do not adequately cover these aspects of security.
This chapter includes the following major sections:
See also the
wsclient.jar demo file (described in Section 10.4) for instructions and samples related to security with Spatial Web services.
For Spatial Web services, several forms of user management are available, affecting how administrators manage external users (that is, the users making SOAP/XML requests) and database users, as well as how users' credentials are controlled (and thus which data and Web service features these users can access).
In the database, a user can be either a database/enterprise user (managed by the system) or an application user (managed in a table). In addition, OC4J might share the user definition of an enterprise user, or it might define an LDAP-managed user separate from any database user (such as using the same name as an existing database user but not necessarily the same authentication as that database user).
Generally, a user will make SOAP requests, for example, by providing the user name
John and the authentication
secret. In this scenario, John must be an OC4J user. (The administrator can use LDAP, LDAP/XML, and other methods for OC4J user management.)
User management in the database is linked to identity propagation, which is described in Section 17.1.1.
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
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.
Authorization and versioning are primarily performed in the database rather than in OC4J, although the administrator can configure OC4J to perform some authorization restrictions. Oracle Database enables common grants on select, insert, and update operations, as well as a virtual private database (VPD), to be configured. Workspace Manager operations are also supported.
As mentioned in Section 17.1.2, any caching in OC4J should be consistent with the database configuration. However, if the caching is not consistent, you should use the single application user approach described in Section 17.1.1, because then it will not be an issue that all human users of the application will be able to see the same data.
Note:OpenLS mapping and routing services cannot operate with virtual private databases (VPDs) or with other forms of user-specific authorization (such as granting SELECT privilege on a table to a specified user).
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.)
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>
src/oracle/spatial/ws/svrproxy/ in the
wsclient.jar demo file (described in Section 10.4).
After you deploy the .ear file, you must configure it. The general configuration includes the following files, but excludes any service-specific setup, such as the WFS-specific portions of the
data-sources.xml contains the database connection for each service (Catalog, OpenLS, WFS, and so on). For example:
<?xml version = '1.0' encoding = 'windows-1252'?> . . . <native-data-source name="jdev-connection-NdmProxyConnection" jndi-name="jdbc/NdmProxyConnectionCoreDS" url="jdbc:oracle:thin:@server.com:port:sid" user="usr" password="password" data-source-class="oracle.jdbc.pool.OracleDataSource"/> . . . </data-sources>
WSConfig.xml contains, beside WFS-specific parameters, the definition of handlers: name, implementation, and user management. For example:
<Handlers> <OpenLS> <JavaClass>oracle.spatial.ws.openls.OpenLsHandler</JavaClass> <Anonymous_xml_user>SpatialWsXmlUser</Anonymous_xml_user> <Proxy_management> <Proxy_authentication/> </Proxy_management> </OpenLS> . . . <Network> <JavaClass>oracle.spatial.network.xml.NetworkWSHandler</JavaClass> <Proxy_management> <Fixed_app_user/> </Proxy_management> </Network> . . . </Handlers>
data-sources.xml file contains a database connection for each services handler, such as WFS. There are three scenarios, based on the method of user identity propagation (described in Section 17.1.1):
Proxy authentication: The connection specified refers to the proxy user, which is different from the actual SOAP user.
Application user management: The connection specified refers to the proxy user, connected as the user to which the system context is set.
Single application user: The connection specified refers to the final user (APP_USER). There is no proxying, no changing of the system context, and no reconnecting as a different user.
WSConfig.xml file includes a part that declares handlers:
<JavaClass>, the first parameter, specifies the implementation of the service handler. This Java class implements the interface
oracle.spatial.ws.SpatialWSHandler. This implementing class can be made available to OC4J in a shared library, specified in the
server.xml file. For example:
<shared-library name="sdows" version="1.0"> <code-source path="*"/> <import-shared-library name="oracle.xml"/> <import-shared-library name="oracle.jdbc"/> </shared-library> . . . </application-server>
The administrator must give the SpatialWS .ear file access to that shared library. This can be done globally in
application.xml, as in the following example:
<imported-shared-libraries> . . . <import-shared-library name="sdows"/> </imported-shared-libraries> </orion-application>
<Anonymous_xml_user>, the second parameter, specifies the database identity of users connecting through the simple non-SOAP XML interface as opposed to the SOAP interface. (For more information, see Section 17.4.2.)
<Proxy_management>, the third parameter, specifies method of propagating the user's identity to the database. Possible values are
<Fixed_app_user>. The most typical selection will probably be
In addition, when deploying and configuring the .ear file, be sure to check for any security-related information in the material about deploying a J2EE application (EAR) in Oracle Containers for J2EE Configuration and Administration Guide, as well as the information about configuring a secure website in OC4J.
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.)
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
application.xml), or by adding the .jar file to the existing shared
sdows library (a quick approach).
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.)
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
Spatial Web services can be accessed through different interfaces, each having implications for security. For all services, a SOAP/WSS interface is available, as well as a simple XML (non-SOAP) interface. For OpenLS, there also is a PL/SQL interface, because the OpenLS implementation itself is in PL/SQL.
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:
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:
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
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.
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.
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: