Security

• 1: Deployment
• 2: Credentials
• 3: User Accounts
• 4: Signing In
• 5: Sessions and Tokens
• 6: Signing Keys
• 7: Users and Groups
• 8: Application Permissions
• 9: Document Permissions

1 - Deployment

Shared Storage

For most large installations Stroom uses shared storage for its data store. This storage could be a CIFS, NFS or similar shared file system. It is recommended that access to this shared storage is protected so that only the application can access it. This could be achieved by placing the storage and application behind a firewall and by requiring appropriate authentication to the shared storage. It should be noted that NFS is unauthenticated so should be used with appropriate safeguards.

MySQL

Accounts

It is beyond the scope of this article to discuss this in detail but all MySQL accounts should be secured on initial install. Official guidance for doing this can be found here .

Communication

Communication between MySQL and the application should be secured. This can be achieved in one of the following ways:

• Placing MySQL and the application behind a firewall
• Securing communication through the use of iptables
• Making MySQL and the application communicate over SSL (see here for instructions)

The above options are not mutually exclusive and may be combined to better secure communication.

Application

Node to Node Communication

In a multi node Stroom deployment each node communicates with the master node. This can be configured securely in one of several ways:

• Direct communication to Tomcat on port 8080 - Secured by being behind a firewall or using iptables
• Direct communication to Tomcat on port 8443 - Secured using SSL and certificates
• Removal of Tomcat connectors other than AJP and configuration of Apache to communicate on port 443 using SSL and certificates

Application to Stroom Proxy Communication

The application can be configured to share some information with Stroom Proxy so that Stroom Proxy can decide whether or not to accept data for certain feeds based on the existence of the feed or its reject/accept status. The amount of information shared between the application and the proxy is minimal but could be used to discover what feeds are present within the system. Securing this communication is harder as both the application and the proxy will not typically reside behind the same firewall. Despite this communication can still be performed over SSL thus protecting this potential attack vector.

Admin Port

Stroom (v6 and above) and its associated family of stroom-* Dropwizard based services all expose an admin port (8081 in the case of stroom). This port serves up various health check and monitoring pages as well as a number of restful services for initiating admin tasks. There is currently no authentication on this admin port so it is assumed that access to this port will be tightly controlled using a firewall, iptables or similar.

Servlets

There are several servlets in Stroom that are accessible by certain URLs. Considerations should be made about what URLs are made available via Apache and who can access them. The servlets, path and function are described below:

HDFS, Kafka, HBase, Zookeeper

Stroom and stroom-stats can integrate with HDFS, Kafka, HBase and Zookeeper. It should be noted that communication with these external services is currently not secure. Until additional security measures (e.g. authentication) are put in place it is assumed that access to these services will be carefully controlled (using a firewall, iptables or similar) so that only stroom nodes can access the open ports.

Content

It may be possible for a user to write XSLT, Data Splitter or other content that may expose data that we do not wish to or to cause the application some harm. At present processing operations are not isolated processes and so it is easy to cripple processing performance with a badly written translation whether written accidentally or on purpose. To mitigate this risk it is recommended that users that are given permission to create XSLT, Data Splitter and Pipeline configurations are trusted to do so.

Visualisations can be completely customised with javascript. The javascript that is added is executed in a clients browser potentially opening up the possibility of XSS attacks, an attack on the application to access data that a user shouldn’t be able to access, an attack to destroy data or simply failure/incorrect operation of the user interface. To mitigate this risk all user defined javascript is executed within a separate browser IFrame. In addition all javascript should be examined before being added to a production system unless the author is trusted. This may necessitate the creation of a separate development and testing environment for user content.

2 - Credentials

Sometimes Stroom needs to connect to other systems:

• Git repositories
• Stroom AI connections
• In the future, all credentials for third-party systems will be managed by this user-interface.

The Credentials module is intended to centralise the management of these credentials within Stroom.

Accessing Credentials Manager

The Credentials Manager can be accessed via the Stroom Menu

Types of Credentials

