Striim

Welcome to the Striim Help Center and Community Site

3.10.3 Managing users, permissions, and roles

Follow

Before a person can access Striim, an administrator must create a user account for them.

Understanding namespaces

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 three namespaces:

  • Global contains system-created objects including system-level roles, default types such as WAEvent and AlertEvent, and the DefaultKafkaProperties property set. Users cannot create objects in this namespace.

  • admin is empty and may be used by administrators for any purpose.

  • If you installed following the instructions in Installing Striim for evaluation purposes, Samples contains sample applications including those discussed in Sample applications for programmers.

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

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:

Note

The READ action is a prerequisite for all other actions. For example, to select from a stream, you must have both READ and SELECT permissions. If you have only SELECT permission, select will fail with a "no such object" error.

  • CREATE

  • DEPLOY

  • DROP

  • GRANT (also allows use of REVOKE)

  • QUIESCE

  • READ (allows user to see that objects exist, for example, when using the LIST command)

  • RESUME

  • SELECT (allows user to query objects and to preview stream contents in the UI)

  • START

  • STATUS

  • STOP

  • UNDEPLOY

  • UPDATE (also allows use of ALTER and RECOMPILE)

Components:

  • alertsubscriber

  • application

  • cache

  • cluster

  • cq

  • dashboard

  • deploymentgroup

  • flow

  • initializer

  • namedquery

  • namespace

  • node

  • permission

  • propertyset

  • propertytemplate

  • queryvisualization

  • role

  • server

  • source

  • stream

  • subscription

  • target

  • type

  • user

  • wactionstore

  • window

Roles

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:

role

A user with this role:

Global.admin

is a superuser, that is, may perform any action, including managing users, roles, applications, and clusters. By default, only users with this role have access to the admin namespace.

Global.agentrole

is assigned to the internal sys user for use in authenticating Forwarding Agents when they connect to the cluster

Global.appadmin

is automatically granted the admin role for every namespace created.

Global.appdev

is automatically granted the dev role for every namespace created.

Global.appuser

is automatically granted the enduser role for every namespace created.

Global.serverrole

is assigned to the internal sys user for use in authenticating servers when they connect to the cluster

Global.systemuser

This role is automatically granted to new users. By default, it allows use of types, property templates, and deployment groups in the Global namespace.

Global.uiuser

This role is automatically granted to new users. By default, it allows access to the Apps, Dashboard, Flow Designer, Monitor, and Source Preview pages.

The following roles are automatically created for each namespace:

role

A user with this role:

<namespace>.admin

can perform any action within the namespace.

<namespace>.dev

can perform any action within the namespace except DROP, GRANT, and REVOKE.

<namespace>.enduser

has read-only access to the namespace.

<namespace>.useradmin

can alter their own user account properties such as the password. This role is created only by CREATE USER, not by CREATE NAMESPACE.

System users and keystore

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

  • admin has all privileges on all namespaces.

  • sys authenticates servers and Forwarding Agents when they connect to the Striim cluster. Its only privileges are Global.serverrole and Global.agentrole. It does not have a namespace and cannot log in.

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;

TQL commands for users

CREATE USER <name>
  { IDENTIFIED BY <password> | USING LDAP <ldap property set> ALIAS FOR <LDAP user> }
  [ DEFAULT ROLE <namespace>.<role name> ];

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

User names:

  • must contain only alphanumeric characters and underscores

  • may not start with a numeric character

  • must be unique

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

role

notes

<username>.admin

has full control over their personal namespace (all other namespaces will be hidden and inaccessible until the user is granted additional roles)

<username>.useradmin

can change their password and other account details

Global.systemuser

can use use types, property templates, and deployment groups in the Global namespace (unless the administrator has modified this role)

Global.uiuser

can access the Apps, Dashboard, Flow Designer, Monitor, and Source Preview pages in the UI (unless the administrator has modified this role)

For discussion of the USING LDAP option, see Using LDAP authentication.

Warning

Passwords may contain only uppercase and lowercase letters, numbers, _, and $. Passwords are case-sensitive.

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, 
)

TQL commands for roles

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 <namespace>[.<application_name>] TO ROLE role_name;

Grants a role permission to perform one or more actions in the specified namespace or application.

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

Web UI permissions

The following permissions control access within the web UI:

  • *:*:apps_ui:*

  • *:*:dashboard_ui:*

  • *:*:monitor_ui:*

  • *:*:sourcepreview_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;

Inspecting users and roles with LIST and DESCRIBE

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:

  • CONTACT THROUGH []: no email address for the user has been specified yet

  • ROLES {newuser.admin, newuser.useradmin, Global.systemuser, Global.uiuser}: the user has the roles discussed above

  • INTERNAL user: not authenticated via LDAP

3.10.3
Was this article helpful?
0 out of 0 found this helpful

Comments