Streams
Security
Streams manages security by principals (users, groups and
roles). Security objects protect Streams objects and
manages access to these objects. A user is granted
permission if:- the user has specific permission to the object,
- or if any of the groups the user belongs to has specific permission to the object,
- or if any of the roles the user has been assigned has specific permission to the object,
- or if any of the groups the user belongs to has assigned
roles that have specific permission to the object.
Principals
Users
Users are defined by the back end authentication provider
Streams is configured to use, for example LDAP.
Streams does not manage users in this repository. In
order to manage the users such as adding, updating and
removing users, you must use the tools provided by the
provider. Streams is only aware of the users that
have specific Streams permissions. Listing users via the
REST management API will only return the list of users Streams is
aware of, not the complete list of users in the back end
store.
Users can be granted specific object permissions.
For example, "read" access to security object "job_0" for
user A grants user A access to information about the job with identifier
0. A user can be assigned one or more roles.
Managing user access to Streams by roles is the
recommended approach.
Groups
Groups, like users, are defined by the back end authentication
provider Streams is configured to use. As with users, groups must be managed by
using the tools supplied by the provider. Streams is
only aware of groups that have explicit Streams
permissions. Listing groups via the REST management API will only
return the list of groups Streams is aware of, not the
complete list of groups in the back end store.
Groups can be granted specific object permissions.
For example, "read" access to security object "job_0" for
group A grants every user that belong to group A access to
information about the job with identifier 0. A group can be assigned
one or more roles. All users that belong to the
group would have the super set of all permissions for roles the
group has been assigned.
Roles
Roles are defined by Streams and can be used to group
permissions. Unlike users and groups, roles are
defined by Streams and can be managed by using the tools
provided by Streams.
Roles can be granted specific object permissions.
For example, "read" access to security object "job_0" for
role JOBUSER would grant every user that has been assigned
the role of JOBUSER, and any user that belongs to any group
that has been assigned the role of JOBUSER access to
information about the job with identifier 0. Roles is the recommended
way of managing access to Streams.
Security Objects
Streams uses security objects to manage access to Streams
objects. For exmple, you can manage access to the domain, instances, hosts and jobs.
Permissions
The permission settings are the settings Streams checks
for access. For example, if security object job_0
has delete permission set for user A, then user A has the
ability to cancel the job with identifier 0.
The following permissions are supported.
- Search
- Controls the ablilty to list children objects. For example, "search" permission to a job group for user A allows user A to list the jobs submitted under that job group.
- Add
- Controls the ability to add a child object. For example, "add" permission to a job group for user A allows user A to submit a job under that job group.
- Delete
- Controls the ability to delete the object. For example, "delete" permission to job_0 for user A allows user A to cancel the job with identifier 0.
- Read
- Controls the ability to access information about the object. For example, "read" permission to job_0 for user A allows user A to access job information and job data for the job with identifier 0.
- Write
- Controls the ability to change the information about the object. For example, "write" permission to job_0 for user A allows user A to manage the job, such as stop and start PEs for the job with identifier 0.
- Own
- Grants the user special permission to the object. For example, "own" permission to job_0 for user A gives user A all access to the job with identifier 0, regardless of what the other permissions are for user A.
Default Permissions
Default permissions are permissions that children objects
inherit when they are created. Default permissions
are not used for permission calculations. For
example, if security object for job group JOBGROUP1 has
default permissions of read, write and delete for user A,
when the first job is submitted to JOBGROUP1 (job identifier 0),
the security object job_0 would have permissions of read,
write and delete for user A.
Resolved Permissions
Resolved permissions are what the user has for
permissions after Streams has resolved the permissions
using all the groups to which the user belongs, all the roles
assigned to the user, and all the roles assigned to the
groups to which the user belongs.