You are here: Globodox Security >Security Basics

Users

Globodox lets you create as many users as you want*. For each user you must provide at least a user name, an email id, a group and a role. The user name is used for logging in to Globodox and is case-insensitive. E.g. If your user name is JOHN you can login in as john, John or JOHN. Ideally a password must be provided for each user though it is not compulsory to do so (i.e. you can leave the password blank).
 
Providing an email id is mandatory because the email id is required for certain current (and future) Globodox features to work correctly. This includes features such as workflow and messaging. If you do not intend to use these features, you can provide a dummy email id.
 
Every user must be a member of at least one group. By default any new user you create is made a member of the Users group. If you make a user a member of more than one group then you must mark one of these groups as the user’s primary group.

 

Every user must also be assigned to at least one role. By default any new user you create is automatically assigned  the Writer (Owned & Shared Items) role.
 
*Though Globodox lets you create as many users as you want, it controls how many users can be simultaneously logged in at any given time. The maximum number of users that can be simultaneously logged in at any given time is based on the number of licenses purchased by the user.

 

Roles

Roles let you group privileges and assign them to multiple users. This reusability makes managing security simpler. Roles also help in scenarios where an employee has been transferred or has left the organization. Simply assigning a new employee to the earlier employee’s role ensures that much of the information accessible to the earlier employee immediately becomes accessible to the new employee.

 
A user can be assigned to multiple roles but must be assigned to at least one role.

 

To decide if a user is allowed to perform a particular action, Globodox checks if a privilege corresponding to that action has been granted to the user. However Privileges are not directly granted to users. Privileges are granted to Roles and users assigned to those Roles inherit the privileges from the Roles.

 
There are two ways to plan what kind of roles you will create in Globodox...

 

Action based Roles

You can use roles like blocks of privileges which you combine to arrive at the final set of privileges for a user.  Certain system roles shipped by default in Globodox take this approach. These roles are...

 

Reader (All Items)

Users in this role can view all items (i.e. Documents & Stacks) in the database unless any of those items have been specifically restricted to them. No other privileges allowing modification or deletion of items are granted in this role.

 

Reader (Owned & Shared Items)

Users in this role can view all items (i.e. Documents & Stacks) in the database, that they own* as well as any items that have been shared to them. No other privileges allowing modification or deletion of items are granted in this role.
 
Writer (All Items)
Users in this role can add/modify/delete all items (i.e. Documents & Stacks) in the database unless any of those items have been specifically restricted to them.
 
Writer (Owned & Shared Items)
User in this role can view, add, modify or delete items which are owned by them and items that have been assigned to them.
 
Note:
A user becomes owner of an item (i.e. Document or Stack), when the user creates that item or when an item is assigned to the user.

 

Designation based Roles

You can use roles as equivalents to designations/job profiles in your organization. So you could have a Sales Manager role and Sales Executive role with each role having appropriate privileges. For e.g. users in the Sales Executive role can be allowed to view documents but not modify them whereas users in the Sales Manager role can be allowed to view and modify documents.
 
Often an employee may perform multiple roles in a company. For example the sales manager might also be looking after marketing. Since Globodox allows multiple roles to be assigned to a user, such situations can be easily handled.

 

 

Privileges

To decide if a user is allowed to perform a particular action, Globodox combines the privileges of the various roles assigned to the user. Globodox then checks if a privilege corresponding to that action has been granted to the user.

 

Core Privileges

Each type of item in the database (e.g. documents, folders etc...) has it's own list of privileges (known as the Core Privileges of that item) which you can grant to a role (for example documents have privileges such as View, Modify, Delete).
 
Core Privileges are available for Documents, Folders, Annotations, Stamps, Saved Queries, Fields and the DB List. Core Privileges are also available for all the Stack Types that you have created in all your DBs.

Privilege Access Level

