IEC TS 62351-8:2011 pdf – Power systems management and associated information exchange – Data and communications security – Part 8: Role-based access control.
5.2.6 Markets
At the time of issuing this specification, there were no specific mandatory roles requested for markets. The mechanism to define own roles offered by this specification may be used to define use case specific roles whenever needed. Additional roles to be defined in the context of IECITS 62351-8 may also be part of an amendment or a new edition.
5.3 Role-to-right assignment with respect to other non-power system domains (e.g. industrial process control)
At the time of issuing this specification, there were no specific mandatory roles requested for non-power system domain. The mechanism to define own roles offered by this specification may be used to define use case specific roles whenever needed. Additional roles to be defined fl the context of IEC1TS 62351-8 may also be part of an amendment or a new edition.
6 General architecture for the PUSH model
6.1 General
FIgure 4 shows the authorization process when a subject wants to access from system A an object (e.g. an application) on system B.
We assume that the systems are properly configured, i.e. the role-to-right assignment has been loaded into system B and subject-to-role assignment with corresponding revision number is stored in the repository.
The small letters define the access control mechanism, i.e.
a) first, the subject authenticates itself from system A towards a repository for retrieval of its access tokens and roles via an LDAP-enabled service:
b) the repository provides the subject with the access token containing role(s); NOTE Stepe a) ad b) may be optional if the subject a afready in possession of the access lo&en
c) the subject submits the access token containing the role(s) from system A to the system B:
this can be done online or offline; the mapping is a one.to-many. i.e. the access token is valid for many systems B: restrictions are optional:
d) system B verifies the access tokens of the subject and gives the subject authorized access to the object according to the right(s) associated with the role inside the access token, Optionally, system B may verity whether the access token has not been revoked by accessing the repository.
The configuration of the role-to-right assignment Is a prerequisite to enforce RBAC and must be undertaken In the engineering process of the system;
e) acknowiedgement of system B to system A.
The process outlined from item a) to item e) is similar to Kerberos. The repository takes the function of a ticketing server It issues an access token with limited lifetime for a subject used by system A to authenticate towards target system B.
This specification focuses on the numbered parts in Figure 4 that are:
1) formats of access tokens containing roles (see Clause 8);
2) security roles and associated rights (see 52);
3) methods to transport the authorization information securely to the target system B using existing protocols (see Clause 10); and
4) verification of access tokens by the target system B The access token can be bound to a single message or an application layer session (see Clause 11).
6.2 Secur. acc.ss to th. LDAP-.nabl.d s.rvic.
This subclause targets the access to an LDAP enabled repository, holding the access token information.
LOAP v3 with SSUTLS should be used.
Each subject authenticating to the LDAP server should have the following entries:
— unique user identifier (user ID);
— authentication information; and
— aocess token.
7 General architecture for the PULL model
7.1 General
To support use cases, in which devices are used that do not feature an appropriate interface to provide the access token locally (e.g.. lEDs with simple HMI In terms of display and key pad), a mechanism is needed to provide the role information for the accessing user. The user may logon using a user ID and a password. The “PULL model described in this clause supports such a user ID, passwocd based logon. but may also be used in conjunction with certificate based logon.