Stroom supports different types of credentials. Different systems can use different types of credentials.

Username / Password

The username and password are passed to the server unchanged.

Access Token

This is a variation of username / password authentication. Stroom will pass the token in place of the password.

SSH Key

This is used when connecting to SSH servers. SSH authentication is not intuitive, thus the basics are explained here.

The user generates a key pair. The public part of the key pair is given to the SSH server, via the command line ssh-copy-id command or via an application-specific web user-interface. The private part is stored on the user’s machine and is secured via a pass-phrase. The pass-phrase ensures that if an attacker gains access to the user’s file they cannot access the private key.

Thus Stroom needs to know the private key and the pass-phrase.

There is one more key pair involved. It is important that the client is confident that they are connecting to the correct SSH server. Otherwise, an attacker might trick the user into connecting to the wrong server. This is secured by the server’s key pair. The server has a private key and allows the client to download the server’s public key.

Stroom can optionally check the server’s key, if the server’s public key is provided. If no key is provided then Stroom will accept any server. This can be useful when getting things working but is not recommended for production use. To enable this setting, check the checkbox “Verify Hosts” and add the entry from your ~/.ssh/known_hosts file.

Key Store

Create a key store in JKS or PXCS12 format.

Key Store Type

Stroom supports these two keystore formats:

• JKS - Original Java keystore format.

• PKCS12 - Standardised format, developed by RSA, which stores cryptography objects in a single file.

Key Store Pass Phrase

The keystore should be protected by a pass-phrase. Stroom needs this pass-phrase to read the keystore.

Upload Key Store File

Select the keystore and upload it to enter it into Stroom.

3 - User Accounts

Accounts vs Stroom Users

See Accounts vs Users for details on the difference between a Stroom User Account and a Stroom User.

Creating User Accounts

User accounts can only be created by a user that holds the Manage Users or Administrator Application permission Application permission This is a permission that is not specific to a single document. It applies to all documents or is not related to documents in any way.Click to see more details....

Create a new user account by selecting

from the main menu.

As a minimum a user account must have a unique identifier that will be used to identify them in Stroom.

If the user’s email address is added then Stroom will be able to email the user to reset their password. This functionality is configured using the properties starting with this prefix stroom.security.identity.email..

Account States

An account has three states and they are independent of one another. An account can be locked and disabled at the same time, or inactive and disabled, and so on. Each is shown as its own column in the Manage Accounts screen because each answers a different question.

The quickest way to keep them apart is to ask what creates each state, because that also tells you what can clear it.

An account in any of these three states cannot sign in.

Enabled and Disabled

This is the administrator’s control over whether an account may be used at all. It is the only one of the three states that an administrator sets directly.

Disabling an account prevents any further sign in, immediately. A disabled account cannot be recovered by the user under any circumstances. Waiting will not release it and a password reset will not release it. This makes disabling the right action whenever someone must be prevented from signing in, whether temporarily, for example while they are on extended leave, or permanently.

Locked

An account is locked automatically after a number of consecutive failed sign in attempts, controlled by stroom.security.identity.failedLoginLockThreshold. It is a defence against password guessing and nothing more.

An administrator cannot lock an account. To prevent someone using Stroom, disable their account instead.

While an account is locked, further sign in attempts are refused without the password being checked at all, and those attempts are not counted against the account. Continued guessing therefore reveals nothing and does not extend the lock.

There are three ways an account becomes usable again.

• Waiting. The lock lapses on its own after stroom.security.identity.failedLoginLockDuration, which is thirty minutes by default. Nothing needs to happen when it lapses. The next sign in with the correct password simply succeeds. The message shown to the user says roughly how long remains, so in a default configuration a locked user does not need to contact anybody.

• Resetting their password. If stroom.security.identity.allowLockedAccountPasswordReset is enabled then the user can request a password reset email and set a new password, which unlocks the account at the same time. This is described in Signing In.

• An administrator unlocking it. A user holding the Manage Users or Administrator Application permission Application permission This is a permission that is not specific to a single document. It applies to all documents or is not related to documents in any way.Click to see more details... can use the Unlock action in the Manage Accounts screen.

