Define Akula Server Administrators
When you install the Akula Server, you also install a predefined
server app scope that exposes REST endpoints used to configure the server and to configure app scopes running on the server. You use many of these endpoints to configure the authorization mechanism. For example, use these endpoints to create and configure roles, associate permissions with roles, and access information about security realms.
You access these endpoints by making an HTTP request to a URL controlled by the
server app scope, or by using the Akula Command-line Management Utility. The URL of these endpoints contains the word
server, as the following example shows for the URL to delete a role:
Every endpoint controlled by the
server app scope has predefined permissions that a user is required to have in order to make a request to the endpoint. For example, the endpoint shown above requires that the user be in a role that has the
Edit_Roles permission. If the user's role does not have the
Edit_Roles permission, a request to that endpoint fails.
At Akula install time, if you use the default configuration files described in Set up the Akula Server Environment, then you have a default administrator configured. Otherwise, no users have the necessary permissions to access the
server app scope. Therefore, any request to its endpoints fails.
Additionally, there are REST endpoints associated with individual app scopes. Many of these endpoints are used by a client apps to access a data source or to perform other actions controlled by the
server app scope. However, some of these endpoints might only be available to administrators and should not be accessible to normal users.
Configuring Akula Server administrators
Configure Akula Server administrators in two ways:
- Specify a user group that functions as the Akula Server administrators. Server administrators have the necessary permission to perform any action on any endpoint for any
serverapp scope controlled by the Akula Server.
The user group must be defined in your authentication realm (such as an Active Directory server). All users in that group have the necessary permissions to function as a server administrator. The procedure for specifying a user group that functions as the Akula administrators is described below.
- Associate individual administrator permissions with a role.
You typically associate individual administrator permissions to a role to give the users in that role limited administrator privileges. For example, associate the
Edit_Logspermission with a role to let the users in that role change the logging level of an Akula logger. For information on how to associate a permission with a role, see Authorizing Users.
Specifying a user group as the Akula Server administrator
To specify the user group that functions as the Akula Server administrator, edit the
AKULA_HOME/global/properties.xml file. The Akula Server reads the properties.xml file at start up. Therefore, after editing this file, you have to restart the Akula Server.
Set the following properties in the properties.xml file to specify the administrator group:
You typically leave the administrator group active at development time. When you deploy the Akula Server to a live site, and after you have configured roles and permission on the live site, you then disable the server administrator group to prevent unintended access to these services.
If it is necessary to expose administrator endpoints on a deployed Akula Server, use the authorization mechanism to individually allow access to that endpoint. For more information, see Authorizing Users.
|The name of the role corresponding to administrators. The Akula Server creates this role for you.|
|The realm containing the user group for the administrators. The name of the realm is determined by how you configured the connection to the realm. For more information, see Using Active Directory Server as an Authentication Realm.|
|The user group on the realm containing all administrator users.|
The example below shows the default values of the
display attributes of the
<akula-property> tag are optional and default to null. The
overridable properties are also optional, but have a default value of
true. In this example, you specify
false so that the property is not sent to the client on log in, and set
false so that the property cannot be changed at the app-scope level at run time. For more information on these attributes, see Using App Properties.