 |
Xentara v2.0.3
User Manual
|
|
Xentara v2.0.3
User Manual
|
Xentara uses access control lists (ACL) to control who has access to different features and elements of Xentara. ACLs allow flexible and fine-grained, role-based access control to all features of Xentara. ACLs are used whenever a client connected via a remote connection attempts to perform some action, like reading or writing a data point.
Entitlements describe a certain action a user may or may not be allowed to perform. Xentara contains five built-in entitlements:
Other entitlements can be defined by skills, or in the Xentara security configuration file. Please refer to the documentation of the individual skills for any entitlements they may define.
If a remote client has a specific entitlement, he or she can perform the corresponding action. A client that has the read entitlement for a specific data point, for example, can read that data point’s value. Whether a client has an entitlement or not, is determined by a combination of the roles of the client and the ACL of the element.
A role is used to specify which remote client has which entitlement. Each client can have one or more roles that determine his or her entitlements for a specific element. The mapping between roles and entitlements is done on a per-element basis using ACLs.
Often, a remote client’s roles depend on authentication information provided by the client. This can be an access token, a certificate, or a username and password. Which authentication methods are supported depends heavily on the protocol used by the remote client. The Xentara OPC UA server skill, for example, supports certificate-based and username/password authentication, because those are the authentication methods supported by OPC UA. The Xentara Web service does not support certificate-based authentication, but does support OAuth 2.0 authentication, because that is what the HTTP protocol supports.
Xentara has one built-in role named “Everyone”, and every remote client automatically has this role. You can define additional roles, like “Administrator”, “Maintenance”, “Client”, “UI”, etc., to be able to assign different entitlements to different users. You should define a role for each group of clients and/or users you want to be able to assign entitlements to.
ACLs (access control lists) perform the actual mapping between roles and entitlements. An ACL can either allow or deny an entitlement to a role. If the entitlement is allowed, the client can perform the appropriate action, if it is denied, they cannot.
For example, if an ACL allows the “write” entitlement for the role “Operators”, all clients that have the role “Operators” can write attributes of Xentara elements. If an ACL denies the “write” entitlement, the clients cannot write element attributes.
An ACL is expressid in the form of an “allow” and a “deny” list for each role. A typical ACL may look like this:
| Role | Allow | Deny |
|---|---|---|
| Everyone | read | write |
| Administrator | read, write | – |
This ACL specifies that clients with the role “Everyone” are allowed reading data points, but denied writing data points. Clients with the role “Administrator” are allowed to read and write data points.
Roles that do not appear in the ACL are considered to have an empty “allow” and an empty “deny” list.
If an entitlement appreads in neither the “allow” nor the “deny” list of a particular role, Then the inheritance rules described in ACL Inheritance are used to determine whether the entitlement is allowed or denied for that role.
If a client has more than one role, he or she is allowed to perform all actions that any of the roles allow. For example, if a client has both the roles “Administrator” and “Remote User”, and the entitlement “write” is allowed for the role “Administrator”, then the client will have write access to element attributes, even if the entitlement is denied for the role “Remote User”. It is enough that the entitlement is allowed for one of the roles the client has in order for the client to be able to perfomr the corresponding action. Adding new roles to a client will always increase the number of things he or she can do, never decrease.
The global access configuration is performed in the global ACL. The global ACL is specified in the Xentara security configuration file. The global ACL specifies the entitlements that apply for the entirety of xentara, except for elements for which an element ACL has been specified.
Each Xentara element in the Xentara model can have its own ACL. This can either be a completely new ACL, or an ACL that modifies the ACL of the parent element. If an ACL is specified for an element, that ACL automatically applies to all child elements as well, unless these have their own element ACLs. For example, if an element ACL allows the entitlement “write” for some role, then write access is automatically granted for all of the children, grandchildren etc. of that element as well. This allows you to easily specify access right for entire branches (sub trees) of the model tree.
The Xentara model itself can also have an element ACL, which controls access to the anonymous root node. Similar to the element ACLs of regular elements, this ACL automatically also applies to all top level elements that do not have their own ACLs, as the top level elements are considered child elements of the anonymous root of the model.
Element ACLs are specified in the Xentara model file.
ACLs have an “inherit” setting that determines whether the ACL is a completely new ACL, or whether it modifies its so called the parent ACL. The parent ACL of each ACL is determined as follows:
If inheritance is disabled, and an entitlement is not found in either the “allow” or “deny” lists of the ACL, then the entitlement is denied. In other words, for ACL without inheritance enabled, everything that isn’t explicitly allowed, is denied.
If inheritance is enabled, then any entitlement that does not appear in either the “allow” or “deny” lists for a particual role is looked up in the parent ACL. If the parent ACL has itself inheritance enabled, and the entitlement is not found there either, then the parent’s parent ACL is examined, etc. This goes on until either the entitlement is found, or one of the ACL has inheritance disabled. If the entitlement is not found at all, then it is considered to be denied.
The global ACL is handled slightly differently, because it does not have a parent ACL. If inheritance is enabled for the global ACL, then it inherits a special default ACL. This default ACL has a single “allow” list that allows the following entitlement for the built-in role “Everyone”:
The “allow” list may also contain additional entitlements defined by skills. Please refer to the documentation of the corresponding skill to determine if an entitlement defined by a skill is allowed by default.