XAP 6.6 Documentation > Back to Table of Contents
Securing the Grid Service Manager and Grid Service Container
Summary: Service Grid secured administration
OverviewThe 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. PrerequisitesThe 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. UsageTo 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, 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. ConsiderationsAt this time, the location of the security file must be shared or copied to all instances of the GigaSpaces installation. ConfigurationThe 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 FilenameBy 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 FAQDoes 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 |