When you grant a privilege for a user you must first decide the access level at which you are granting the privilege. For example if you are granting the Modify privilege to a Role, you need to decide if you want the users in that role to be able to modify all the documents in the DB or only modify documents that have been shared to them.
 
The following privilege access levels are available for any core privilege...

 

A role can of course have different levels of access for each privilege. For example a role can be allowed to view all documents but allowed to modify only group owned document and allowed to delete only owned documents.

 

Other Privileges

The privileges listed in the Other Privileges list also control what actions a user is allowed to perform. However these privileges do not have access levels. These privileges control actions such adding a tag, disconnecting a user, viewing a event log etc..

 

Groups

Each user must be a member of at least one group. Users can be members of multiple groups but only one group can be set as the user’s Primary Group.  

 

When any user adds an item (i.e. Document or Stack), the user becomes the owner of that item. At the same time, the user's primary group becomes the owning group of that item. Because of this any users belonging to the same group can automatically get access to this item if their access level for any privilege is set to Group Owned or higher.
 
You can think of the Primary Group as the department to which the user belongs in the organization. Apart from the primary groups users can belong to other groups as well. These groups can be thought of as other departments or temporary teams that the user is also a part of.
 
Users working together on a project can be made members of a group. Since documents can be shared with individual users or entire groups, this makes it easy to quickly share documents with the entire project team. Yet, to maintain security, access to documents is based on hierarchical security groups.

 

Notes:

 

Sharing

Globodox allows you to share individual documents, stacks, folders etc.. to specific users or groups. Sharing is required in cases where the normal Role, User and Group mechanism would not do the job. For e.g. you could be using the Role, User and Group mechanism to ensure that each user can only view documents that they own. Now if you wanted a specific document to be viewable by all of these users, you could achieve this by sharing the document with all the users.
 
You can share items with a user/s or groups. While sharing you can also grant different privileges to each user or group.
 
Sharing is also required if you need to decide on a per document level which users can work with a document and what privileges they will have.

 

Security Label

Using Security Labels is very similar to sharing. If you find yourself repeatedly sharing to the same set of users or groups you can use security labels instead. Security labels let you save the list of users and groups that you frequently share items with. Along with each user and group you can also save the privileges granted to them. When you save security label, you must provide a name for it.
 
Now every time you wanted to share an item to the same set of users or groups you can simply apply the saved security label to that item. This eliminates the need to select users/groups and grant permissions every time you share an item. In other words security labels let you reuse your share settings.
 
Security Labels are preferable to sharing. Technically they offer a higher performance. Also any changes you make to a security label are immediately propagated to all the items which use that security label. For example if you add a new user to a security label and grant the View privilege to the user, all existing items to which the security label was applied would become immediately visible to the new user.

If you wanted to stop sharing an item you can simply remove the security label from that item. If you modify the security label to remove some users/groups from it, then those users and groups will immediately lose access to all items with that security applied (unless these users/groups).
 
Only one security label can be applied to any item.

 

Security Labels can only be deactivated. They cannot be deleted.

 

Security Label Special Groups

Normally Security Labels contain a list of users and/or groups as well as the privileges granted to each user or group. Security labels can also contain Special Groups. Currently Owner, Owning Group and Others are the three special groups available. Special Groups are context sensitive groups and their membership is decided when the security label is evaluated at run time to figure out if the user has access to an item.
 

Owner Special Group
You can add the Owner special group to a security label and grant it the delete privilege. Now when the security label is applied, whichever user is set as the owner of the document/stack/folder will be allowed to delete the document/stack/folder, even if that user's role has not been granted the Delete Document/Stack/Folder.
 
Owning Group Special Group
You can add the Owning Group special group to a security label and grant it the delete privilege. Now when the security label is applied to a document/stack/folder, any user belonging to that document's/stack/folder owning group will be allowed to delete the document/stack/folder, even if that user's role has not been granted the Delete Document/Stack/Folder privilege.
 
Others Special Group
Sometimes you might want to grant privileges to an item to all the users in the system. In this case you can add the Others special group to the security label and grant it the required privileges.
 
Suppose you add the Others special group to a security label and grant it the View privilege. Now when the security label is applied to a document/stack/folder, any user of the system will be allowed to modify the document/stack/folder, even if that user's role has not been granted the Modify Document/Stack/Folder privilege.

Restrict

The Restrict feature lets you block a user's access to any item. You can restrict an item from any number of users. The owner of an item or any user who has Restrict privileges on that item, can restrict that item from other users.
 
You can only restrict users. You cannot restrict entire groups.

 
Restrict takes precedence over a Share. For example, a user has been granted privileges over a document via a security label. The same user has also been restricted. In this case the user will be denied access to the document.
 
Restrict also takes precedence over Role Privileges granted at the Full (Restrictable), Group Owned (Restrictable), Owned (Restrictable) and Shared access levels. Restrict does not take precedence over Role Privileges granted at the Full, Group Owned and Owned access levels.
 
For example, if the user's role has been granted the View privilege for Documents at the Full access level, then the user will be allowed to see any document, even if it has been restricted. On the other hand, if the user's role has been granted the View privilege for Documents at the Full (Restrictable) access level, then the user can view all documents except for the documents that have been restricted.

 

Restrict specific user actions

Globodox not only lets you restrict a Role from performing one or more actions on all documents, but also to restrict the user from performing those actions on specific documents.

 

For example, you can decide that a user with the Role set as Assistant cannot delete any document. But you can also let the user view and modify a specific document, but not delete it. So even if the user has been assigned a Role that has the privilege to delete all the documents, they can still be restricted from deleting a particular document if the need be.

 

Owner

A user becomes the owner of an item (for e.g. Document or Stacks) when the user creates/adds that item. The user also becomes the owner of an item when that item is assigned to the user by another user.

 

Owning Group

When a user becomes the owner of an item (for e.g. Document or Stack) the user's primary group becomes the owning group of that item. Because of this any users belonging to the same group as an item's owning group, can automatically get access to the item if their access level for any privilege of that item is set to Group Owned or higher.
 
You can use this mechanism in situations where all users of a department need some level of access to all documents owned by other users of that department.

 

 

Password Policies

Maximum password age
Use this policy to set the maximum number of days after which a user's password will expire and will have to be changed. If you want the password to never expire, set this value to zero.

Minimum password length
Use this policy to set the minimum number of characters that a password must contain. Globodox will not allow any user to set a password that is shorter in length than this value. If you do not want to set a minimum value then set this value to zero.

Maximum Logon attempts
Use this policy to set the maximum number of consecutive failed logon attempts before Globodox disables the user account. A disabled account can be enabled by the superadmin user. If you do not want to set a maximum logon attempts limit then set this value to zero.

Security Policies

Inactivity Timeout

The Inactivity Logout policy allows you to set a time limit for application inactivity. So, if the logged in user remains inactive for the specified time period then user is automatically logout from the system. This can be used to terminate the connection to Globodox which appears to be logged in, in case of improper shut down of user machine.

Never logout
Check this option if you want do not want inactive users to be automatically logged out of Globodox

Application Inactivity time out
Enter the number of minutes to set the time limit for application inactivity.

 

Allow Remember Password and Auto-Login
Use this policy to allow users to use the Remember password option on the login screen. This policy also allows users to choose to automatically login to Globodox on Windows startup.

 

Redact Permission

When annotating a scanned document (or any other image file) you can redact (hide) parts of the document by drawing opaque blocks over those parts. In this case, you may still want to allow certain users to be able to remove the opaque blocks and view the hidden content underneath. Globodox lets you do this, by simply selecting the list of users who are allowed to view the hidden parts.

 

 

 

 

---

Page URL: https://www.globodox.com/support/help/index.htm?security_basics.htm