Object Security

The security model within Redwood Server is made up of a number of core objects:

Privileges - the ability to see or do something. Subjects - a subject is an entity to which privileges may be granted. There are two types of subject: Users and Roles. Privilege Grants -control which users or roles have which privileges. Role Grants - control which users or roles have other roles.

Users are granted privileges in one of two manners: They are granted a privilege directly. They have a role that has that privilege (either directly, or indirectly via another role).

Special Roles

Special roles are used to grant access to the scheduler from the external security system. They are in two groups.

• The core roles that are used to control access.
• The predefined roles set up for convenience.
• The core roles are necessary in any security setup, use of the predefined roles is encouraged but not necessary.
• The descriptions here are summaries, for the exact privileges given to each role in a given version, check the user interface.

Core roles (always required):

• scheduler-administrator - can perform all actions.
• scheduler-bae-only-user - indicates that the user account is restricted to logging in via the SAP Inbound interface, only.
• scheduler-isolation-administrator - can import and modify users.
• scheduler-screen-reader - indicates that you are using a screen reader.
• scheduler-user - has access to Redwood Server only, cannot see any objects (always required, even for administrators).
• scheduler-viewer - read only access to all objects.
• redwood-administrator - can perform all actions.
• redwood-login - has access to Redwood Server only, cannot see any objects (always required, even for administrators).
• redwood-support - read only access to all objects.

The user access roles are bound to features that require a specific license key:

• scheduler-business-user - can access the business-user-centric user interface.
• scheduler-it-user - can access the it-user-centric user interface.

Predefined roles (optional):

• scheduler-event-operator - can raise and clear events, as well as all privileges assigned to scheduler-viewer.
• scheduler-job-administrator - can create/edit/delete event definitions, process definitions, and chain definitions and modify both processes, and chains, as well as all privileges assigned to scheduler-event-operator.
• redwood-operator - combination of the above two roles.

The core roles always have the same name in Redwood Server regardless of the manner used to grant these roles to roles or users in the external security system.

To be able to log in at all, users must have the 'scheduler-user' role. You can then control security using any combination of the other core roles, the predefined roles, or roles of your choice.

The predefined roles are:

• scheduler-viewer - has read only access to all objects.
• scheduler-job-administrator - can manage processes.
• scheduler-event-operator - can manage events.

Privileges and Ranks

A privilege is the ability to do or see something. Privileges are granted to Users or Roles using the Redwood Server user interface. There are some generic privileges that apply to all objects (like View or Delete), and other object specific privileges (like Submit Process).

The possible privileges for an object depend on its type. Privileges common to most object types are:

• Create - create an object
• View - see the object
• Edit - edit the object
• Delete - delete the object
• Some object types also have special privileges:
• SAP System - use the Business Automation API
• Events - raise, clear raised event, clear pending event, delete archived event
• Applications and Registry keys - create child objects
• User - enable or disable
• Operator Message - reply
• Queue - submit into, view processes in queue
• Process - view files
• Process Definition - submit
• Monitor - confirm
• Process server - control (start and stop)
• Audit trail - restore object

Privileges are never granted directly, they are always granted in combinations called Ranks. Ranks are similar to military ranks: a general can do more than a colonel who can do more than a captain. The ranks represent combinations of privileges that work together.

For example the 'Edit' rank always includes both the ‘View' and ‘Edit' privileges, since it does not make sense to be able to edit an object without first being able to view it. In general a higher Rank grants all the privileges of the ranks below it.

The exceptions are Edit and Delete:

• Edit allows Edit but not Delete.
• Delete allows Delete but not Edit.
• All allows both Edit and Delete.

note

The All rank will always include all privileges in all ranks below it.

Access and Admin

Each grant is made up of two parts:

• The Access rank - this controls what the user or role is allowed to do or see themselves.
• The Admin rank - this controls what the user or role is allowed to grant to others.

The Admin rank is always less than or equal to the Access rank: a user can never grant more privileges than they have themselves. The Admin rank may be 'None' in which case the user cannot grant any privileges to any other users.

The Access grant will never be 'None', since that means ‘No privileges', which is the same as not having been granted them in the first place.

Grant Levels

Privileges can be granted at different levels. Levels include:

• Partition
• Object type
• Object

Most privileges can be granted at all levels. The main exception is create. The privilege to create an object cannot be granted at object level, it can only be granted at the higher levels. Some objects are not partitionable, they do not have a partition and thus their privileges can only be granted system wide or on specific objects, Monitor Node for example.