This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Security

All aspects of securing Stroom and the content within it. Includes application security, user and group accounts and the permissions model.

1 - Deployment

There are many aspects of security that should be considered when installing and running Stroom.

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 it’s 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:

Servlet Path Function Risk
DataFeed /datafeed or /datafeed/* Used to receive data Possible denial of service attack by posting too much data/noise
RemoteFeedService /remoting/remotefeedservice.rpc Used by proxy to ask application about feed status (described in previous section) Possible to systematically discover which feeds are available. Communication with this service should be secured over SSL discussed above
DynamicCSSServlet /stroom/dynamic.css Serves dynamic CSS based on theme configuration Low risk as no important data is made available by this servlet
DispatchService /stroom/dispatch.rpc Service for UI and server communication All back-end services accessed by this umbrella service are secured appropriately by the application
ImportFileServlet /stroom/importfile.rpc Used during configuration upload Users must be authenticated and have appropriate permissions to import configuration
ScriptServlet /stroom/script Serves user defined visualisation scripts to the UI The visualisation script is considered to be part of the application just as the CSS so is not secured
ClusterCallService /clustercall.rpc Used for node to node communication as discussed above Communication must be secured as discussed above
ExportConfig /export/* Servlet used to export configuration data Servlet access must be restricted with Apache to prevent configuration data being made available to unauthenticated users
Status /status Shows the application status including volume usage Needs to be secured so that only appropriate users can see the application status
Echo /echo Block GZIP data posted to the echo servlet is sent back uncompressed. This is a utility servlet for decompression of external data URL should be secured or not made available
Debug /debug Servlet for echoing HTTP header arguments including certificate details Should be secured in production environments
SessionList /sessionList Lists the logged in users Needs to be secured so that only appropriate users can see who is logged in
SessionResourceStore /resourcestore/* Used to create, download and delete temporary files liked to a users session such as data for export This is secured by using the users session and requiring authentication

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 careful 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 - User Accounts

User accounts for authentication when using Stroom’s internal identity provider.

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 .

Create a new user account by selecting

Security
Manage Accounts

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 Flags

User accounts have a number of flags that can be set by an administrator or automatically by Stroom.

  • Enabled - Enables/disables the account. A disabled account cannot login. Useful for disabling a user that is temporarily on leave.

  • Locked - Set when a users has too many failed login attempts (controlled by the property stroom.security.identity.failedLoginLockThreshold). Can be un-set by a user with Manage Users Application Permission . A locked account cannot login.

  • Inactive - Set automatically in one of these cases:

    • A brand new account has not been used for a duration greater than stroom.security.identity.passwordPolicy.neverUsedAccountDeactivationThreshold.
    • An account has not been used for a duration greater than stroom.security.identity.passwordPolicy.unusedAccountDeactivationThreshold. A inactive account cannot login.

3 - Users and Groups

The Stroom user and group entities that can be granted application and document permissions.

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 . It can also represent non-human processing user, e.g. where a Stroom User is created and has an API Key created for it to allow a client system to use Stroom’s API .

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:

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:

4 - Application Permissions

Assigning application level permssions (such as ‘Manage Users’) to users or groups.

An Application Permission is a permission to perform an action that is not associated with a single Document 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:

Security
Application Permissions

Application Permission Types

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

Permission Description
Administrator Full administrator rights to access and manage all data, documents and screens, i.e. everything.
Annotations Create and view annotations in query results.
Change Owner Change the ownership of a document or folder to another user.
Data - Delete Delete streams.
Data - Export Download/export streams from a feed.
Data - Import Upload stream data into a feed.
Data - View View stream data (e.g. in the Data Viewer or a Dashboard text pane
Data - View With Pipeline View data in a Dashboard text pane that uses a pipeline.
Download Search Results Download search result data on a Dashboard.
Export Configuration Export content (i.e. documents, that you have permission to view) to a file.
Import Configuration Import content from a file.
Manage API Keys Access the API Keys screen to view, create, edit, delete the user’s own API keys. ‘Manage Users’ permission is also required to managed other users API keys
Manage Cache Access the Caches screen to view and clear system caches.
Manage DB Access the Monitoring -> Database Tables screen to view the state of the tables in the database.
Manage Index Shards Access the Shards sub-tab on an Index document.
Manage Jobs Access the Jobs screen to manage Stroom’s background jobs.
Manage Nodes Access the Nodes screen to view the nodes the cluster and manage their priority and enabled states.
Manage Policies Access the Data Retention screen to manage data retention rules.
Manage Processors Access the Processors tab and manage the processors/filters used to process stream data through pipelines.
Manage Properties Access to the Properties to manage the system configuration.
Manage Tasks Access the Server Tasks screen to view/stop tasks running on the nodes.
Manage Users Access the screens to manage users, groups, document/application permissions. Also gives the user the ability to manage API keys for other users.
Manage Volumes Access the Data Volumes and Index Volumes screens to create/edit/delete the index/data volumes used for Lucene indexing and the stream store.
Pipeline Stepping Step data through a pipeline using the Stepper.
View System Information Use the System Information API. This is used by the administrators for viewing some of the internal working of Stroom to aid in debugging issues.

5 - Document Permissions

Assigning document level permssions (such as ‘View’) to users or groups.

Document Permissions are permissions that are granted to Users or Groups for a specific Document . 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:

Permissions

Permission Types

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

Permission Description
Owner Same as delete plus ability to change the document’s permissions (i.e. grant permissions on this document to other users/groups.
Delete Same as edit plus permission to delete the document.
Edit Same as view plus permission to edit, move, rename or add tags to the document.
View Permission to see the document in the explorer tree, open it as read-only, copy it or export it (subject to also having the Export Configuration application permission.
Use Only allow use of a document, e.g. allow use of an index as part of a search process but do not allow viewing of the document itself.

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

Permission Description
Owner Same as delete plus ability to change the folder’s permissions (i.e. grant permissions on this folder to other users/groups.
Delete Same as edit plus permission to delete the folder.
Edit Same as view plus permission to edit, move, rename or add tags to the folder.
View Permission to see the folder in the explorer tree (and it’s child items that you also have View permission on), open it as read-only, copy it or export it (subject to also having the Export Configuration application permission.
Use Only allow use of a folder, e.g. allow use of an index as part of a search process but do not allow viewing of the folder itself.

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 user 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.

User/Group Permissions Direct/Inherited
Division 123 View on Dictionary IP Allow List Direct
Team A View on Dictionary IP Allow List Inherited
Team A Owner on Dashboard Team Dashboard Direct
jbloggs View on Dictionary IP Allow List Inherited
jbloggs Owner on Dashboard Team Dashboard Inherited
jbloggs View on Dashboard Frank’s Dashboard Direct

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 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.