Securing the Data Layer

Secured Space

A secured embedded Space protects access (to data), which is granted only to users with sufficient privileges. When a remote Space proxy connects to a secured Space, it must provide security credentials (usually the username and password, as explained in Custom Security regarding extensions).

An embedded Space can be configured with internal services (Space filters, Notify/Polling containers, etc.), which must have privileges to operate on the embedded Space. These privileges are propagated by the security credentials provided when creating a Space.

The security credentials can be either be supplied as a UserDetails object, or in its simpler form of two Strings (username and password).
These are used to implicitly create a secured Space, with security privileges being propagated to internal services.

The username and password can also be supplied using a pu.properties file supplied during deployment. If these are supplied, they will be used to implicitly connect to a secured Space, returning an authenticated proxy for this user.

#pu.properties
security.username=user
security.password=password

security.username and security.password are constant property keys. If you want to set your own property placeholders, such as $\{mySpace.username\} and $\{mySpace.password\}, you must use plain XML configuration. These properties have to be injected at deploy time, by some property resolver.

Protecting User/Password

Leaving the username and password exposed (in pu.xml/pu.properties) isn't secure. A preferred implementation is to supply the credentials during deployment. The GigaSpaces Management Center, CLI, and Admin API administration tools provide comprehensive support for deploying a secured Processing Unit (refer to Accessing a Secured Service Grid).

Using the CLI deploy command, supply the username and password using -user and -password:

> gs deploy -secured -user testing -password 1234 myPU.jar

Property substitution is not supported for the nested os-core:security element. If you don't want to add a Space property (and need to use property placeholders instead), you can pass the username and password as parameters:

Local Cache

The local cache Java version | .NET version is a read-only service on top of a remote Space. Thus, the local cache "creator" needs to have Read privileges.
Security is enforced by the remote Space, and the proxy should be acquired by supplying the username and password.

Space Filters

Space Filters Java version | .NET version are interceptors inside the XAP Space that allow implementation of user-defined logic based on Space events. Some filters need to perform operations on the embedded Space. If secured, the filter needs sufficient privileges for its operations.

The username and password supplied when creating a Space are used to implicitly create a secured Space. The security privileges of the specified user are propagated to the filter. If the user has Read privileges, then the filter can perform a space.read(..) on its embedded Space.

Before-Authentication Operation

A filter can be registered for before-authentication events. Before a client tries to authenticate, any filter with the before-authentication operation-code is invoked. The SpaceContext supplied as part of the call holds a SecurityContext that has the UserDetails object.

The following Spring configuration registers this filter for before-authentication (6) operation:

The following Spring configuration XML shows how the filter can be configured using explicit method listings (in this case, annotations are not required).
Note the before-authentication method adapter.

Custom Access Control

Custom Access control using Space Filters allows for access decisions based on user/role/data relationships. The SpaceContext filter invocation parameter holds the SecurityContext of the current operation. This context provides you with UserDetails, the Authentication and AuditDetails. Based on these, you can enforce custom access decisions (such as allow or disallow the operation).

The SpaceContext may be null when related to replication/recovery and filter operations, such as notify-trigger. In these cases, there is no user context.

The filter can be declared just like any other filter, but note that the priority plays a role in the order of filter execution. The default priority is zero.

Task Execution over the Space

Tasks Java version | .NET version can be executed in a co-located, asynchronous manner within the Space (Processing Unit with an embedded Space). To execute a task, you must have Execute privileges. Execution can be restricted to certain tasks by applying "Class-Filter'. There is no need to define specific privileges for operations being performed by the task on the Space.

The following is a simple implementation of a task that performs a "count' operation on the Space.

While executed tasks are effective when co-located, you may require operations on the cluster.

GigaSpace clustered = gigaSpace.getClustered();

Space operations performed from within the task are guarded by a temporary trust available throughout the life-cycle of the task. If you are trying to enforce custom access control, the SecurityContext must be extracted in a before-execute filter call.

Executor-Based Remoting

Executor-based remoting Java version | .NET version allows you to use remote invocations of POJO services with the Space as the transport layer, using OpenSpaces Executors. To invoke a service method, you must have Execute privileges for class org.openspaces.remoting.ExecutorRemotingTask.

Event-Driven Remoting

Event-driven remoting allows you to use remote invocations of POJO services with the Space as the transport layer, using a polling container on the Space side to process the invocations. Under the wires, event-driven remoting uses the Space write and take capabilities. As such, you must have Write and Take privileges (at both ends) for class org.openspaces.remoting.EventDrivenSpaceRemotingEntry.

JDBC Driver

XAP allows applications to connect using a JDBC driver. A XAP JDBC driver accepts SQL statements, translates them into Space operations, and returns standard result sets. To acquire a connection to a remote secured Space, provide the credentials (username and password) as parameters to the connection.