Setting failedLoginLockDuration to zero means locks never lapse, in which case one of the other two routes is the only way back. The duration is applied when a sign in is attempted rather than when the lock is created, so changing this property also changes locks that are already in force.

Inactive

The Account Maintenance job marks an account as inactive when it has not been used for some time. This happens in one of two cases:

• A brand new account that has never been signed into was created longer ago than stroom.security.identity.passwordPolicy.neverUsedAccountDeactivationThreshold.
• An account has not been signed into for longer than stroom.security.identity.passwordPolicy.unusedAccountDeactivationThreshold.

Accounts flagged as never expires are exempt, as are accounts that have been reactivated recently, so that reactivating an account does not simply see it deactivated again on the job’s next run.

As with locking, an administrator cannot mark an account as inactive. Disabling is the control for preventing access.

How an inactive account becomes usable again depends on stroom.security.identity.reactivateInactiveAccountsOnLogin.

• When it is disabled, which is the default, an administrator must use the Reactivate action in the Manage Accounts screen.
• When it is enabled, presenting a valid credential reactivates the account and signs the user in, in one step. This applies equally to a correct password and to a valid certificate.

A disabled account is never reactivated automatically. Reactivation only happens once a credential has been accepted, and a disabled account never gets that far.

Administrator Actions

The Manage Accounts screen offers the following actions to a user holding the Manage Users or Administrator Application permission Application permission This is a permission that is not specific to a single document. It applies to all documents or is not related to documents in any way.Click to see more details....

There is deliberately no action to lock an account or to mark one as inactive. Those two states are applied by Stroom in response to something it has observed, and an administrator wanting to prevent access should disable the account.

Requiring a password change at the next sign in can safely be combined with setting a password in the same save. The requirement is kept rather than being cleared by the password change.

4 - Signing In

This page describes what a user experiences when signing in to Stroom using its internal Identity Provider (IDP) Identity Provider (IDP) An Identity Provider is a system or service that can authenticate a user and assert their identity. Identity providers can support single sign on (SSO), which allows the user to sign in once to the Identity Provider so they are then authenticated to all systems using that IDP.Click to see more details....

Signing in with a Password

The outcome of a sign in attempt depends on the state of the account as well as the password.

A wrong password and a user id that does not exist produce exactly the same answer, so the sign in screen cannot be used to discover which accounts exist.

For a disabled or locked account the password is not checked at all. Neither state can be talked out of with a correct password, so there is nothing to be gained by checking one, and refusing without checking means the sign in screen cannot be used to test whether a password is correct.

Failed attempts against a disabled or locked account are not counted, because the account is already refused.

Being Asked to Change Your Password

A user may be signed in successfully and then be required to set a new password before they can do anything else. This happens in three cases:

• It is their first ever sign in and stroom.security.identity.passwordPolicy.forcePasswordChangeOnFirstLogin is enabled, which it is by default.
• An administrator has set a new password for them and asked that it be changed.
• Their password is older than stroom.security.identity.passwordPolicy.mandatoryPasswordChangeDuration.

The new password must satisfy the password policy, which is applied by the server on every route that sets a password. The previous password cannot be reused.

Getting Locked Out

After a number of consecutive wrong passwords, controlled by stroom.security.identity.failedLoginLockThreshold, the account is locked.

The message shown to a locked user depends on how the system is configured, and always gives them the cheapest way back in.

An administrator is only named where an administrator really is the only way back. In a default configuration a locked user is told to wait, which avoids a support request for something that resolves itself.

See User Accounts for the three ways an account becomes usable again.

Resetting a Forgotten Password

If the user has an email address recorded against their account, and stroom.security.identity.passwordPolicy.allowPasswordResets is enabled, they can use Forgot password? on the sign in screen to be emailed a link for setting a new password.

The response shown on screen is the same whether or not the address belongs to an account, so this screen cannot be used to discover which email addresses have accounts.

The link is valid for stroom.security.identity.token.emailResetTokenExpiration, ten minutes by default, and can be used only once. Requesting another link invalidates any earlier one. Repeated requests are rate limited by stroom.security.identity.passwordResetRequestCooldown.

Completing a reset ends all of that user’s existing sessions everywhere in the cluster. They then sign in with their new password.

When a Reset Cannot be Completed

Some accounts cannot be recovered this way. Rather than sending a link that would not work, Stroom emails the account holder to say that the reset cannot currently be completed and that they should contact an administrator if it continues.

This happens when:

• The account is disabled. Only an administrator can enable it again.
• The account is locked and stroom.security.identity.allowLockedAccountPasswordReset is not enabled. Note that a lock which has already lapsed does not prevent a reset.
• The account is inactive and stroom.security.identity.reactivateInactiveAccountsOnLogin is not enabled. Without it, setting a new password would not be enough to sign in, so an administrator has to reactivate the account first.

The email is deliberately the same in all three cases and does not say which one applies. It goes to the address held against the account, so it tells the account holder something is wrong without telling whoever made the request anything at all.

No email of any kind is sent when there is nobody to send it to, that is when the address matches no account, the account has no email address recorded, password resets are turned off, or an email was already sent within the cool-down period.

Signing in with a Certificate

If stroom.security.identity.allowCertificateAuthentication is enabled, a user presenting a valid certificate can be signed in without typing a password. The user id is taken from the certificate’s common name using stroom.security.identity.certificateCnPattern and stroom.security.identity.certificateCnCaptureGroupIndex.

A valid certificate is treated in exactly the same way as a correct password. The same account states apply in the same order, so a disabled or locked account is still refused, and an inactive account is either reactivated or refused depending on stroom.security.identity.reactivateInactiveAccountsOnLogin.

5 - Sessions and Tokens

Signing in to Stroom creates a session, and Stroom issues tokens that are used to prove who a user is, both to Stroom itself and between the nodes of a cluster. This page describes how sessions and tokens are ended, both by users for themselves and by administrators.

Ending Your Own Sessions

Any user can end their own sessions other than the one they are currently using, by selecting

from the main menu.

This is useful after signing in from a machine that is no longer under their control. It applies across every browser and device, and across every node in the cluster.

Completing a password reset also ends all of that user’s sessions, including the one being used at the time. See Signing In.

The User Access Screen

A user holding the Manage Users or Administrator Application permission Application permission This is a permission that is not specific to a single document. It applies to all documents or is not related to documents in any way.Click to see more details... can see and end the access held by other users by selecting

from the main menu.

The screen lists users along with how many sessions and tokens each currently holds, and shows the sessions held for the selected user across every node in the cluster.

Two actions are available.

• End this user’s sessions and revoke their tokens does exactly that, across the whole cluster rather than just the node serving the request. It does not withdraw their access: the account is untouched and they can sign in again.

• Open this user opens the selected user, where they can be disabled. This is offered alongside revocation because the two are easily confused and do quite different things, as described below.

Revoking, Disabling, and the Difference between Them

Three actions are easy to confuse, and each does something different. To stop someone using Stroom completely and immediately, you need the last two together.

Ending sessions and revoking tokens does both of those things and no more. It deliberately leaves the account alone, so the password still works and the user can sign in again. Every token revoked this way is dead permanently, but their access as a whole is not withdrawn. It forces re-authentication rather than shutting anybody out, which makes it the right action when you want to be certain that whoever is currently signed in has to prove who they are again.

Disabling the Stroom User User Refers to a Stroom User that is linked to either an Account in Stroom’s internal Identity Provider or a user account in an external Identity Provider. A Stroom User is primarily concerned with authorisation (i.e. application/document permissions and group memberships) rather than authentication, though disabling one also refuses that person at authentication and ends any access they currently hold.Click to see more details... does everything the above does, and additionally refuses them at authentication, whether they are signing in interactively or presenting a token. This is the action to take when someone must be stopped, and is what the Open this user button on the User Access screen is for.

