User Roles
Every user account in S-Filer Portal carries exactly one role. The role is a property of the account itself: it is decided when the account is created and it sets the outer limit of what that account may ever do, whatever else is configured around it.
A role is not the only thing that governs what a user can do, and it is easily confused with three other mechanisms:
- User group membership grants the transfer rights: permission to send, to receive, to use quick send, the applicable password policy, the allowed IP addresses, and so on. An account that belongs to no group cannot transfer files at all, whatever its role.
- Community and Share membership determines with whom a user exchanges files.
- Delegated administration (group administrator, community administrator) is an attribute of a membership, not a role. The same account can be a Standard user who happens to administer one group.
The effective permissions of a user are the intersection of all of these. A role never grants a permission that the group, the community or the Share withholds; it can only take one away.
See Also
Administration Concepts describes user groups, communities and delegated administration. Multi-Factor authentification (MFA) describes the MFA policies referenced below.
The roles at a glance
| Role | Identifier | Assignable | Purpose |
|---|---|---|---|
| Administrator | 1 | Yes | Administers the solution; cannot transfer files. |
| Standard | 0 | Yes | The ordinary interactive user. The default role. |
| Restricted | 5 | Yes | Like Standard, but cannot reorganize a community nor act on the files of others. |
| Guest | 4 | Yes | Outside participant invited into a Share. |
| Anonymous | 3 | No | Recipient of a quick send who has no account. |
| Automate | 2 | No | S-Filer Portal itself, acting on its own behalf. |
The Identifier column is the numeric value used by the configuration keys, the command line interface and the REST API. The four assignable roles are the only ones offered in the Role drop-down list of the administration console.
The four assignable roles are ordered, from the least to the most privileged: Guest, Restricted, Standard, Administrator. This order matters when a delegated administrator assigns a role. See Assigning a role.
Assignable roles
Administrator
An Administrator manages the solution: users, user groups, communities, system policies, extensions and audit trails. This is the role of the master administrator account created during the installation.
An Administrator does not transfer files. The account is refused by the transfer interfaces, it cannot be the owner of a Share, and it belongs to no user group and no community. Promoting an existing account to Administrator therefore empties it of everything that made it a transfer account.
Only an Administrator can grant the Administrator role, since it is the most privileged one.
Important
Changing the role of an account to Administrator removes it from all of its user groups and communities, clears its default community and its inbox alias, makes its inbox read-only and resets its quota. Putting the previous role back does not restore any of this: the memberships must be granted again by hand. The administration console asks for a confirmation before applying the change.
Warning
An Administrator cannot remove their own Administrator role. Another Administrator must do it. This prevents the last administrator of an installation from locking everyone out of the administration functions.
Standard
Standard is the ordinary role, and the default for a new account. A Standard user transfers files interactively in the communities and Shares they are a member of, may own and manage a Share, sees the files that other members sent to a community, and may be appointed administrator of a group or of a community.
Unless there is a specific reason to restrict an account, this is the role to use. It is also the default value of the Default user role parameter of an authentication domain.
Restricted
A Restricted user works like a Standard user, but cannot act on the content of a community. The restriction applies to actions, not to visibility: a Restricted user browses and downloads exactly what a Standard user does in the communities and Shares they belong to, including the files that other members deposited there.
Every restriction comes from a single rule. In a community, deleting, moving, renaming, changing a time to live and creating a folder are all authorized the same way. The server grants the operation to:
- an administrator of that community;
- the sender of the file concerned;
- any other member whose role is Standard or Guest, and who is also allowed to upload into that community and allowed to see the file concerned.
The role alone never satisfies the third clause. Its two other conditions are permissions that come from user groups, never from the role and never from a setting of the community itself. S-Filer Portal resolves them over the groups that the member and the community have in common — the groups the member belongs to that are also attached to that community:
- Being allowed to upload comes from the Upload Allowed permission of those groups.
- Being allowed to see the file comes from their Download Allowed permission, unless the community is configured to display files that cannot be downloaded, in which case every member of the community sees them.
When a member reaches a community through several such groups, the cfg.server.management.service.upload.usergroup.bitwise and cfg.server.management.service.download.usergroup.bitwise server parameters decide how the values of those groups are combined: OR, the default, means that one group granting the permission is enough, while AND requires every one of them to grant it.
See Also
Upload Allowed and Download Allowed are properties of a user group. See Change the properties of a user group in the Administration Guide, and the two combination parameters in the Server configuration reference.
Restricted is the only assignable role left out of the third clause, which gives:
| Operation, in a community | On a file they sent | On a file sent by someone else | On a folder |
|---|---|---|---|
| Delete | Yes | No | No |
| Move | Yes | No | No |
| Rename, or change the time to live | Yes | No | No |
| Create a folder | — | — | No |
A folder has no sender, which is why the first column never rescues a folder operation: a Restricted user can neither create, rename, move nor delete a folder in a community. This folder restriction is enforced by the server, so it holds for the web interface, the REST API and the command line alike.
In the web interface the effect is directly visible: in a community file list, a Restricted user has no Add folder, Move or Delete button at all, and the rename and time-to-live icons appear only on the files they sent themselves.
Warning
On one point the web interface is stricter than the table above: the Delete and Move buttons are hidden throughout the community file list, including on the files the Restricted user sent themselves. The server does authorize those two operations on their own files, so they remain reachable through the REST API and the S-Filer command line. Do not rely on the missing buttons as a boundary; the table above is the boundary.
Three things are not affected:
- The user's own inbox. There, a Restricted user creates folders, moves, renames and deletes like anyone else.
- Transferring files. A Restricted user uploads and downloads exactly like a Standard user.
- Delegated administration. A Restricted user may still own and manage a Share, and may still be a delegated administrator. One who is an administrator of a community regains every operation above in that community.
Use this role for participants who must deposit files into a shared space without being able to reorganize it or withdraw what is already there.
Important
The Restricted role hides nothing. It is not a confidentiality mechanism: a Restricted user sees the files of every other member of their communities. To keep members from seeing each other's files, place them in separate communities, the role will not do it.
Guest
Guest is the role of an outside participant who was invited into a Share. It is the least privileged assignable role.
An account with this role is created automatically when a user who does not yet exist is invited into a Share by email address. The account created this way receives the Guest role, is added to the group that manages the Share, has a read-only inbox and must change their password on first logon. A Guest cannot deposit files into their own inbox.
A Guest may transfer files in the communities and Shares they belong to. A Guest may also act on the content of a community — delete, move, rename, change a time to live, create a folder — but only under the third clause of the rule given for the Restricted role, whose two conditions both apply: through the groups they share with that community, the account must be allowed to upload into it and allowed to see the file concerned. Holding the Guest role is therefore never sufficient on its own; as for every other role, these permissions come from the user groups. A Guest may not own or manage a Share: the Create a share entry is absent from their navigation menu.
A Guest can be appointed administrator of a group, but being the least privileged role, such an administrator can only assign the Guest role to the accounts they create.
Internal roles
The two roles below cannot be assigned to an account. They are used internally by S-Filer Portal, and you will encounter them in the reports and in the audit journal.
Anonymous
Anonymous represents the recipient of a quick send who has no account in S-Filer Portal. When a user sends a file to a plain email address, S-Filer Portal creates an anonymous record for that recipient so the transfer can be authorized, notified and audited.
An anonymous recipient is never an administrator, is confined to the single transfer it was created for, and is refused by the web service and upload interfaces that are reserved for real accounts.
Automate
Automate is the identity S-Filer Portal uses when it acts on its own behalf rather than on behalf of a logged-in user: scheduled tasks, extensions, and the automatic creation of accounts. It is the most privileged identity of the solution, so that these internal operations are never blocked by the ordering of roles.
No human account ever has this role.
What each role can do
The table below compares only the capabilities that actually differ between roles.
| Administrator | Standard | Restricted | Guest | |
|---|---|---|---|---|
| Belong to user groups and communities | No | Yes | Yes | Yes |
| Transfer files interactively | No | Yes | Yes | Yes |
| Own or manage a Share | No | Yes | Yes | No |
| Delete or move a file sent by someone else | Yes | Yes | No | Yes |
| Rename a file sent by someone else, or change its time to live | Yes | Yes | No | Yes |
| Create, move, rename or delete a folder in a community | Yes | Yes | No | Yes |
| Administer users, groups, communities and policies | Yes | No | No | No |
| Be a delegated group or community administrator | No | Yes | Yes | Yes |
| Applicable system MFA policy | Administrators | Regular users | Regular users | Guest users |
| Counts towards the licensed number of users | No | Yes | Yes | No |
Warning
This table shows the limits imposed by the role alone. The role grants nothing by itself: the permissions come from the user groups. A Yes therefore means "not forbidden by the role", not "always allowed". In particular, the three rows about acting on the content of a community also require the Upload Allowed permission of a group shared with that community — a Standard user in a group without that permission can neither send files there nor act on what is already there.
Assigning a role
From the administration console
The role is chosen in the Role drop-down list of the user creation and user modification screens.
An Administrator sees the four assignable roles. A delegated administrator of a group sees only the roles that are no more privileged than their own, and the server refuses the change if a more privileged role is submitted anyway. A group administrator who is a Standard user can therefore assign Guest, Restricted or Standard, but not Administrator; a group administrator who is a Guest can only assign Guest.
On automatic account creation
When an account is created automatically, by adoption or by auto enrollment in an authentication domain, the role comes from the Default user role parameter of that domain, and not from the form that the user filled in. The corresponding configuration key is cfg.authentication.external.default.enrollment.role, whose value is the numeric identifier of the role:
| Value | Role |
|---|---|
| 0 | Standard (default) |
| 1 | Administrator |
| 4 | Guest |
| 5 | Restricted |
See Also
Auto Enrollment explains when this parameter applies, and Adding a new authentication method explains where to set it.
When a user is invited into a Share
A user who is invited into a Share by email address and who does not yet have an account is created with the Guest role. The person doing the inviting can change that role in the invitation window, within the limits of their own role.
From the command line and the API
The S-Filer Admin CLI takes the numeric identifier of the role through the -ur option of its user commands. Only the four assignable values above are meaningful; any other value falls back to 0 (Standard). The REST API exposes the same identifiers.
Changing the role of an existing account
The role of an existing account can be changed at any time, within the limits described above. Two consequences are worth knowing before doing it:
- Lowering the role of an account does not undo what the account already did. Files it sent, Shares it owns and memberships it holds remain as they are, but the account may no longer be able to manage them. Before making a Standard user a Guest, transfer the ownership of the Shares they own.
- Only Standard and Restricted accounts count towards the number of users allowed by the licence. Turning a Standard user into a Guest frees a licence seat; the opposite consumes one, and fails if the licensed maximum is already reached.