Summary: Service Grid secured administration

Overview

The security model around the Service Grid components is in terms of Service Grid administration. This includes the basic life cycle control of: deployment, undeployment, manual relocation, termination, etc. If you start a secure Grid Service Manager/Grid Service Container (GSM/GSC), the only way you can apply administrative operations is if you authenticate using a secure client (e.g. UI/CLI).

Once authenticated, the client may be authorized with full credentials, allowing full administrative control. Clients may also be limited with read-only credentials, allowing them only view control. Future versions may also support no credentials at all.

Prerequisites

The Service Grid security model follows the same security model of the Space. The user accounts file holding user names, passwords, roles and credentials is accessed using the same driver. This information is stored by default in an encrypted file located at <GigaSpaces Root>\security\default-users.

Usage

To enable security for the Service Grid, the GSM and GSC need to be loaded in secured mode. This is done either by modifying the services.config file directly, or by providing a system property.

Default config
com.gigaspaces.grid{
    ...
    //Set to true if GSM and GSC should be loaded in secured mode; 
    //Default false.
    secured = Boolean.getBoolean("com.gs.grid.secured");
}

Enable via config.

The syntax is based on the Jini configuration specification which provides strict type definition. To enable the secured mode,
you can simply set the value to true.

com.gigaspaces.grid{
	...
    secured = true;
}

Enable via Sys. Prop

Append the following system property to EXT_JAVA_OPTIONS in setenv script.

-Dcom.gs.grid.secured=true

Once enabled, you should see an INFO message stating that the component is secured. For example, when the GSM is secured, the following is displayed.

INFO \[com.gigaspaces.grid.gsm\]: Secured mode enabled for GSM.

Considerations

At this time, the location of the security file must be shared or copied to all instances of the GigaSpaces installation.

Configuration

The GigaSpaces default security filter uses the default-users file, located under the <GigaSpaces Root>/security directory, as the default user accounts list. The security file URL can be configured using two system properties. These system properties can be set as part of EXT_JAVA_OPTIONS in the setenv script.

Set the filter logging level to CONFIG to check the current configuration settings:

CONFIG \[com.gigaspaces.filters\]: Loaded users security permissions file 
from <f:/gigaspaces-xap/security/default-users>

Overriding Security Filename

By default, the filename is default-users. Here is how to override it with a custom name:

-Dcom.gs.security.file.name=my-users

This results in a path to <GigaSpaces Root>/security/my-users

Changing the Security Directory Path Within the GigaSpaces Installation Directory

By default, the security subdirectory is selected implicitly. To use a different directory structure, indicate a path as part of the URL property, i.e., start the URL with a forward slash (/).

-Dcom.gs.security.file.name=/my-security-folder/my-users

This will result in a path to <GigaSpaces Root>/my-security-folder/my-users

Moving Security Directory Outside the GigaSpaces Installation Directory

By default, the root directory of the security file is <GigaSpaces ROOT>. To manage the security file outside of the installation directory, you will need to set the following system property:

-Dcom.gs.security.file.dir=f:/foo/

This will result in a path to f:/foo/security/default-users
note the required '/' at the end of f:/foo/.

FAQ

Does the space need to be secured?

Can a non-secured GSC connect to a secured GSM?

GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence