Summary: GigaSpaces uses the space filtering mechanism to perform authentication and authorization.
OverviewGigaSpaces uses the space filtering mechanism to maintain authentication and authorization. The default security filter supports authentication and authorization. Authorization ProcessThe 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 AuthorizationTo 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. ConfigurationThe 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
Security Filter AuthenticationGigaSpaces 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) ProcessImplicit loginWhen 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.
Explicit LoginThe explicit login operation can be performed in one of two ways:
The Users FileThe 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. ConsiderationsThe location of the security file must be shared or copied to all instances of the GigaSpaces installation. ConfigurationThe security file URL is specified in the space schema. It can be overridden using an XPath property. 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 XPathspace-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 Propertyspace-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. 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 Using Existing User Accounts ListIn 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 ListYou 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 ).
|
![]() |
GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence |