ETCETERA Authorization Services (AUTH) is the security framework utilized by ScerIS ETCETERA. It controls authentication and authorization. Authentication refers to verifying that a user is who he or she claims to be. Authorization is the granting of privileges to an authenticated user. AUTH includes various software components that tie directly into ETCETERA modules, and a centralized management utility that enables system administrators to configure permissions and security schemes for all managed products.
AUTH Architecture: In general terms, implementing security with AUTH requires understanding that:
- A user gains permissions to ETCETERA software by being a member of one or more groups.
- The permissions provided by a group are defined by the roles and classes included in the group.
- A role packages one or more permissions needed for a user to undertake a task.
- A permission consists of a resource associated with an action.
- A resource is an object associated with an access condition (if applicable).
- An object is an element of an ETCETERA module.
User: A user is a Local or Domain windows account with access to an ETCETERA module as configured by an administrator using AUTH. Add a user to AUTH first and then assign them to one or more AUTH groups to determine their permissions for different modules. AUTH supports two types of user accounts:
- Windows Authentication– Import the user’s existing Microsoft Windows account information and AUTH automatically authenticates the user using the associated Microsoft Windows account login information.
- ScerIS Authentication– Used to provide access to ScerIS modules for users who do not have Microsoft Windows accounts. AUTH produces a random password for the user and requires the user to change their password at the next login. Password policy for ScerIS users is configurable; users are locked as the result of invalid logins (quantity is configurable). The administrator can set a period for the password to be valid and set the number of days before password expiration that notification to the user is required. AUTH passwords have a default setting for password complexity. Using a regular expression, the password must consist of at least six characters, include a letter of the alphabet, at least one number, and one character that is not a number or regular character. To change password requirements, simply use a different regular expression.
Groups: A group aggregates permissions (using Roles) as well as class access into one entity so that you do not need to assign rights to each individual user. A user cannot access a ScerIS application without being a member of a group. ScerIS Auth provides pre-defined groups based on the primary responsibilities and tasks of different sets of users. A group aggregates permissions (using Roles) as well as class access into one entity and a user must be a member of an appropriate group in order to access a ScerIS application. Predefined groups include archivers, creators, editors, viewers, process admins, system admins, service, admins and users.
Roles: A role packages the permissions needed to undertake a task in a specific application.
Permissions: Permissions determine what actions users can perform on resources. They are the building blocks of ScerIS Auth roles, and are created from Resources. Permissions are assigned to one or multiple roles, but never directly to individual users.
Actions: Actions determine what a user can to do with the software element. Actions are pre-defined in AUTH. Among the many actions available are Create, Delete, Route, and Sign. Actions are not standalone entities; actions modify resources. The actions available are specific to the resource.
Resources: A resource is an object (element) of an application, coupled with an access condition (when available). An access condition more precisely defines access to the object (for example, you can restrict access to the AUI object by associating it with the access condition of a specific AUI class.)
Access Conditions: When appropriate, an access condition is associated with an object to describe the state or status of the object (examples of these conditions include Objects being assigned to a user, having been routed, or being a member of a particular class.)
Object: An object is an individual element that can be controlled in an application, such as an Online AUI or a software command or feature. Objects are building blocks for Resources. AUTH includes a large set of pre-defined Objects for various ScerIS applications. You must create a Resource from an Object before you can use it to create a permission.