Disabling the account, which only applies when Stroom is its own Identity Provider (IDP) Identity Provider (IDP) An Identity Provider is a system or service that can authenticate a user and assert their identity. Identity providers can support single sign on (SSO), which allows the user to sign in once to the Identity Provider so they are then authenticated to all systems using that IDP.Click to see more details..., stops them authenticating at all. It does not disturb a session that is already running. See User Accounts.

Token Lifetimes

These are the defaults, and are configurable under stroom.security.identity.token..

Refresh tokens can be used only once, and each use issues a replacement. If a refresh token is presented a second time, which suggests it has been copied, Stroom withdraws that token and every token descended from it.

6 - Signing Keys

When Stroom acts as its own Identity Provider (IDP) Identity Provider (IDP) An Identity Provider is a system or service that can authenticate a user and assert their identity. Identity providers can support single sign on (SSO), which allows the user to sign in once to the Identity Provider so they are then authenticated to all systems using that IDP.Click to see more details... it signs the tokens it issues with a key that it creates and replaces by itself. Nodes and Stroom-Proxy check that signature to satisfy themselves that a token really came from Stroom.

This screen exists so that a key believed to have been exposed can be withdrawn. It is not needed for day to day running, because keys are replaced automatically.

Reach the screen by selecting

from the main menu.

What the Screen Shows

Each key is listed with its status and the date it was issued, and nothing else. Nothing that identifies a key or describes its contents is shown, because the stored key includes the private half that produces signatures.

The active key has no end date. Keys here do not expire on a schedule. Rotation replaces the active key when it is old enough, and only at that point does the key it replaced gain a date on which it stops being trusted.

Automatic Rotation

Stroom replaces the active signing key every stroom.security.identity.token.jwkRotationInterval, which is thirty days by default.

Rotation is invisible to users. The key being replaced continues to be trusted for long enough that every token already signed with it expires naturally, so nobody is signed out and nothing needs to be restarted.

Revoking a Key

Revoking withdraws a key immediately. Any token signed with it stops being accepted, and a replacement signing key is created at the same moment so that Stroom can carry on issuing tokens.

There are two actions.

• Revoke withdraws the selected key.
• Revoke all withdraws every key that is still trusted, for when a key is believed to have been exposed but it is not known which.

Both actions ask for confirmation first, and the confirmation says what that particular key will cost, because the effect differs enormously between them. Revoking a retired key usually affects a handful of people, while revoking the active key affects everyone.

What to Expect after Revoking the Active Key

Everybody using Stroom is signed out and must authenticate again. For people at a browser this is quick, and they will be signed back in as soon as they do so.

Nodes and Stroom-Proxy hold their own tokens signed with the same key, and they replace those tokens as they expire rather than immediately. Parts of the cluster may therefore be unable to talk to one another for up to ten minutes. This resolves itself and needs no intervention, but it is worth expecting rather than being surprised by, and it is a good reason to reserve this action for a suspected compromise.

Revoking a retired or expired key has no such effect, as nothing is signing with it.

7 - Users and Groups

Accounts vs Stroom Users

See Accounts vs Users for details on the difference between a Stroom User Account and a Stroom User.

User

A Stroom User represents a human user and is linked to either a User Account in Stroom or to a user account in an external Identity Provider (IDP) Identity Provider (IDP) An Identity Provider is a system or service that can authenticate a user and assert their identity. Identity providers can support single sign on (SSO), which allows the user to sign in once to the Identity Provider so they are then authenticated to all systems using that IDP.Click to see more details.... It can also represent a non-human processing user, e.g. where a Stroom User is created and has an API Key API Key API Keys are a form of authentication token that are created within Stroom for use by Stroom-Proxy instances or other clients that want to use Stroom’s API. It is an encrypted string that contains details of the user and the expiration date of the token. Possession of a valid API Key for a user account means that you can do anything that the user can do in the user interface via the API.Click to see more details... created for it to allow a client system to use Stroom’s API API Application Programming Interface. An interface that one system can present so other systems can use it to communicate. Stroom has a number of APIs, e.g. its many REST APIs and its /datafeed interface for data receipt.Click to see more details....

