Summary: GigaSpaces uses the space filtering mechanism to perform authentication and authorization.

Overview

GigaSpaces uses the space filtering mechanism to maintain authentication and authorization. The default security filter supports authentication and authorization.

Authorization Process

The space authorization defines which operations a user may perform on the space. GigaSpaces uses a set of predefined roles and user-defined custom roles that specify whether a user has read-only, read/write, or administrative permission to the space. Write permission provides access to all destructive space operations - write, update and take.

Client Side Authorization

To eliminate the security performance overhead, the space proxy itself performs client side authorization. Any user who sends an initial context via the space security filter is assigned a token. This token represents the user's basic roles and defines whether that user may perform read/write or administration operations. The proxy uses this token to detect if a user is attempting to perform an unauthorized operation. If so, it will throw a SecurityException and will not communicate with the space. Custom roles and class-based filtering are done on the space side.

Runtime updates – Whenever you add users and update their roles via the space browser, there is no need to restart the space.

Configuration

The configuration required to set up the default security filter done via the following properties:

space-config.filters.filter-names=DefaultSecurityFilter
space-config.filters.userAccountDriver=com.j_spaces.core.filters.MemoryRealm
space-config.filters.DefaultSecurityFilter.enabled=true
space-config.filters.DefaultSecurityFilter.security=true
space-config.filters.DefaultSecurityFilter.class=
             com.j_spaces.core.filters.DefaultSecurityFilter
space-config.filters.DefaultSecurityFilter.active-when-backup=true
space-config.filters.DefaultSecurityFilter.shutdown-space-on-init-failure=false
space-config.filters.DefaultSecurityFilter.operation-code=0, 2, 3, 4, 6, 8, 9, 11, 13
space-config.filters.DefaultSecurityFilter.url=default-users
space-config.filters.DefaultSecurityFilter.priority=1
  • The security property indicates that this filter is a security filter and therefore should maintain a security context.
  • The class property points to the default implementation of the security filter.
  • The url property points to the location of the users encrypted file. This file stores the users lists and their roles.

For more details on the filters setup, refer to the Space Filters section.

Security Filter Authentication

GigaSpaces uses the Account driver to access the user accounts file. The default driver uses the default-users encrypted file. Each accounts file contains the username, password system roles, and user-defined custom roles.

Space Authentication (Login) Process

Implicit login

When the space proxy is loaded into the application VM, it automatically performs an initialization process with the space. This invokes the server security filter setContext API, that sets up an initial permission to the space.

By default, a secured space is assigned with "anonymous" user roles (user anonymous and password anonymous). The anonymous user must be defined in the user's accounts file.

Explicit Login

The explicit login operation can be performed in one of two ways:

  • Using system properties to define the user name and password:
    GigaSpaces security system properties:
    User Name com.gs.security.userid
    Password com.gs.security.password

    You can add these system properties into the gs-ui script to avoid typing at the logic window user/pass when accessing each secured space.

  • Using a call to the IJSpace.setContext method. The IJSpace interface provides security methods.

    For more details, refer to the setSecurityContext(com.j_spaces.core.SecurityContext) method.

OpenSpaces users should use the os-core:security to inject the user and password information.
See the Space Component Security Context section for more detials.

The Users File

The GigaSpaces default security filter uses the default-users file, located under the <GigaSpaces Root>/security directory, as the default user accounts list. To add or remove a user, use the GigaSpaces Management Center's Security Filter dialog. Changes take effect when clicking the Update button. No need to restart the space.

Considerations

The location of the security file must be shared or copied to all instances of the GigaSpaces installation.

Configuration

The security file URL is specified in the space schema. It can be overridden using an XPath property.
The default:

space-config.filters.DefaultSecurityFilter.url=default-users

Set the filter logging level to CONFIG to verify the applied configuration.

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

Overriding Security File URL Using XPath

space-config.filters.DefaultSecurityFilter.url=my-users

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

Overriding Security File URL Using XPath Resolved By System Property

space-config.filters.DefaultSecurityFilter.url=${my.security.url}

The URL value will be resolved at runtime. This is helpful, for example, when a space is deployed into a secured GSC and all the spaces deployed should refer to the same security file.
Note that (only) in 6.6.2, the URL is always overriden by -Dcom.gs.security.file.name.

Changing The Implicit 'security' Directory

By default, the security sub-directory is implicit. To manage a different directory structure, indicate a path as part of the url property – in other words, start the URL with a forward slash (/), followed by the desired path.

space-config.filters.DefaultSecurityFilter.url=/my-security-folder/my-users

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

Changing the root directory

By default, the root directory of the security file is <GigaSpaces Root>. To manage the security file out-side 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
The system property can be set as part of EXT_JAVA_OPTIONS in the setenv script, or passed to the space within a properties file.

Using Existing User Accounts List

In many cases, users who need to access the space are already defined in the application's user accounts database or directory service. The default security filter provides a plugin mechanism to integrate with the user accounts list for existing users.

Integrating a Custom Users File List

You may use an external directory service to load user permissions to be used as part of the space authentication process.

In order to customize the DefaultSecurityFilter to use an external users list, you should implement the ISpaceUserAccountDriver (com.j_spaces.core.filters.ISpaceUserAccountDriver; see Javadoc ).

  • The space-config.filters.userAccountDriver property should include the class name that implements the ISpaceUserAccountDriver interface.
  • The following format is used for the second argument in the ISpaceUserAccountDriver.init( String URL ) method:
    <GigaSpaces Root> + File.separator + "security" + File.separator + <DefaultSecurityFilter><url>, that is, the GigaSpaces root directory, followed by your operating system's file separator, followed by the string DefaultSecurityFilter, followed by the custom URL.
If you are using a custom User Account Driver, you will need a custom tool in order to modify the user list. This can't be done using the GigaSpaces Management Center/ CLI.
GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence