Roles

During the console login process, the user is assigned a security role. The security role determines what the user can do and which emails the user can see. Refer to Logins to learn how roles are assigned to users.

There are five main aspects to role definition:

• Permissions – controlling what the user can do (e.g. delete email)
• View filters – defining which emails the user can see (e.g. normal users can only see their own emails)
• Role Priority - controlling which roles match over others.
• Role Editing Permissions - in support of delegated administration, administrators can only edit lower priority roles (than the one they are assigned)
• Built-In Roles - understanding built-in roles

There are three built-in roles in the system: administrator, auditor and user.  When a user logs, roles are assigned according to the role assignments defined in Logins. The ordering of roles in the list is significant. During user login, the highest matching role will be assigned to the user. To change the role priority, click the up and down arrows next to the role name.

The default permissions and view filters associated with these roles are described in below.

Permissions

View Filters

The role view filter field is used to specify which emails are visible to those users assigned the role.

The default Role View Filters are as follows:

Own Mail View Restriction

anyaddress:%email%

To restrict those assigned the role to see their own emails only, set view filter on the assigned role to anyaddress:%email%.

The macro %email% is expanded out with the email addresses retrieved from Active Directory or LDAP mail attribute field.

Domain View Restriction

anyaddress:company.com

To restrict those assigned the role to see all emails from their own domain, set view filter on the assigned role to anyaddress:%domain%.

The macro %domain% is expanded out with the domains extracted from the logged in users email addresses. 

To restrict users assigned the role to view emails from a particular particular domain only, enter anyaddress:company.com.

It is also possible to hard code a particular email address, such as anyaddress:"joe@company.com"

Active Directory User Group Restriction

memberof:%memberof%

To restrict those assigned the role to see all emails in all Active Directory groups they belong to, set the view filter to memberof:%memberof%.

To restrict users to see emails belonging to a specific group, use memberof:Marketing or memberof:"Sales Department". You can test the query in the search view. 

Giving A User Access To Another Users Mail

anyaddress:(%email% tompeters)

In some circumstances, it is desirable to provide a user with access to another users emails. There are two ways of achieving this Either by creating a new role for the new employee with a modified view filter or by adding a new email address to the user's proxyAddress/mail field.

Adding a New Role

1. In Configuration->Roles, create a new Role for the user to which the new view mailbox right will be assigned
2. In the Role View Filter enter the equivalent of 'anyaddress:(%email% tompeters)
3. Increase the priority of the Role (using up and down arrows), so that new role takes precedence over other roles (for example, User role).
4. In Configuration->Logins, for the user to be granted access, create a new role assignment that that refers to the newly created role above
5. To test, Logout and then login as the user to be granted access

Adding an Email Address in Active Directory/Azure/LDAP

In the case where an employee leaves the company, and there is the requirement for a new substitute employee to access the ex-employee's email, rather than create a new role, it may simply be easier to add the ex-employee's email address to the proxyAddresses or mail field of the new employee.

Further explanation: When a user logs into MailArchiva, all the email addresses associated with the user are obtained from Active Directory/Azure/LDAP, and then used for filtering purposes. Thus, to provide access to the ex-employee's emails, simply add the ex-employee's email address to the new employee's email list. Depending on the specific mail server in question, one can do this by modifying the proxyAddresses attribute, mail attribute, or otherwise in the user properties in Azure/Active Directory/LDAP Console. The email addresses are only obtained during the login, so between testing cycles, be sure to logout the user.

Custom Filter Query Construction

subject:ceoreport

In the Role view filter, it is possible to enter a wide range of queries. The query syntax and search fields are the same as those used in the main search function. In fact, for test purposes,  it is often a good idea to test the filter query in the main search interface.

Role Priority

The order in which roles are displayed in the Roles section is significant.  Roles assigned a higher priority appear higher in the list. During role assignment, role priority is significant. A matching role with the highest priority will always be assigned over a lower priority matching role. Refer to Logins to learn how roles are assigned to users. To change the priority of a role,  click the up and down arrows in the Roles section.

Role Editing Permissions

To enable administrators to delegate administration functions to other administrators without compromising security, users assigned a particular role may only edit roles assigned a lower priority than the logged user's own role. Thus, assuming there are three roles A, B and C (in order of priority). If a logged in administrator is assigned Role B, that administrator will be able to edit role C, but not A and B.

Built-In Roles

There are four built in roles: the User Role, Audit Role, Administrator Role and Master Role. The Master Role permission can only be edited in the server.conf directly and are not visible in the Administration console. The characteristics of these built-in roles are described further below. If the built-in roles are not suitable, you can define one or more custom roles. To define a custom role:

• Click on the “Add Role” button in the Roles section of the server console
• configuration screen
• Enter an appropriate name for the role
• Select the permissions associated with the role
• Add a view filter clause to limit which emails users assigned the role can view

User Role

The User Role is used for the purposes of enabling employees to access to their own emails in the archive. The macro “%email%” in the view filter restricts users who are assigned the role to viewing emails that concern themselves only. In addition, users assigned the User Role are, by default, unable to alter the configuration of the system.

When defining a view filter, the macro %email% will be replaced with the email address of the logged-in user. Thus, by selecting “any address” and entering “%email%” as a value, you will effectively limit the user to seeing their own emails only.

In a Role View Filter, it is possible to specify a complex filter query in accordance with the MailArchiva query syntax. This is useful in a number of scenario's. For example, say one wanted to grant a particular user access to another user's emails. One could create a role for that user, and specify anyaddress:(%email% OR john.adams@*). In this example, the logged in user will be able to see all John Adam's mail (for your reference: there are also other ways to accomplish the same behaviour. Hint: alternate email attribute and value in LDAP/AD authentication).

Audit Role

The main difference between the built-in Audit Role and the User Role is that its view filter is empty, meaning auditors are able to access the emails of every person in the company.

Administrator Role

Administrators are capable of modifying the configuration of MailArchiva, excluding role definition and login configuration. For security reasons, they are not permitted to view all emails of all users in the archive.

Master Role

The master role is assigned when a user is logged in as the “admin” user. The master user is all powerful and has the ability to access all functions of the system, including view all emails in the archive.