Authentication, authorization and accounting
Contents
Basics
Local bus calls between EVA ICS services have zero security and authentication in favor of speed and reliability, so all local services are considered as trusted.
The following communications are considered as untrusted and require additional authentication and authorization:
External clients (such as web clients of HMI service)
RPC calls and events between EVA ICS nodes (Replication service).
Structure
EVA ICS AAA model model looks as the following. There are no strict requirements and any service layer can be replaced to a custom one, but in case of significant incompatibility, all services above the custom layer must be altered/patched/replaced.
Access control list
Access control lists are basic entities of EVA ICS AAA. ACLs are provided by Default ACL service, which allows:
ACL management
Formatting ACL data according to the caller service needs, including combining multiple ACLs together.
The default ACL has the following structure:
id: <ACL_ID>
admin: false
read:
items: ['oids']
pvt: ['paths']
rpvt: ['uris']
write:
items: ['oids']
deny_read:
items: ['oids']
pvt: ['paths']
rpvt: ['uris']
deny_write:
items: ['oids']
ops:
- log
- supervisor
meta:
var: ['value']
var2: ['value']
Fields:
admin admin ACL (has access to everything). In case if this field is set to true, all others (except meta) are ignored and not used for authorization.
read grants read access to items/pvt/rpvt
write grants both read and write access to items
deny_read denies access to certain items/pvt/rpvt
deny_write denies write access to certain items (e.g. unit actions, setting lvar values etc.)
ops list of special operations (“allow” in v3). supported values: log, supervisor
meta map of key=list fields, used for information purposes only
When two ACLs are combined, all fields are combined as well, including meta.
ACL can miss any field, the only mandatory field is “id”.
Note that the default ACL service does not check all fields for errors (e.g. field name misspelling), as they can be used by different HMI/replication services. In case of an unsupported ACL, HMI/replication service may return an error when applied.
ACLs can be managed with eva-shell:
eva acl -h
API key
API keys are used by certain services (such as HMI service and replication ones) to authenticate RPC calls and encrypt certain types of events.
Unlike similar products, API keys in EVA ICS are not connected with user accounts, so there is not necessary to create so-called “service account users”.
By default, API key management and authentication are provided by Local user/key authentication service service.
API keys can be managed with eva-shell:
eva key -h
User
User accounts are used by certain services (such as HMI service) to authenticate end-users. External RPC calls do not support user-based authentication, so a user must first login with its account and then use the obtained API token to authenticate all communications.
By default, API key management and authentication are provided by Local user/key authentication service service.
Additional user authentication services available:
Active directory auth service - included in EVA ICS Enterprise.
Local users can be managed with eva-shell:
eva user -h
Session token
Session tokens are provided by end-services (such as HMI service) to authenticate external RPC calls and communications.
When a token is issued, an end-service caches assigned ACLs and authenticates all further calls using them.
A token can expire or be destroyed by the end-service after the certain period of time or by request from either the token owner or by admin via bus call.
A token MUST be automatically destroyed by the end-service if the user account/ACLs it was formed on top, are modified or removed.