All audited activity in Stroom will be attributed to a Stroom User and their unique identifier will be included in the audit events.

A User can have the following:

• Membership of one or more Groups.
• One or more Application Permissions Application permission This is a permission that is not specific to a single document. It applies to all documents or is not related to documents in any way.Click to see more details... granted to it.
• One or more Document Permissions Document permission Document permissions control the access that users and/or groups have to a Document.Click to see more details... granted to it.

Enabling and Disabling a User

A User can be enabled or disabled using the Enabled tick box on the user, reached by selecting

from the main menu and opening the user. This requires the Manage Users or Administrator Application permission Application permission This is a permission that is not specific to a single document. It applies to all documents or is not related to documents in any way.Click to see more details....

Disabling a User is the strongest single action available against a person. It takes effect at once and does three things:

• Every session they hold is ended, across every node in the cluster.
• Every token issued to them is revoked.
• They are refused at authentication from then on, whether signing in interactively or presenting a token.

This is distinct from disabling their Account, which only prevents them signing in and leaves any session already running untouched. An Account exists only where Stroom is its own Identity Provider (IDP) Identity Provider (IDP) An Identity Provider is a system or service that can authenticate a user and assert their identity. Identity providers can support single sign on (SSO), which allows the user to sign in once to the Identity Provider so they are then authenticated to all systems using that IDP.Click to see more details..., whereas every person has a Stroom User whichever Identity Provider (IDP) Identity Provider (IDP) An Identity Provider is a system or service that can authenticate a user and assert their identity. Identity providers can support single sign on (SSO), which allows the user to sign in once to the Identity Provider so they are then authenticated to all systems using that IDP.Click to see more details... is in use, so disabling the User is the action that works in all deployments.

See Sessions and Tokens for how this compares with simply ending someone’s sessions, and User Accounts for the Account states.

Group

A Group represents a collection of Stroom Users and/or other Groups. A Group can be used to ease the management of application and document permissions by granting permissions to one Group then adding users to that Group. For example if all the users in a team require the same application and document permissions, then a Group can be created for them and the permissions assigned to the Group. When a user joins or leaves the team it is simply a case of editing the membership of the Group.

A Group can have the following:

• One or more members (Users and/or other Groups).
• Membership of one or more other Groups.
• One or more Application Permissions Application permission This is a permission that is not specific to a single document. It applies to all documents or is not related to documents in any way.Click to see more details... granted to it.
• One or more Document Permissions Document permission Document permissions control the access that users and/or groups have to a Document.Click to see more details... granted to it.

8 - Application Permissions

An Application Permission is a permission to perform an action that is not associated with a single Document Document Typically refers to an item that can be created in the Explorer Tree, e.g. a Feed, a Pipeline, a Dashboard, etc. May also be known as an Entity.Click to see more details... or is unrelated to Documents. Application Permissions can be granted to Users or Groups.

In order to grant Application Permissions to yourself or to other Users/Groups you must have the Manage Users or Administrator Application Permissions. If you have one of these permissions then you can access the Application Permissions screen from the main menu:

Application Permission Types

The following is the list of different application permissions that can be granted to users/groups.

9 - Document Permissions

Document Permissions are permissions that are granted to Users or Groups for a specific Document Document Typically refers to an item that can be created in the Explorer Tree, e.g. a Feed, a Pipeline, a Dashboard, etc. May also be known as an Entity.Click to see more details.... They control what documents a user/group can see and what they can do to those documents. They allow very fine grained control over what a user/group can see or do in Stroom.

For example, User jbloggs may be granted Use permission on the Index named Alert Index in order for him to be able to query that index in a dashboard, but not be able to see it in the explorer tree or change it in any way.

By default a new user with no Application Permissions, Document Permissions or Group memberships cannot view/use/modify any documents. They do not even have permission to create any documents. When logging into Stroom, they will simply see an empty explorer tree.

A user can gain varying levels of access to documents in a number of ways:

