Setting up users and groups

The software has multiple ways of ensuring user authentication and authorization of resources:

• Authentication identifies a user based on username and password, Windows domain association or external identity provider (IdP).

• Authorization uses the authentication information to grant the appropriate level of access control to the content and other tools.

• Multi-factor authentication with Duo.

Granular roles-based security allows the System Administrator to quickly control the exact level of access a group of users will have to FileHold. For example, a group of users may be restricted to 'Read Only' access for one type of file yet have full access to another document type. Security can be configured at multiple levels so documents can even be stored in the same folder yet carry differing permissions of access.

There are two types of user accounts: Locally Managed Users and Active Directory Synchronized Users. Both types of accounts can co-exist on the same FH Server.

• A Locally Managed user is an account that uses FileHold authentication or authenticates with an IdP.

  • FileHold authentication allows System Administrators to setup and manage users without involving complex IT deployment scenarios. This is suited for a non-technical System Administrator in a smaller organizational environment. Administrators can quickly create user accounts in mere minutes OR activate user self-registration. Self registration allows users to register themselves in FileHold without intervention of a System Administrator. These users can enter their full name, user name, and other contact details (which is optional). Unlike regularly registered users, self-registered users are placed into a single group that may have very limited permissions. The administrator re-assigns these users to a group that provides them with the access they need.

    If you are self-registering a group of people that have identical permissions and content access requirements internally then there may be no need for the group to have very limited permissions.

  • The IdP authentication option employs the Open Authentication standard (OAuth2) and allows the use of an outside system such as Azure Active Directory to authentication users. It makes single sign on possible without the use of a local Active Directory server and across a wide variety of applications. It also supports the self-registration concept, but the registrations are limited to users in your domain and you can directly assign them to groups via role or group claims at the IdP.

• FileHold Domain Users are users synchronized with an Active Directory domain. Likewise, FileHold Domain Groups are groups synchronized with Active Directory. Domain users and groups behave the same way as locally managed users when interacting FileHold. The difference is that the properties (contact information, passwords etc) associated with domain user/groups are managed externally in Active Directory and not through the user properties of the document management system. There are several benefits to synchronizing a domain with FileHold including Integrated Windows Authentication (IWA) or single sign on, automatic updating of name and other contact details changes, central control for user on/offboarding and central management of FileHold group assignments.

  Users from a domain can be added three ways to FileHold:

  • One at a time by selecting a specific user from a domain list,
  • Many at a time by selecting all users in a specific group from a domain list,
  • On demand from a domain group. In this case user group associations in FileHold can be automatically maintained over time each time the synchronization with Active Directory executes.

Image

Active directory users can also authenticate against a IdP, similar to local users where their email address is identical in both systems. This can also facilitate a transition to an IdP from native Windows authentication.

Managing user and group access in FileHold

Permissions in FileHold are determined by a variety of factors including their role assignment, their schema membership, their cabinet and folder membership and role modifications, their document ownership and whether or not they are participating in a workflow. Roles are assigned to groups and users are added as members of group inheriting the role of the group.

A user, outside the context of a group, has an inherent role equal to the highest role in all the groups where they are members. For example, a user may be assigned to a group with a read-only role and another group as a cabinet administrator. Their inherent role is cabinet administrator wherever inherent roles are recognized.

User roles are not relevant within the context of a document schema. For example, a user with a read-only role is a member in a schema on an equal basis with a user who has an organizer role. Inherent roles affect schema membership as users with an inherent role of cabinet administrator or higher are automatically members of all schemas.

Cabinet and folder library objects have the greatest impact on what access a specific user will have to a document. Inherent roles mean that senior library administrators and system administrators have access to all documents. Lower roles have access depending on their library object membership, whether or not their role has been reduced and whether or not they are an owner of the library object. For example, a library administrator assigned as a member of a cabinet has fewer permissions than one assigned as an owner. Or, a document publisher could have their role reduced to read-only for a specific folder. And, a user could be in two groups with the document publisher role, but one that allows downloads and one that does not. These groups could be assigned to different folders giving the user the ability to add documents to both, but in one case they could not download the document after they added it.

The following flowchart depicts how users and groups are set up in the system.

Image