- Alarm Recorder
- Artemis Command History Publisher
- Artemis Event Publisher
- Artemis Parameter Publisher
- Artemis TM Publisher
- Command History Recorder
- Data Link Initialiser
- Event Recorder
- Index Server
- Parameter Archive Service
- Parameter Recorder
- Processor Creator Service
- Replay Server
- System Parameters Collector
- XTCE TM Recorder
Yamcs includes a security subsystem which allows authenticating and authorizing users. Authentication is the act of identifying the user, whereas authorization involves determining what privileges this user has.
Once authorized, the user may be assigned one or more privileges that determine what actions the user can perform. Yamcs distinguishes between system privileges and object privileges.
A system privilege is the right to perform a particular action or to perform an action on any object of a particular type.
|ControlProcessor||Allows to control any processor|
|CreateInstances||Allows to create instances|
|ModifyCommandHistory||Allows to modify command history|
|ControlCommandQueue||Allows to manage command queues|
|Command||Allows to issue any command|
|GetMissionDatabase||Allows to read the entire MDB|
|ChangeMissionDatabase||Allows online changes to the MDB|
|ControlArchiving||Allows to manage archiving properties of Yamcs|
|ControlLinks||Allows to control the lifecycle of any data link|
|ControlServices||Allows to manage the lifecycle of services.|
|ManageAnyBucket||Provides full control over any bucket (including user buckets)|
|ReadEvents||Allows to read any event|
|WriteEvents||Allows to manually post events|
|WriteTables||Allows to manually add records to tables|
|ReadTables||Allows to read tables|
Yamcs extensions may support additional system privileges.
An object privilege is the right to perform a particular action on an object. The object is assumed to be identifiable by a single string. The object may also be expressed as a regular expression, in which case Yamcs will perform pattern matching when doing authorization checks.
|Command||Allows to issue a particular command|
|CommandHistory||Allows access to the command history of a particular command|
|InsertCommandQueue||Allows to insert commands to a particular queue|
|ManageBucket||Allow control over a specific bucket|
|ReadBucket||Allow readonly access to a specific bucket|
|ReadPacket||Allows to read a particular packet|
|ReadParameter||Allows to read a particular parameter|
|Stream||Allow to read and emit to a specific stream|
|WriteParameter||Allows to set the value of a particular parameter|
Yamcs extensions may support additional object privileges.
A user may have the attribute superuser. Such a user is not subject to privilege checking. Any check of any kind will automatically pass. An example of such a user is the System user which is used internally by Yamcs on some actions that cannot be tied to a specific user. The superuser attribute may also be assigned to end users if the AuthModule supports it.
The security subsystem is modular by design and allows combining different AuthModules together. This allows for scenarios where for example you want to authenticate via LDAP, but determine privileges via YAML files.
The default set of AuthModules include:
- YAML AuthModule
- Reads Yaml files to verify the credentials of the user, or assign privileges.
- LDAP AuthModule
- Attempts to bind to LDAP with the provided credentials. Also capable of reading privileges for the user.
- SPNEGO AuthModule
- Supports authenticating against a Kerberos server. This module includes extra support for Single-Sign-On via Yamcs web interface.
AuthModules have an order. When a login attempt is made, AuthModules are iterated a first time in this order. Each AuthModule is asked if it can authenticate with the provided credentials. The first matching AuthModule contributes the user principal. A second iteration is done to then contribute privileges to the identified user. During both iterations, AuthModules reserve the right to halt the global login process for any reason.
A special note on roles. Yamcs itself does not require roles nor does it keep track of roles on the User object. Permissions are always verified via user privileges. Specific AuthModules may however introduce roles as a convenience to group sets of privileges together.
Example from a typical deployment:
These options are supported:
- Whether security is enabled. If false then Yamcs will not require users to login and will assume that everybody shares a single account defined under the unauthenticatedUser property.
- Configures the user details of the default user. This property is only considered when enabled is set to false
- List of AuthModules that particpate in the login process. Each AuthModule may support custom configuration options which can be defined under the config key.