Understanding the Default Security Configuration File
In order to understand the security configuration file, we must first understand authorities and roles.
What is an Authority?
An authority is a list of functions (system tasks). If an authority is assigned to a user, then the user can perform the authority-related functions.
Authorities are pre-defined in GigaSpaces and cannot be created or altered by the user.
Authorities are cumulative — if a user is assigned two authorities, they are able to execute all of the functions for both authorities. Below is a list of authorities that are available in GigaSpaces.
| Authorities Used in Pre-configured Roles | |
|---|---|
| Authority | Description |
| MANAGE_GRID | Start, terminate, restart of GSC/GSM/LUS |
| MANAGE_PU | Scale up/down, scale in/out, relocate, restart PU instance, destroy PU instance |
| MONITOR_JVM | Monitoring of JVM statistics |
| MONITOR_PU | Monitoring of Processing Units (classes, connections, statistics, etc.) |
| PROVISION_PU | Deploy, undeploy of processing units |
| SPACE_READ | Read, Count and Notify operations |
| Additional Authorities | |
|---|---|
| Authority | Description |
| SPACE_WRITE | Write and update operations |
| SPACE_TAKE | Take and Clear operations |
| SPACE_EXECUTE | Execute tasks |
| SPACE_ALTER | Register type descriptor, Clean and Drop-Class operations |
| SPACE_CREATE | Write only (no update) operations |
What is a Role?
A role is a list of authorities. Roles can be defined for convenience, to easily assign the same list of authorities to different users. You can use the pre-configured GigaSpaces roles, and you can create your own role definitions. The pre-configured GigaSpaces roles are as follows:
| Role | Authorities |
| ROLE_ADMIN | MONITOR_JVM, MONITOR_PU, SPACE_READ, PROVISION_PU, MANAGE_GRID, MANAGE_PU |
| ROLE_MNGR | MONITOR_JVM, MONITOR_PU, SPACE_READ, PROVISION_PU |
| ROLE_VIEWER | MONITOR_JVM, MONITOR_PU, SPACE_READ |
Creating Your Own Roles — the Security Configuration File
The default security configuration file is located at ../config/security/security-config.xml.
The relevant lines in the files are described in the following table. As you can see below, you may modify lines 14 to 19 to define your own roles.
| Lines | Text | Notes |
|---|---|---|
| 3-9 |
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:sec="http://www.springframework.org/schema/security" xmlns:util="http://www.springframework.org/schema/util" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-3.1.xsd"> |
This defines the Spring security framework. |
| 11-12 | <!-- This password encoder is provided for getting started and testing purposes only and is not considered secure. --> <bean id="passwordEncoder" class="org.springframework.security.crypto.password.NoOpPasswordEncoder"/> | Define the class used for password encryption. In this example, no password encryption is used. |
| 14-19 |
<!-- Predefined role to privileges mapping (ROLE_VIEWER, ROLE_MNGR, ROLE_ADMIN). -->
<util:map id="roles"> <entry key="ROLE_ADMIN" value="MONITOR_JVM, MONITOR_PU, SPACE_READ, PROVISION_PU, MANAGE_GRID, MANAGE_PU"/> <entry key="ROLE_MNGR" value="MONITOR_JVM, MONITOR_PU, SPACE_READ, PROVISION_PU,"/> <entry key="ROLE_VIEWER" value="MONITOR_JVM, MONITOR_PU, SPACE_READ"/> </util:map> |
Define the roles that will be used to provide users with system access. These roles are assigned to users on lines 28-39 below. This is where you can define your own roles. We recommend the following naming convention for user-defined roles: begin the name with ROLE_ |
| 21-25 |
<!-- Populates user details with authorities declared by associated role -->
<bean id="roleBasedUserService" class="com.gigaspaces.security.spring.RoleBasedUserService"> <constructor-arg ref="userService"/> <constructor-arg ref="roles"/> </bean> |
Bold text defines this as a Spring security implementation. |
| 28-39 |
<sec:authentication-manager>
<sec:authentication-provider user-service-ref="roleBasedUserService"/> <sec:authentication-provider> <sec:password-encoder ref="passwordEncoder"/> <!-- prefer BCrypt --> <sec:user-service id="userService"> <sec:user name="gs-admin" password="gs-admin" authorities="ROLE_ADMIN"/> <sec:user name="gs-mngr" password="gs-mngr" authorities="ROLE_MNGR"/> <sec:user name="gs-viewer" password="gs-viewer" authorities="ROLE_VIEWER"/> </sec:user-service> </sec:authentication-provider> </sec:authentication-manager> </beans> |
Highlighted text shows that this is an in-memory security implementation — the user information is coded here, inline. Note that if we were accessing external security information, instead of the highlighted text, we would code an external reference, as in this example of LDAP security: <sec:authentication-manager> <sec:authentication-provider ref="ldapAuthenticationProvider"/> </sec:authentication-manager> |
