GigaSpaces Management Center (UI) allows to manage the Grid services and Processing Units running within the Grid containers. When security is enabled, the UI will restrict access to these services for non-privileged users.
Administrators can use the UI to manage users and roles, and allow them to Login and operate based on their granted privileges.
This section assumes familiarity with the Security Basics section.
Managing the directory can be done directly through the DirectoryManager API. GigaSpaces Management Center utilizes this API and exposes a convenient administration interface for managing the users and roles supported by the backed directory implementation.
Our default file-based implementation allows the directory to be administered only if the user has Manage Users or Manage Roles privileges. When the directory is first created (i.e. directory file doesn't exist), only an admin/admin user may be allowed to access and administer the directory. By default, the admin holds both privileges which allows declaring of new roles, adding users and assigning of roles. The admin user can be deleted, as long as you provide another user with management capabilities.
There is no need for any service to be up and running. Just choose from the title menu bar Security -> Manage Security and the management dialog will open.
This view is split into two tabs - Users and Roles. If you only have partial management roles, then only read-only actions are allowed.
The Users tab, displays a summary of all the users, their assigned roles, and user-specific privileges.
A user can be associated with predefined roles and be granted with user-specific privileges.
To associate a user with roles, choose the roles from the list of roles. Each associated role will appear in its own tab,
To assign a Monitor Privilege, System Privilege, or Grid Privilege select the privilege check-box.
To assign Space Privilege rules, use the + button to add a row to the Space Operations table. This grants the user the privilege to perform a space operation on the specified Class/Package name. The Space Operation can be one of Write, Read, Take, Alter, or Execute which can be chosen from the drop-down. To restrict the operation to a certain class, specify a Class/Package name (wild-card) filter and choose Allow or Deny.
The following snapshot shows that the user has:
The Roles tab, displays a summary of all the roles, its permissions and any assigned users to each role.
Creating a role is the same as creating a user with user-specific privileges. Except that these privileges can be associated by role-name to users.
The following role is set to have Monitor PU, Manage Grid, Provision PU, Manage PU, and a Space Operation rule allowing a Write of any class matching eg.Account*.
There are two options to perform UI login - directly from the command line or from within the UI.
You may find the command line option convenient when using pre-defined scripts. Use the command line arguments -user and -password with the user credentials.
To login from within the UI, choose from the title menu bar Security -> Login and the login dialog will open.
In distributed systems, the login credentials are authenticated with each service. Thus, the indication of success or failure is specific to each.
To logout, choose from the title menu bar Security -> Logout, which will cause a refresh of all discovered services.
If the user lacks sufficient privileges, the UI displays a similar message to the following:
The following table represents some of the actions that the UI disables when there are insufficient privileges.
The Deployment Wizard allows the deployment of a data-grid or a processing unit. In both cases, a GSM needs to be selected from the available list of GSMs. If the GSM is locked, you will be requested to Login.
It is important to understand the difference between the credentials supplied to the login dialog and the supplied credentials provided when deploying. The first, is used to authenticate the user against the services discovered by the UI, and allow actions to be performed. One of the actions is to deploy. When you are authorized to deploy, the credentials passed in the deployment dialog are propagated to the Processing Unit.
To deploy a secured data-grid, select the Secured Space checkbox. Supplying credentials is optional. If no credentials are supplied, a secured Space will be instantiated. If credentials are supplied, a secured Space will be instantiated, propagating the credentials to internal services (i.e. Space Filters).
Security configuration properties can be supplied, during deployment of a Space, as custom properties; Either from a file or added through the dialog.
To deploy a secured processing unit, select the Secured Space checkbox. As with a secured data-grid, supplying credentials is optional. The supplied credentials will be passed to the processing unit, to be propagated to the beans relying on the Space proxy.
For example, the data-processor has a polling container - when deployed, the credentials supplied need to meet the permissions required by the embedded processing units. In this case, a Take privilege. The data-feeder on the other hand, when deployed, needs Write privileges to write into the data-processor cluster.
Security configuration properties can be supplied, during deployment of a ProcessingUnit, as context bean level properties; Either from a file or added through the dialog.