Managing users, permissions, and roles
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 four namespaces depending on which sample apps were installed:
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.SamplesDB
,SamplesDB2File
, andSamplesDB2Kafka
contain the CDC demo apps discussed in Running the CDC demo apps.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 |
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> [ 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) |
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 [<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.
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 yetROLES
{newuser.admin, newuser.useradmin, Global.systemuser, Global.uiuser}
: the user has the roles discussed aboveINTERNAL user
: not authenticated via LDAP