Security Model |
FileHold consists of several separate applications which must share information about the session. All sessions are stored in the Global Session Cache which is located in the User Role Manager application. Other applications retrieve the session details from the User Role Manager. To minimize overhead, that information is temporarily cached in their own Local Session Caches and only refreshed when necessary.
The image below shows how sessions are created, cached and shared within FileHold. When a user logs in using the Session Manager, the session is first created in the Global Session Cache. When a method of another web service is called for the first time, the session doesn’t yet exist in the Local Session Cache of the service, so the service must ask the Session Manager to confirm that the FHLSID represents a valid session and retrieve the user’s identity. When another method is called in a short period of time, the FHLSID can be verified directly using the Local Session Cache.
The Web Client works in a similar way, except it doesn’t store the FHLSID but passes it back to the browser as a cookie. Every time a page is displayed, the identifier is retrieved from the cookie and forwarded to appropriate web services.
Authorization in FileHold is based on roles. A role determines what operations can be performed by the user. For example, a Read Only user can access and download documents, but cannot add or modify them. Library Administrators can manage document schemas and fields and System Administrators can manage users and groups. The role of a user depends on the FileHold group to which the user belongs. A user can inherit multiple roles from multiple groups.
For each role there is a predefined set of operations which the user with that role is allowed to perform. Many actions consist of many low-level operations. For example, copying a document requires access to the folder and the document schema as well as the right to create documents in the destination folder. The permission to perform the operation often depends on some other condition; for example, some users can create documents only in folders that they own.
Some operations are not performed in the context of any user, but in the context of the service account – for example the scheduled tasks which send notifications and update the full text search index. These operations cannot be performed using the public API, but only by calling the internal services which require Windows authentication.