Users, user licenses and user authentication terminology explained
There can be ambiguity when referring to "users" in FileHold. Context and adjectives may be useful in determining exactly what is being discussed.
Product function
There are two types of users when it comes to the functionality of the product: internal and external. Most of the time when we are talking about product functions and users, we are referring to "internal" users. Nearly all product functions require an internal user. There are two exceptions: Courier transmission access and external signatures.
Courier transmissions can be sent to internal and external users. External users are created on-the-fly by the person sending the Courier transmission by simply supplying a valid email address. They will appear in the Courier status report and usage log when they interact with the transmission or documents. Only external users will consume Courier one-time licenses.
Like Courier transmissions, digital signature requests can be sent to the external signature provider with internal and external users to sign. Since the interaction of these users are entirely within the external signature provider, only the audit report from the external signature provider will show the actual actions of the signers.
External users are always authenticated internally within FileHold and are considered local FileHold users.
Additional reading:
Licenses
There are four types of user licenses in FileHold. The user license determines the scope of operations that the user can perform.
| Description | Desktop client | Web client | Mobile client | API | Courier | Anonymous portal |
|---|---|---|---|---|---|---|
| Full registered | ✔ | ✔ | ✔ | ✔ | ✔ | ✘ |
| Limited registered | ✔ | ✔ | ✔ | ✔ | ✔ | ✘ |
| Portal alias | ✘ | ✘ | ✘ | ✘ | ✘ | ✔ |
| Courier one-time-use | ✘ | ✘ | ✘ | ✘ | ✔ | ✘ |
Additional reading:
- Creating or viewing locally managed users
- Adding Active Directory users and groups as FileHold users
- Courier one-time licenses
Authentication
All users accessing FileHold must be authenticated. This ensures that only valid users are accessing FileHold and able to see only the documents they are entitled to see. There are four methods for authenticating with FileHold as a user.
- Local FileHold authentication - FileHold uses the username and password provided at the login screen to authenticate these users against usernames and hashed passwords in the FileHold database. No special integrations are needed to have this category of users in your system. They work immediately out-of-the-box. They are managed exclusively with the FileHold user management tools.
- External identity provider authentication - FileHold does not attempt to authenticate users in this scenario. Instead, the authentication process is handed off to an external identity provider such as Azure Active Directory, SecureAuth, Okta, Auth0, etc. The entire authentication handshake between the user and the identity provider is transparent to FileHold. When it is finished, FileHold simply gets a positive or negative response from the identity provider and creates or denies a user session accordingly.
- Active directory domain authentication - FileHold uses the username, password and domain provided at the login screen to authenticate these users with the provided active directory domain. The user is only able to provide a domain that has been previously synchronized with FileHold.
- Implicit authentication - This is used in two cases: the anonymous portal and Courier transmissions that do not require passwords. These users are authenticated by simply knowing the address of the portal or the Courier transmission link. The anonymous portal scenario is a special case of local FileHold or domain authentication.