Managing users, permissions, and roles

Namespaces are logical domains within the Striim environment that contain applications, flows, and their components such as sources, streams, and so on. Namespace-level roles and permissions control which users can do what in Striim.

By default, in a new Striim installation, there are two or four namespaces depending on which sample apps were installed:

When you create a new user account, a personal namespace with the same name is created automatically. The user has admin privileges for that namespace so may create applications and dashboards in it.

It is possible for an application in one namespace to use components in another namespace. See Using namespaces for more information.

Permissions determine which actions each user can perform in Striim. Permissions are assigned to users through roles.

A permission defines one or more actions that may be performed on one or more component types. A permission's domain may be global (granted in all namespaces) or limited to one or more specified namespaces. Optionally, permission may be restricted to one or more objects (components, flows, and/or applications) specified by name.

The syntax is:

GRANT <action(s)> ON <component types(s)> <namespace>.<object>

For example, GRANT READ,SELECT ON type Global.*  means permission to read and select all types in the Global namespace. Since many basic Striim operations use those types, by default all users have this permission through the Global.systemuser role.

ALL (for actions) and * (for the other elements) are wildcards. For example, GRANT ALL ON * *.* means permission to perform all actions on all components in all objects in all namespaces. The admin user has this permission through the Global.admin role.

Actions:

Components:

Roles associate permissions with users and namespaces. A role may contain multiple permissions and multiple roles.

The default system-level roles that exist in a new Striim installation are:

The following roles are automatically created for each namespace:

Striim has two system user accounts that are created during installation:

The admin and sys passwords, as well as the metadata repository password, are stored in a Java KeyStore, striim/conf/sks.jks, using AES-256 and BCrypt.

If you prefer, you may create a user similar to sys that can authenticate only Forwarding Agents (replace ******** with a strong password):

CREATE USER agentauth IDENTIFIED BY ********;
DROP NAMESPACE agentauth CASCADE;
REVOKE Global.systemuser FROM USER agentauth;
REVOKE Global.uiuser FROM USER agentauth;
GRANT Global.agentrole TO USER agentauth;

CREATE USER <name>
  IDENTIFIED BY <password> 
  [ DEFAULT ROLE <namespace>.<role name> ];

Creates a new user and a personal namespace of the same name.

User names:

If you do not specify a default role, the user will have the following role and permissions:

For example, the following command creates a new user jsmith with the ability to view, edit, deploy, and run the sample applications:

CREATE USER jsmith IDENTIFIED BY secureps DEFAULT ROLE Samples.dev;

If you do not include the optional DEFAULT ROLE clause, the user will have access only to their personal namespace until granted additional roles as described in TQL commands for roles.

To change a user's password (requires UPDATE permission on the user), use:

ALTER USER <user name> SET ( password:"<password>" );

For example, ALTER USER jsmith SET (password:"newpass"); will change jsmith's password to newpass.

Optionally, you may specify a time zone to be used to convert DateTime values in dashboard visualizations and query output to the user's local time. For example:

ALTER USER jsmith SET (timezone:"America/Los_Angeles");

This can be useful when the user is in a different time zone than the Striim cluster. See http://joda-time.sourceforge.net/timezones.html for a full list of supported values.

Optionally, you may add additional fields that will be included in DESCRIBE USER output:

ALTER USER <user name> SET ( { firstname | lastname | email }:"<value>",... );

For example, ALTER USER jsmith SET (email:"jsmith@example.com", firstname:"James",lastname:"Smith", email:"jsmith@example.com"); will result in this DESCRIBE output:

USER jsmith CREATED 2017-10-02 16:49:32
USERID jsmith
FIRSTNAME James
LASTNAME Smith
TIMEZONE America/Los_Angeles
CONTACT THROUGH [type : email value : jsmith@example.com]
ROLES {samples.dev, jsmith.admin, jsmith.useradmin, Global.systemuser, Global.uiuser}
PERMISSIONS []
INTERNAL user.

NAMESPACE jsmith CREATED 2017-10-02 16:49:32
CONTAINS OBJECTS (
	ROLE DEV, 
	ROLE USERADMIN, 
	ROLE ENDUSER, 
	ROLE ADMIN, 
)

GRANT <namespace>.<role name> TO USER <user name>;

Grants a user a role.

GRANT Samples.appdev TO USER <user name>;

Gives a user the ability to view, edit, deploy, and run the sample applications.

CREATE ROLE <namespace>.<role name>;

Creates a role in the specified namespace. See Using namespaces for discussion of sharing roles among applications.

GRANT <action(s)> ON [<component type(s)>] <namespace>[.<application_name>] TO ROLE <namespace>.<role_name>;

Grants a role permission to perform one or more actions in the specified namespace or application. Optionally, you may specify one or more component types (see Permissions).

GRANT <namespace>.<role name> TO ROLE <namespace>.<role name>;

Grants one role to another. Effectively, this grants all the first role's permissions to the second role.

REVOKE <action(s)> ON [<component type(s)>] <namespace>[.<application_name>] FROM ROLE <namespace>.<role_name>;

Revokes a previously granted permission from a role.

REVOKE '<namespace>.<role name>' FROM ROLE <namespace>.<role name>;

Revokes a previously granted role from another role.

REVOKE <namespace>.<role name> FROM USER <user name>;

Revokes a previously granted role from a user.

The following permissions control access within the web UI:

The apps_ui permission allows access to the Apps, Flow Designer, and Metadata Manager pages.

You may allow access to other pages by granting one or more of the above permissions to a role. For example, the following would give users with the Samples:dev role access to the Source Preview page:

GRANT ALL ON sourcepreview_ui *.* TO ROLE Samples.dev;

UI permissions must always be granted to *.*. You cannot limit them to a particular namespace or object.

The following would revoke the permission granted in the previous command:

REVOKE ALL ON sourcepreview_ui *.* FROM ROLE Samples.dev;

The Global:admin role provides access to all pages of the web UI. Other users' access is controlled by the Global.uiuser role, which by default allows access to all pages. To change that, modify the role. For example, to restrict the Monitor page to admins:

revoke all on monitor_ui *.* from role Global.uiuser;

Use the LIST command to see what users or roles exist. For example, in a default installation:

W (admin) > list roles;
Processing - list roles
ROLE 1 =>  Global.uiuser
ROLE 2 =>  Global.admin
ROLE 3 =>  admin.admin
ROLE 4 =>  admin.dev
ROLE 5 =>  Global.appadmin
ROLE 6 =>  Global.appuser
ROLE 7 =>  Global.systemuser
ROLE 8 =>  admin.enduser
ROLE 9 =>  Global.appdev

Use the DESCRIBE command to see which roles and privileges are associated with a user or role. For example, for the default admin user and default Global.admin role (which as noted above has all privileges):

W (admin) > describe user admin;
Processing - describe user admin
USER admin CREATED 2017-09-28 12:08:59
USERID admin
CONTACT THROUGH []
ROLES {Global.admin}
PERMISSIONS []
INTERNAL user.

See what happens when we add a user:

W (admin) > CREATE USER newuser IDENTIFIED BY passwd;
Processing - CREATE USER newuser IDENTIFIED BY passwd
-> SUCCESS 
Elapsed time: 131 ms
W (admin) > describe user newuser;
Processing - describe user newuser

USER newuser CREATED 2017-10-02 17:19:00
USERID newuser
CONTACT THROUGH []
ROLES {newuser.admin, newuser.useradmin, Global.systemuser, Global.uiuser}
PERMISSIONS []
INTERNAL user.

The DESCRIBE output shows us: