Gimmal Physical security primarily implements a role-based model supporting either forms or single-sign on authentication like that found within Windows Active Directory or Active Directory Federated Services. An unlimited number of roles are supported.
The model itself consists of two halves, the first restricting data access, and the second is application functionality.
Security roles and their associated privileges are managed from within the Gimmal Physical module, sample screen shots of which are shown below.
The Gimmal Physical application may be accessed via either Forms or Single Sign On. Configuration of the authentication mode is managed within the application’s corresponding web.config file.
When under Forms authentication, all security credentials are managed within the Gimmal Physical application itself, including Username and Password. Gimmal Physical supports the standard suite of password complexity rules including password length, types of characters required, lifespan, and number of failures until lockout.
When running on-premises against Active Directory (using Integrated Windows Authentication), each time a Gimmal Physical user attempts to access the Gimmal Physical application via the client-specific url, their network domain- specific User ID is used to query Active Directory to determine which, if any, Gimmal Physical -specific domain groups they belong to.
Gimmal Physical makes this determination based upon a textual comparison of Gimmal Physical roles defined within the Gimmal Physical application compared to role names defined with the network domain (e.g. ‘Gimmal -administrator’ or ‘Gimmal Physical -Records Officer’). Outcomes include:
If no Gimmal Physical -specific domain group memberships are identified, the user is denied access to the application.
If a Gimmal Physical -specific domain group membership is identified, Gimmal Physical checks for the existence of an internal Gimmal Physical user record. If one is found, Gimmal Physical updates that record with any changes found from linked Active Directory fields. If one is not found, Gimmal Physical creates the internal Gimmal Physical user record, populating it with any linked Active Directory fields.
If more than one Gimmal Physical -specific domain group membership is identified, Gimmal Physical selects the first it finds and processes authentication via #2 above.
When using Single Sign On against an Identity Provider which can utilize SAMLv2, (such as OKTA, ADFS, or AAD) Gimmal Physical will authenticate the user based on the assertion sent by the IdP. Gimmal Physical can be configured to recognize a specific claim as username information and will find/create the user record in Gimmal Physical based on that information. Gimmal Physical can also assign the user to a role and configure other metadata based on the claims sent in the assertion.
Gimmal Physical data security may be configured at table, row, or column levels.
Table Level Security
Table level security corresponds to individual data tab within Gimmal Physical, allowing or preventing access to those screens. Table level security is managed via simple checkbox driven logic within the security module as shown below. A common example is granting or denying access to the Holds tab.
Column Level Security
Column level security provides the ability to hide individual data elements. Column level security is managed via simple checkbox driven logic within the security module as shown below. A common example might be to hide the Scheduled Destruction Date for boxes or files.
Row Level Security
Row level security provides the ability to restrict users to those data records specific to them. Row level security may be implemented via Tab Filters, Secured Lists, or User-level meta-data, an example of each shown below.
Gimmal Physical functional security provides the ability to grant or deny access to virtually every functional capability within the software, corresponding to the application ribbon and action menus displayed below.