Administration interface users

Funnelback provides the ability to partition a Funnelback installation to allow individual people to manage their own search packages, data sources and results pages.

Upon installation, an administrator user is created to manage all collections, and this user has the ability to create users and roles with varying levels of permissions within Funnelback.

Although for some Funnelback installations simply using the single administration user for all tasks may be appropriate, we encourage administrators to make features such as the marketing dashboard available to interested parties within their organisation.

Other possible applications of the Funnelback security model include:

  • Allowing a web-designer to upload and download search templates within an existing implementation; or

  • Allowing a manager to view query reports on particular collections without granting the ability to change technical implementation details.

Managing users and roles

Administration users and roles can be managed by selecting manage users and roles from the settings menu of the administration dashboard.

From these pages users may be added, edited, have their passwords changed or be removed entirely. Similarly, roles may be added, edited or removed from the system.

Funnelback’s roles features allow for any permission or capability traditionally assigned directly to users to be granted to a role, which can then be granted to many individual users, simplifying permission management over time.

Creating and editing users

When a new user is created you will be asked to select the client, provide user details, set the user’s password, assign the user to any roles they should have and finally grant permissions to manage the new user.

In Funnelback 16.0 administration user IDs changed, requiring the client ID to be prepended to the username. If a unique username is chosen it is possible to log in to Funnelback with the username as the administration user ID. However, note the following limitations:

  • The simple name is the full username with the clientID and tilde removed. e.g. a username of client1~bob would have a simple name of bob.

  • The simple name is matched against the username field of the user account (so if an email address is used as the username this should not be confused with the email field).

  • This only works for local administration logins (SXC, SAML logins are not supported). In practice SXC and SAML logins are mapped to local logins using a groovy user mapper so in most cases it will also work for these.

  • If the simple username is not unique then logging in with the simple username will map to the first matching user. e.g. if both client1 and client2 have a user called bob then there are two user IDs (client1~bob and client2~bob). In this scenario you must login with the full username to guarantee that you will log in as the correct user.

When creating a new user use an email address for the username. This will ensure a unique username and also enable users to log in using only their email address (rather than a longer form ID that includes the client ID).

Once the user has been created, these details (other than the username) can be edited, and specific settings can be adjusted including:

  • Assigning specific permissions to the user (though we encourage using roles where possible)

  • Assigning roles to the user and granting the right to edit a role or grant the role to other users

  • Allowing the user to see some or all collections on the server

  • Allowing the user to see some or all profiles on the server

  • Allowing the user to create specific types of collections and associate them with licenses

  • Allowing them to manage some other users/roles, other users/roles matching some suffix (e.g. all users who’s username ends in @example.com) or all other users on the system

  • Allowing them to acknowledge accessibility auditor issues at selected levels of scoping

In context help is provided for each of these actions within the user editing screen.

Please note that Funnelback does not provide any interface to manipulate user specific file manager rules. If required, it is recommended that these are directly edited into a role.ini file and then that role is granted to the users that need it.

Creating and editing roles

Funnelback includes a set of default roles covering a number of common permission scenarios, such as administrator users and users who can access only search analytics.

New roles can also be created and edited to match the specific requirements of a Funnelback installation.

The role will initially require a name and a list of roles (or users) who should be granted permission to manage the new role. Once created, the role can be assigned any of the permissions or settings a user may have, as described above.

As with the user editing screen, in context help is provided for each section of the role editing screen.

Please note that roles may also be assigned other roles, which allows for higher level roles to be assembled from sub-roles rather than being recreated from scratch.

Upgrading users and roles

Users and roles are automatically upgraded during the Funnelback upgrade process. It is also possible to manually apply these changes by calling update-configs.pl.

When a new permission is introduced, the user or role may gain this permission based on what the user or role previously had. For example, a newly introduced permission can_taste will be granted to any user or role that already had the permission can_chew. Sometimes, these new permissions may be granted based on having a combination of multiple existing settings. For example, can_eat is only granted if the user or role previously had can_chew and can_swallow. If the user or role does not have both of these permissions, they will not be given can_eat.

Caveats

Upgrading of users and roles is done in isolation and does not consider inherited permissions. In the example above, it is possible that the user being upgraded has both permissions can_chew and can_swallow through the inheritance of multiple different roles. So if a user gets can_chew from one role and can_swallow from another role, even though the user has access to both permissions, they will not be given can_eat.

Manually upgrading users or roles may not result in exactly the same results as going through the upgrade process because the upgrade process may also update the default file-manager rules. This can result in new permission not being granted because the user or role no longer has access to something that was previously granted in the default file-manager rules.

Please refer to release notes where any changes in users and roles permissions will be mentioned.

© 2015- Squiz Pty Ltd