This section describes an overview of Tachyon role based access control (RBAC) and its components and how to configure Tachyon RBAC.
This is not intended as an in-depth explanation of what RBAC is, but as a demonstration of how it's been implemented in Tachyon and how users can configure it programmatically.
The C# examples assume you're using Tachyon Consumer SDK and you have an instantiated instance of Tachyon connector class in an object called connector.
All SDK methods return the same class called ApiCallResponse. Inside the object of ApiCallResponse you'll find a property called ReceivedObject. That object is the actual data received from the API. In the following examples this detail is left out, stating that the returned object contains the data. For example, when we say that XYZ object contains certain data, this means the ReceivedObject contains that data, since that is always true.
Basics of role based access control (RBAC)
Role-based access control is an access control mechanism defined around roles and privileges. This security model pivots around the concept or a Role. Users (called principals in Tachyon) can be assigned to a Role and it's through a Role they gain permissions to perform actions. Each element of Tachyon's security system leads back to a Role.
RBAC objects in Tachyon
Tachyon has several types of objects that are part of its RBAC system. This section briefly describes these object's description and purpose.
Principals are identical to users. They're not called users because the word 'user' is traditionally associated with a person. A principal is, from a technical standpoint, an Active Directory account which may be a user account or a computer account. It can also be an AD group.
Tachyon allows only principals authenticated through Windows authentication and known to Tachyon itself. Depending on the request, the Tachyon establishes the permissions of the calling principal by looking at the roles the principal is assigned to. By default, a fresh installation of Tachyon has a principal representing the user account installing it.
All permissions lead to roles. Principals must have roles assigned to them before using the system.
A permissions is an ability to perform an operation on a securable type.
A Securable type is an object that can have permissions assigned to it. For example, Instructions can have permissions, as can Consumers and Management Groups. Security itself is an object principals need permissions to, so they can modify it, it will also have a securable type. If an element of Tachyon has security defined for it, it must have a securable type.
An Instance is one, specifc copy of an object of a given Securable Type. This can, for instance, be a single Instruction Set.
While most permissions work on Securable Types as a general thing, where if a Principal is assigned a Permission on a given Securable Type they can work with any object of that type, some Securable Types allow Permissions to be specified on just one given instance of a Securable Type object, giving a more granular control over access to that Securable Type.
An Operation (or Applicable Operation) represents the type of an action that can be performed on a securable type, like "Read" or "Write".
Marc (Principal) through his Global Questioners (Role) has Questioner (Applicable Operation) permission on Instructions (Securable type).
A Principal will have a specific permission on given securable type through a role the principal belongs to. This is the only way principals can obtain permissions and permissions are always for a specific operation on a given type.
To establish the full permission set of a given principal you have to combine all permissions from all the roles assigned to that principal.
You can retrieve permissions in several different ways, for example as a Principal, a Role or a Securable Type.
Some APIs perform checks for the calling user by pulling the user information from the HTTP request itself. Other APIs allow you to specify which object you want to get permissions for.
Getting permissions for a Principal
Getting all Permissions
Retrieving a principal's permissions is done using the account name (for example "somedomain\jane.doe") of that principal. When directly using the API, you have to encode that account name into base64 before sending it, while Consumer API SDK will do the encoding for you.
In general, any GET endpoint will require you to base64 encode the principal name, due to the fact that principal names can contain characters that are not allowed in URIs.
The following examples use the "somedomain\jane.doe" account.
|Direct Consumer API call||C# code using Consumer SDK library|
Making a GET request to /Permissions/Principal/c29tZWRvbWFpblxqYW5lLmRvZQ== will yield following response:
Use Permissions object inside the Tachyon connector instance.
"permissions" object will contain the same data you can see in the JSON response on the left.
Checking for a specific Permission
Getting permissions for a Role
Getting permissions for a Securable Type
Who am I?
Active Directory search
Retrieving members of an Active Directory group
Configuring Tachyon's RBAC through the Consumer API
Adding Principals from Active Directory
Adding, Editing and Removing a Role
Assigning and unassigning Principals to Roles
Adding and removing Permissions to a Role
Assigning and unassigning Management Groups to a Role
Configuring Management Groups
Configuring Securable Types and Applicable Operations
Dealing with Operations