• Being added to a Group that has direct or inherited permissions on one or more existing documents.
• Being added to a Group that has direct or inherited permissions to create one or more document types.
• Being directly granted permissions one or more existing documents.
• Being directly granted the permission to create one or more document types.
• Being granted the Administrator Application Permission which gives them access to ALL documents.

In order to modify the permissions on a document, you must either hold Owner permission on the document or have the Administrator Application Permission. The Document Permissions screen for a document/folder can be accessed by right clicking on it in the explorer tree and selecting:

Permission Types

The following is the list of different permissions that can be granted to users/groups on a document.

The following is the list of different permissions that can be granted to users/groups on a folder .

Implied Permissions

Note that each permission in the two tables above also includes all the permissions below it in the table, e.g. a user with Edit permission on a document will also have the implied permissions View and Use. There is no need to grant these lower permissions to the user, though doing so will have no impact as Stroom will use the highest value permission when checking permissions.

Inherited Permissions

If a User jbloggs is a member of Group Team A and that group is a member of group Division 123, then jbloggs will inherit all permissions from both Team A and Division 123. A User/Group will inherit all permissions of the groups that they are a member of and also from any ancestor groups of those groups.

Owner Permission

A document can have multiple owners. An owner can be a user or a group. When a document is created by a user they are automatically made an owner of it. Any user with the Administrator role has implied ownership of ALL documents.

Having Owner permission on a document means the user can grant permissions on that document to other users, or revoke permissions from other users.

Use Permission

This permission allows users to access a document but not actually see it in the explorer tree or open the document in Stroom. They can however make use of the document, e.g. selecting and querying an Index in a Dashboard .

The Use permission is not relevant to all document types.

Permissions on Folders

Folders in the explorer tree work mostly in the same way as documents when it comes to permissions. There are a couple of exceptions to this.

Permission on Folder Contents

The permissions on a folder apply only to the folder itself and has no bearing on what you can/can’t do to its child items. The permissions on each child item in the folder control what you can/can’t do to those items.

For example, if you only have View permission on a folder, but have Delete on a document in that folder, then you are able to delete that document and thus change the contents of the folder.

Similarly, if you have View permission on a folder but have no permission on any of its child items, then you will just see an empty folder.

Ancestor Folder Visibility

A folder will be visible to a user in the explorer tree if the user has View permission on it OR if the user has View permission on any single document/folder that is a descendant of it.

For example, if a user has View permission on a Dictionary Dictionary_XYZ with path

System / Folder_A / Folder_B / Dictionary_XYZ

but no permissions on Folder A or Folder B, they will be able to see both Folders in the explorer tree in addition to the Dictionary. They will however not be able to open those Folders as they do not have the permission.

Therefore, when granting permissions on a document/folder to a user/group, you are also implicitly granting visibility (but not View permission) on all ancestor folders.

Create Permissions

Folders can have one or more Create Permissions granted on them to users/groups.

There is a Create Permission for each document type, e.g. Index, Dictionary, Feed, etc. A Create Permission is the ability to create a new document of that type in that folder.

For example, user jbloggs is an analyst and is granted Create Dashboard and Create Query permissions on the Folder named Joe's Folder. This means Joe can only create Dashboard or Query documents in that folder and nothing else.

Applying Changes to Descendants

When making changes to the permissions on a Folder you have the option of making the changes to just that folder or to all descendants of that folder. Selecting to apply to all descendants will make all permission changes apply to every descendant, i.e. including any sub-folders and their contents or own sub-folders.

Moving and Copying Documents

When you move or copy a document/folder you have the choice of how the destination document/folder’s permissions should be derived. The move/copy dialog offers the following choices:

• None - Removes all current permissions. Ignores permissions of the destination folder. You will be the owner of the moved document if not already.
• Source - Keep the current permissions and ownership as they are.
• Destination - Removes all current permissions. Adds the permissions of the destination folder. You will be the owner of the moved document if not already.
• Combined - Keep the current permissions and add the permissions of the destination folder. You will be the owner of the moved document if not already.