Server Administration Application – Configuring Ebase
Security
See also: Server Administration Application Home Page, Ebase Xi Security System
The Ebase Xi system is supplied with a built-in security system which supports the definition of users, roles, authorizations, groups and group memberships. Use of this security system is optional. The security system can be maintained on the server using the Server Administration web application as shown below.
The meaning of the various columns shown above is explained in the next section.
User properties can be edited when either creating a new user using the icon or clicking on the name of an existing user. Users can be associated with roles; this can be done directly using the roles boxes shown below, or by associating the user with one or more groups which are, in turn, linked to roles.
User tab:
User name |
The user name – this is only editable when creating a new user |
Reset password |
Click this checkbox to show password fields where a new password can be entered. This checkbox is only shown when editing an existing user. |
Password |
User password |
Confirm password |
User password |
Roles tab:
Drag roles from the Candidate roles box to the User roles box to add a role to the user. Use the reverse process to remove a role. Any roles inherited from groups are shown for information purposes at the bottom of this tab.
Groups tab:
The Membership column is only enterable if the group supports memberships.
Role properties can be edited when either creating a new role using the icon or clicking on the name of an existing role. Each role consists of a role name plus optionally any number of authorizations. The role name can be used programmatically to check whether a user has a certain role e.g. in Javascript: system.securityManager.hasRole(“Admin”) or FPL hasRole(‘Admin’), and can also be used in workflow assignment. Authorizations can be used to provide more granularity in a security check and are used by the following features within Ebase Xi:
Click here for more information on roles and authorizations.
Role tab:
Role name |
The role name – this is only editable when creating a new role |
Authorizations tab:
Each authorization contains three basic attributes: type, name and function and all three are required, though wildcards (*) can be specified in each case. These three attributes are matched against the corresponding attributes when a security authorization is checked e.g. in Javascript: system.securityManager,isAuthorized(“Accounts”, accountName, “Read”).
Action |
· Allow - returns true to an authorization check that matches the authorization · Prevent - returns false |
When this is checked an audit record is written to the
security log detailing the userid, the request, the
authorization that was used to process the request, and whether the request
was allowed or denied. The security log files are controlled by the following
three parameters in security.properties: Ufs.auditLogDirName Ufs.auditLogFileName Ufs.retainOldAuditLogs |
Group properties can be edited when either creating a new group using the icon or clicking on the name of an existing group. Groups can be associated with roles and users can be associated with groups: this provides an alternative way of assigning roles to users.
Groups can also optionally have memberships: these are used with a legacy workflow assignment technique.
Group tab:
Group id |
The group name – this is only editable when creating a new group |
Group members |
Shows the users who are members of this group – this is read only |
Group Roles tab:
Drag roles from the Candidate roles box to the Group roles box to add a role to the group. Use the reverse process to remove a role. All group roles are inherited by group users.
Supported Memberships
tab:
Membership |
The membership name |
Exclusive |
Check this to indicate that the membership can only have one member e.g. teamLeader |
v