Security

Objectives

Security is about giving the right users access to the right information in Umana, and protecting the rest. In particular, that includes protecting Umana from unauthorized intruders.

In other words, ensuring that...

Logon Security: Only authorized users can access Umana. Keeping out intruders.
Can DO: A user has access only to the appropriate modules, and the appropriate capabilities in each of those modules.
Can SEE: A user can access only information of the employees he should.

Web vs desktop: The same users, ids, passwords, rules applying to users of Umana Desktop apply to users accessing Umana via the web. There is just one data base and IDs / passwords /permissions apply to all access methods.

Security parameterization

Let's compare Umana security to Windows security:

In Windows there are USERS and GROUPS (roles).
In Umana we have EMPLOYEES and USERS, and GROUPS. So we have added a new element. (That makes sense: your users are your employees.)

Here is how these elements fit together in Umana.

Global security parameters are in Administration > Options > Security

Employees

Every employee (past or present) has a PERS record in Umana.

The User ID field on Tab 2: Address,Phone has the User Id for the employee to log on to Umana.

Best practice: Make the employee's Umana user-id the same as their Windows user-id, so you can use Single Sign-on for them.

To log on to Umana employees use their user ID and their password. They are the same for both desktop and web access.

If the user ID in PERS matches an ID in the USERS table, then that matching profile from the users table is applied.
If it doesn't, then Umana applies the DEFAULT user-id profile.
In either case, the related user in the USERS table, along with the groups it belongs to, controls the employee's access rights (capabilities and data).

Terminated employees

Terminated employees can not log on to Umana. You can control just which JSTAT (employment status) values are permitted in Administration > Options > Security. See also Users: Logon Security

Groups

A user group defines a role in Umana. User are members of groups.

Roles define access rights: module capabilities (can DO), and limits (filters) on which employees' data they can access (can SEE)

In other words, by being a member of a group a user inherits the access rights of the group.
Consider creating separate can-DO groups and can-SEE groups. Or maybe putting your can-DO limits on groups and can-SEE limits on users. Department filters on can-DO groups would not make sense.

Can DO

The more groups the user is a member of, the more he can DO in Umana.

Example: The supervisor of HR, by being a member of groups HR and SUPERVISOR, he can do whatever is allowed for either group.

For each group, Umana displays the list of all modules with the letters A, D, M and/or I alongside. The letters mean...

A - Addition allowed
D - Deletion allowed
M - Modification allowed
I - Interrogation only allowed
Letters A,D,M imply I (interrogation) as well

For some modules, other letters also apply. For example, in the Job module the letter "S" gives access to salaries. To find out the "other letters" available for a module:

Select the module.
Right-click on the Other field of the window. The pop-up menu is displayed.
Select the Help - field option.

Can SEE

Filters on what the user can SEE are more subtle, because they filter on individual fields of the employee record. To specify filters click -Filters...

Example-1: Suppose group "A" is limited to employees with PSTAT="PERM" (PSTAT = person status), and group "B" is limited to employees with PSTAT="TEMP".

Then a user who is a member of both A and B sees employees with either status (TEMP or PERM). So in this case, adding a group gives broader access.
Example-2: If group "C" has no filter on PSTAT, but group "A" does, then by a user becoming a member of group "A" actually reduces the set of employee dossier he can SEE, to employees with PSTAT="PERM".
In other words, filters on the same PERS field from different groups are combined with OR, so members see the union of the dossiers visible to each group. On the other hand, filters on different fields are combined with AND, giving the member access to only the intersection of dossiers allowed on each field filter.

You can also specify that a user can see only his employees. Use this for a manager restrict him to view only his employees.

To limit a user to seeing only his own data, remove the "F" (FIND) option from his capabilities in a module.

Users

A USER record defines the profile of a single employee - except for the DEFAULT user, which applies to all employees who don't have a specific user record.

To give an ID to an employee, enter the User ID in the employee's PERS record.
Do not use the same User-Id for more than one active employee.

The user record holds the employee's password and the groups they belong to. (For employees with the DEFAULT user, the password is in the PERS record instead.)

Groups and Users are similar: they both define what a user can DO and can SEE.

It is possible to have a USER not used by any employee – a user-id that no employee has. This can be useful for outside support (e.g. Carver Technologies). With no associated PERS, Multi-factor Authentication is not possible and certain functionality will be limited.