IEC TS 62351-8:2011

Power systems management and associated information exchange - Data and communications security - Part 8: Role-based access control

IEC/TS 62351-8:2011(E) covers the access control of users and automated agents to data objects in power systems by means of role-based access control. The scope of this specification covers everything that is needed for interoperability between systems from different vendors.

General Information

• Status: Published
• Publication Date: 28-Sep-2011
• ICS: 33.200 - Telecontrol. Telemetering
• Technical Committee: TC 57 - Power systems management and associated information exchange
• Drafting Committee: WG 15 - TC 57/WG 15
• Current Stage: DELPUB - Deleted Publication
• Start Date: 28-Apr-2020
• Completion Date: 28-Feb-2018

Standards Content (Sample)

IEC/TS 62351-8 ®
Edition 1.0 2011-09
TECHNICAL
SPECIFICATION
colour
inside
Power systems management and associated information exchange – Data and
communications security –
Part 8: Role-based access control

IEC/TS 62351-8:2011(E)
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by

any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either IEC or

IEC's member National Committee in the country of the requester.
If you have any questions about IEC copyright or have an enquiry about obtaining additional rights to this publication,
please contact the address below or your local IEC member National Committee for further information.

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite
ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie
et les microfilms, sans l'accord écrit de la CEI ou du Comité national de la CEI du pays du demandeur.

Si vous avez des questions sur le copyright de la CEI ou si vous désirez obtenir des droits supplémentaires sur cette

publication, utilisez les coordonnées ci-après ou contactez le Comité national de la CEI de votre pays de résidence.

IEC Central Office
3, rue de Varembé
CH-1211 Geneva 20
Switzerland
Email: [e-mail]
Web: www.iec.ch
About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.
 Catalogue of IEC publications: www.iec.ch/searchpub
The IEC on-line Catalogue enables you to search by a variety of criteria (reference number, text, technical committee,…).
It also gives information on projects, withdrawn and replaced publications.
 IEC Just Published: www.iec.ch/online_news/justpub
Stay up to date on all new IEC publications. Just Published details twice a month all new publications released. Available
on-line and also by email.
 Electropedia: www.electropedia.org
The world's leading online dictionary of electronic and electrical terms containing more than 20 000 terms and definitions
in English and French, with equivalent terms in additional languages. Also known as the International Electrotechnical
Vocabulary online.
 Customer Service Centre: www.iec.ch/webstore/custserv
If you wish to give us your feedback on this publication or need further assistance, please visit the Customer Service
Centre FAQ or contact us:
Email: [e-mail]
Tel.: [phone]
Fax: [phone]
IEC/TS 62351-8 ®
Edition 1.0 2011-09
TECHNICAL
SPECIFICATION
colour
inside
Power systems management and associated information exchange – Data and
communications security –
Part 8: Role-based access control

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
X
ICS 33.200 ISBN 978-2-88912-723-8

– 2 – TS 62351-8 © IEC:2011(E)

CONTENTS
FOREWORD . 5

INTRODUCTION . 7

1 Scope . 8

2 Normative references. 9

3 Terms, definitions and abbreviations . 10

3.1 Terms and definitions . 10

3.2 Abbreviations . 12

4 RBAC process model . 13
4.1 General . 13
4.2 Separation of subjects, roles, and rights. 14
4.2.1 General . 14
4.2.2 Subject assignment. 15
4.2.3 Role assignment . 16
4.2.4 Right assignment . 16
4.3 Criteria for defining roles . 16
4.3.1 Policies . 16
4.3.2 User, roles, and rights . 16
4.3.3 Introducing roles reduces complexity . 16
5 Definition of roles . 17
5.1 Role-to-right assignment inside the object in general . 17
5.1.1 General . 17
5.1.2 Number of supported rights . 17
5.1.3 Number of supported roles . 17
5.1.4 Flexibility of role-to-right mapping . 17
5.2 Role-to-right assignment with respect to power systems . 17
5.2.1 Mandatory roles and rights for logical-device access control . 17
5.2.2 Power utility automation – IEC 61850 . 20
5.2.3 CIM – IEC 61968 . 22
5.2.4 AMI. 22
5.2.5 DER . 22
5.2.6 Markets . 23
5.3 Role-to-right assignment with respect to other non-power system domains
(e.g. industrial process control) . 23
6 General architecture for the PUSH model . 23
6.1 General . 23
6.2 Secure access to the LDAP-enabled service . 24
7 General architecture for the PULL model . 24
7.1 General . 24
7.2 Secure access to the LDAP-enabled service . 26
7.3 LDAP directory organization . 26
8 General application of RBAC access token . 26
8.1 General . 26
8.2 Session based approach . 27
8.3 Message based approach . 28
9 Definition of access tokens . 28
9.1 General . 28

TS 62351-8 © IEC:2011(E) – 3 –

9.2 Supported profiles . 29

9.3 Identification of access token . 29

9.4 General structure of the access tokens . 29

9.4.1 Mandatory fields in the access tokens . 29

9.4.2 Mandatory profile-specific fields . 29

9.4.3 Optional fields in the access tokens . 30

9.4.4 Definition of specific fields . 30

9.5 Specific structure of the access tokens . 32

9.5.1 Profile A: X.509 ID certificate . 32

9.5.2 Profile B: X.509 attribute certificate . 34

9.5.3 Profile C: Software token . 37
9.6 Distribution of the access tokens . 37
10 Transport profiles . 38
10.1 Usage in TCP-based protocols . 38
10.2 Usage in non-Ethernet based protocols . 38
11 Verification of access tokens. 38
11.1 Normative part . 38
11.1.1 General . 38
11.1.2 Access token authenticity . 38
11.1.3 Time period . 39
11.1.4 Access token integrity . 39
11.2 Optional part . 39
11.3 Revocation methods . 39
11.3.1 General . 39
11.3.2 Supported methods . 40
12 Interoperability . 40
12.1 General . 40
12.2 Supported access tokens . 40
12.3 How to ensure backward compatibility . 40
12.4 How to extend the list of roles and rights . 41
12.5 How to map this specification to specific authorization mechanisms . 41
Bibliography . 42

Figure 1 – Generic framework for access control . 13

Figure 2 – Diagram of RBAC with static and dynamic separation of duty according to
(ANSI INCITS 359-2004) . 14
Figure 3 – User, roles, rights and operations . 15
Figure 4 – Schematic view of authorization mechanism based on RBAC . 24
Figure 5 – Schematic view of authorization mechanism based on RBAC PULL model . 25
Figure 6 – Session based RBAC approach . 28

Table 1 – List of pre-defined role-to-right assignment . 18
Table 2 – List of mandatory pre-defined rights . 19
Table 3 – Pre-defined roles . 20
Table 4 – Mandatory role-to-right mapping for service access control . 21
Table 5 – The ALLOW right . 21
Table 6 – The DENY right. 21

– 4 – TS 62351-8 © IEC:2011(E)

Table 7 – VIEW right and associated ACSI services . 22

Table 8 – Mapping between ID and attribute certificate . 36

TS 62351-8 © IEC:2011(E) – 5 –

INTERNATIONAL ELECTROTECHNICAL COMMISSION

____________
POWER SYSTEMS MANAGEMENT
AND ASSOCIATED INFORMATION EXCHANGE –

DATA AND COMMUNICATIONS SECURITY –

Part 8: Role-based access control

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of

patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
The main task of IEC technical committees is to prepare International Standards. In
exceptional circumstances, a technical committee may propose the publication of a technical
specification when
• the required support cannot be obtained for the publication of an International Standard,
despite repeated efforts, or
• the subject is still under technical development or where, for any other reason, there is the
future but no immediate possibility of an agreement on an International Standard.
Technical specifications are subject to review within three years of publication to decide
whether they can be transformed into International Standards.
IEC 62351-8, which is a technical specification, has been prepared by IEC technical committee
57: Power systems management and associated information exchange.

– 6 – TS 62351-8 © IEC:2011(E)

The text of this technical specification is based on the following documents:

Enquiry draft Report on voting

57/1119/DTS 57/1153/RVC
Full information on the voting for the approval of this technical specification can be found in the

report on voting indicated in the above table.

This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.

A list of all the parts in the IEC 62351 series, published under the general title Power systems
management and associated information exchange – Data and communications security, can
be found on the IEC website.
The committee has decided that the contents of this publication will remain unchanged until the
stability date indicated on the IEC web site under "http://webstore.iec.ch" in the data related to
the specific publication. At this date, the publication will be
• transformed into an International standard,
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.

IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct understanding
of its contents. Users should therefore print this document using a colour printer.

TS 62351-8 © IEC:2011(E) – 7 –

INTRODUCTION
This Technical specification covers access control in power systems. The power system

environment supported by this specification is enterprise-wide and extends beyond traditional

borders to include external providers, suppliers, and other energy partners. Driving factors are

the liberalization of the energy sector, the increasingly decentralized generation of energy, and

the need to control access to data of precious resources. This specification supports a

distributed security environment in which security is also a distributed service.

The power system sector is continually improving the delivery of energy by leveraging technical

advances in computer-based applications. Utility operators, energy brokers and end-users are

increasingly accessing multiple applications to deliver, transmit and consume energy in a
personalized way. These disparate applications are naturally connected to a common network
infrastructure that typically supports protection equipment, substation automation protocols,
inter-station protocols, remote access and business-to-business services. Consequently,
secure access to these distributed and often loosely coupled applications is even more
important than access to an application running on a stand-alone object.
Secure access to computer-based applications involves authentication of the user to the
application. After authentication, the level at which a user can use the application is
determined. The use of local mechanisms for authorization creates a patchwork of approaches
which are difficult to uniformly administer across the breadth of a power system enterprise.
Each application decides the authorization on its own logic. If applications can use a network, a
database can serve as a trusted source of user’s group or role affiliation. Thus, the access to a
shared user base can be controlled centrally. Each application can then examine the rights
listed for a subject and corresponding role and determine their level of authorization.
The role of a user is transported in a container called an access token of that user to the
object. Access tokens are created and administered by a (possibly federated) identity
management tool. All access tokens have a lifetime and are subject to expiration. Prior to
verification of the access token itself, the user transmitting the access token must be
authenticated by the object. The object trusts the management tool to issue access tokens with
suitable lifetime. This enables local verification of the access token’s validity at remote sites
without the need to access a centralized repository (e.g. a centralized revocation list).
Three different access token formats are supported as three different profiles. Two of them are
X.509 Access tokens and the third is a software token similar to Kerberos. They can be used
over TCP/IP and serial communication links.
This specification defines role-based access control (RBAC) for enterprise-wide use in power
systems. It supports a distributed or service-oriented architecture where security is a
distributed service and applications are consumers of distributed services.

– 8 – TS 62351-8 © IEC:2011(E)

POWER SYSTEMS MANAGEMENT
AND ASSOCIATED INFORMATION EXCHANGE –

DATA AND COMMUNICATIONS SECURITY –

Part 8: Role-based access control

1 Scope
This technical specification covers the access control of users and automated agents – in the
following subjects – to data objects in power systems by means of role-based access control
(RBAC). RBAC is not a new concept used by many operating systems to control access to
system resources. RBAC is an alternative to the all-or-nothing super-user model. RBAC is in
keeping with the security principle of least privilege, which states that no subject should be
given more rights than necessary for performing that subject’s job. RBAC enables an
organization to separate super-user capabilities and package them into special user accounts
termed roles for assignment to specific individuals according to their job needs. This enables a
variety of security policies, networking, firewall, back-ups, and system operation. A site that
prefers a single strong administrator but wants to let more sophisticated users fix portions of
their own system can set up an advanced-user role. RBAC is not confined to users however, it
applies equally well to automated computer agents, i.e., software parts operating independent
of user interactions. The following interactions are covered by the scope of this technical
specification:
– local (direct wired) access to the object by a human user;
– local (direct wired) access to the object by a local and automated computer agent, e.g.
another object at the substation;
– direct access by a user to the object using the objects’ built-in HMI or panel;
– remote (via dial-up or wireless media) access to the object by a human user;
– remote (via dial-up or wireless media) access to the object by a remote automated
computer agent, e.g. another object at another substation, or a control centre application.
As in many aspects of security, RBAC is not just a technology; it is a way of running a
business. As subject names change more frequently than role names and as role names
change more frequently than the rights of a data model (e.g. IEC 61850), it is advisable to store
the frequently changing entities (i.e. the subjects names) outside the object. Less frequently
changing role names and rights are stored inside the object.

RBAC thus provides a means of reallocating system controls as defined by the organization
policy.
The scope of this specification covers everything that is needed for interoperability between
systems from different vendors. The purpose of this specification is therefore:
– firstly, to introduce ‘subjects-roles-rights’ as authorization concept;
– secondly, to promote role-based access control for the entire pyramid in power system
management; and
– thirdly, to enable interoperability in the multi-vendor environment of substation automation
and beyond.
Out of scope for this specification are all topics which are not directly related to the definition of
roles and access tokens for local and remote access, especially administrative or
organizational tasks, such as:
– user names and password definitions/policies;

TS 62351-8 © IEC:2011(E) – 9 –

– management of keys and/or key exchange;

– engineering of roles;
– assignment of roles;
– selection of trusted certificate authorities issuing credentials (access tokens);

– defining the tasks of a security officer;

– integrating local policies in RBAC.

NOTE These issues will be addressed in IEC/TS 62351-9 .

The IEC 62351 series specifies end-to-end security in power systems so that secure

connections are established between applications. RBAC is recognized as a potentially efficient
and safe means to control access to data objects.
Existing standards (see [ANSI INCITS 359-2004], [IEC 62443], and [IEEE 802.1X-2004]) in the
process control industry and access control ([RFC2904] and [RFC2905]) are not sufficient as
none of them specify either the exact role name and associated rights, the format of the access
tokens or the detailed mechanism by which access tokens are transferred to and authenticated
by the target system – however, all this information is needed though for interoperability.
2 Normative references
The following referenced documents are indispensable for the application of this document. For
dated references, only the edition cited applies. For undated references, the latest edition of
the referenced document (including any amendments) applies.
IEC 61850 (all parts), Communication networks and systems in substations
IEC 61850-7-2, Communication networks and systems for power utility automation – Part 7-2:
Basic information and communication structure - Abstract communication service interface
(ACSI)
IEC/TS 62351-1, Power systems management and associated information exchange – Data
and communications security – Part 1: Communication network and system security –
Introduction to security issues
IEC/TS 62351-3, Power systems management and associated information exchange – Data
and communications security – Part 3: Communication network and system security – Profiles
including TCP/IP
IEC/TS 62351-4, Power systems management and associated information exchange – Data
and communications security – Part 4: Profiles including MMS
IEC/TS 62351-5, Power systems management and associated information exchange – Data
and communications security – Part 5: Security for IEC 60870-5 and derivatives
IEC 62443 (all parts), Industrial communication networks – Network and system security
ISO 9594-8/ITU-T Recomendation X.509:2005, Information technology – Open Systems
Interconnection – The Directory: Public-key and attribute certificate frameworks

___________
Under consideration.
– 10 – TS 62351-8 © IEC:2011(E)

3 Terms, definitions and abbreviations

For the purposes of this document, the terms and definitions of IEC/TS 62351-1 apply, as well

as the following.
3.1 Terms and definitions
3.1.1
area of responsibility
range of authority, for instance based on network segregation

3.1.2
automated agent
computer program running on a single machine
NOTE It performs local and/or remote operations independent of user inputs.
3.1.3
access token
evidence or testimonials concerning one's right to credit, confidence, or authority
3.1.4
holder
entity that possesses or owns an access token
3.1.5
issuer
entity that issues an access token
3.1.6
identity provider
entity that creates, maintains and manages identity information; typically used in single sign-on
scenarios
3.1.7
object
any system resource subject to access control such as a file, printer, terminal, database
record, etc.
3.1.8
operation
executable image of a program which upon invocation executes some function/activity for the
subject
3.1.9
privilege
attribute or property assigned to a subject by an authority
3.1.10
privilege management infrastructure
PMI
the infrastructure able to support the management of privileges in support of a comprehensive
authorization service and in relationship with a public key infrastructure
3.1.11
right
atomic set of accessing privileges assigned to a particular system object

TS 62351-8 © IEC:2011(E) – 11 –

3.1.12
role
job function within the context of an organization with some semantics associated regarding the

authority and responsibility conferred on the user assigned to the role

NOTE A role subsumes a set of rights.

Pre-defined role: a role that is defined in this specification.

Default role: a role that is defined by the vendor of the protection equipment (not by its specification) and that is

valid generally for all objects of that vendor.

Specific role: a role that is defined by the utility operator for its particular needs.

3.1.13
service
permission in the context of IEC 61850
3.1.14
session
encounter between a user and an application or with the computer in general
NOTE One user session is the time between starting the communication channel (either local or remote) and
terminating (either by the user or the system).
3.1.15
static separation of duty
SSD
enforcement constraints on the assignment of users to roles
NOTE Membership in one role may prevent the user from being a member of one or more other roles, depending
on the SSD rules enforced.
3.1.16
dynamic separation of duty
DSD
limitation of the availability of rights by placing constraints on the roles that can be activated
within or across a user’s sessions
NOTE 1 DSD provides the capability to address potential conflict of interest issues at the time a user is assigned
to a role.
NOTE 2 DSD allows a user to be authorized for roles that do not cause a conflict of interest when acted in
independently, but which produce policy concerns when activated simultaneously. Although this separation of duty
could be achieved through the establishment of a static separation of duty relationship, DSD relationships generally
provide the enterprise with greater operational flexibility.

3.1.17
out-of-band
communications which occur outside a previously established communication method or
channel
3.1.18
service provider
an object that provides services
NOTE It is subject to access control.
3.1.19
subject
user or an automated agent
NOTE A subject is a right holder. It has a name attribute whose value is mandatory. It is this name that is used to
enrol a subject in a particular role.

– 12 – TS 62351-8 © IEC:2011(E)

3.1.20
token
physical instance of an access token

3.1.21
user
human being
3.2 Abbreviations
For the purposes of this document, the following abbreviations apply.
AC attribute certificate
ACL access control list
ACRL attribute certificate revocation list
ACSI abstract communication system interface
AMI advanced metering infrastructure
AoR area of responsibility
CIM common Information model
CRL certificate revocation list
DER distributed energy resource
HMAC keyed-hash message authentication code
HMI human machine interface
IED intelligent electronic device; stands for a field device, a gateway or a PC
in the net control centre
ID identity
IS international standard
ISA instrument system and automation society
LDAP lightweight directory access protocol
LD logical-device (IEC 61850)
LN logical node (IEC 61850)
OCSP online certificate status protocol
OID object identifier
OSI open systems interconnection
PKI public key infrastructure; the complete set of processes required to
provide encryption and digital signature services

privilege management infrastructure; the complete set of processes
PMI
required to provide an authorization service

RBAC role-based access control
SCL substation configuration description language (IEC 61850)
SSL secure socket layer
SW software
TCP transport control protocol
TLS transport layer security
UID universal identifier
TS 62351-8 © IEC:2011(E) – 13 –

4 RBAC process model
4.1 General
The purpose of an access control mechanism is to protect system resources, formally called

objects. For a system that implements RBAC, system resources can represent information

containers (e.g. files, directories in an operating system and/or columns, rows, tables, and

views within a database management system) or exhaustible device resources, such as

printers, disk space and CPU cycles.

Role-based access control (RBAC) is a technology that has the potential to reduce the

complexity and cost of security administration in networks with large numbers of intelligent
devices. Under RBAC, security administration is simplified through the use of roles and
constraints to organize subject access levels. RBAC reduces costs within an organization
primarily because it accepts that employees change roles and responsibilities more frequently
than the rights within roles and responsibilities have to be changed.
Figure 1 is a generic picture for access control. It consists of a subject, an identity provider and
an object.
Identity provider
repository
Subject
Object
IEC  2272/11
Figure 1 – Generic framework for access control
The subject wants to access the resources of the object by means of an access token provided
by the identity provider. There are generally two ways to do this:
– the access token can be fetched by the object from the repository of the identity provider
when the subject connects to the object: This case is called “PULL”;

– alternatively, the subject can first fetch the access token from the repository of the identity
provider prior to accessing the object: This case is called “PUSH”.
The access token contains the role of the subject. Role-based access control is part of a
general authentication, authorisation and accounting infrastructure for access control to data.
The subject provides information about its identity to the repository of the identity provider in
order to get authenticated along with a request for an access token to the object (PUSH) or the
object can get the required information (access token) from a repository (PULL).
In general, the subject has rights assigned via roles that are pushed to or pulled by the object.
In deciding whether to employ a push or pull model, several factors should be considered:
For the PUSH model:
– the access token holding the authorisation information must be sufficiently secure;

– 14 – TS 62351-8 © IEC:2011(E)

– the access token should have a short time to live to prevent replay attacks;

– the access token must be validated;

– the token exchange should be cryptographically protected.

For the PULL model:
– the authentication service at the repository must be accessible;

– a trusted communication path to the authentication service is required;

– there is no computational overhead associated with verification of the token (but there will

be a time delay for communications);

– the pulled authentication information is always current.
4.2 Separation of subjects, roles, and rights
4.2.1 General
A model for RBAC including separation of duty (static as well as dynamic) is given in Figure 2.

Static separation
of duty
Subject Right
assignment assignment
Subject Role Operation Object
1.n 1.n 1 1.n
1.n
Right
Dynamic separation
of duty
1.n
Session
IEC  2273/11
Figure 2 – Diagram of RBAC with static and dynamic
separation of duty according to (ANSI INCITS 359-2004)
The arrows in Figure 2 indicate relationships (e.g., a subject can be assigned to one or more

roles, and a role can be assigned to one or more subjects). This arrangement provides great
flexibility and granularity in assigning rights to roles and subjects to roles. Without these
conveniences, there is a danger that a subject may be granted more access to resources than
is needed because of limited control over the type of access that can be associated with
subjects and resources. Any increase in the flexibility of controlling access to resources also
strengthens the application of the principle of least right.
Each session is a mapping of one subject to possibly many roles, i.e., a subject establishes a
session during which the subject activates one or a subset out of a set of roles that it is
assigned to. Each session is associated with a single subject and each subject is associated
with one or more roles.
The main components of RBAC are thus: subject, role, right for operations and objects, and
session.
There are two mappings between these components that need be configured by the
administrator:
TS 62351-8 © IEC:2011(E) – 15 –

– subject-to-role mapping termed subject assignment; and

– role-to-right mapping termed role assignment.

Figure 3 gives a survey of subjects, roles, rights, and operations in the scope of the IEC 61850

standard.
Subject Subject
...
Subject
A B
Subject assignment
Role Role Role Role
... ...
A X Y
IEC 62351-8
Role assignment
Right Right
... ...
View Read Security
A
IEC 62351-8
Right assignment
Operation/
Object
... ...
IEC  2274/11
Example: IEC 61850
Figure 3 – User, roles, rights and operations
A right subsumes a set of operations which is determined by the data model in use; e.g. a
protection system may use the IEC 61850 data model. This specification supports data models
for power systems as listed in 5.2.

A set of roles and associated rights must be defined to enable proper operability. These so-
called pre-defined roles and pre-defined rights are encircled by grey boxes in Figure 3. They
represent the core part of this specification and are defined in 5.2. The pre-defined rights
represent an abstraction layer towards the underlying data models.
4.2.2 Subject assignment
The subject assignment or subject-to-role mapping is stored outside the system in a repository.
The repository may be accessed with an LDAP-enabled service to retrieve the access tokens.
One or more subjects can be assigned to one or more roles.
The time period during which a particular subject-to-role mapping is valid should be kept
flexible.
GetLogicalNodeDirectory
GetDataDirectory
GetDataDefinition
GetDataSetDirectory
Priviledge A
– 16 – TS 62351-8 © IEC:2011(E)

4.2.3 Role assignment
The role assignment or role-to-right mapping is stored inside the object. It represents the

configuration of the object and depends on the data model in use.

This mapping is also determined by security/safety regulations and is the main focus of this

specification. Pre-defined roles and pre-defined rights are used to implement such policies.

A right belongs to at least one role.

NOTE Role definition and role assignment can have different life-cycles. To assure consistency, they are equipped
with a revision number which must be checked in the object (see also 11.1). Otherwise, a role can be presented to
an object with a different right assignment than the one stored in the object.
4.2.4 Right assignment
The mapping between rights, operations and objects is given by the data model in use. Refer to
5.2.
4.3 Criteria for defining roles
4.3.1 Policies
A minimum set of roles is defined by policies and standards (such as NERC CIP-001 –
CIP-009). These roles are mandatory and are called pre-defined roles. These pre-defined roles
are defined in this technical specification.
Vendors of power system equipment may deploy their equipment with a set of additional roles.
These roles are called default roles and may serve vendors specific configuration procedures
and/or vendor specific handling of the equipment.
Finally, roles may be defined by the utility operator and/or the substation management to meet
their specific needs (e.g. local implementation requirements). These roles are termed specific
roles.
4.3.2 User, roles, and rights
Subject names change more frequently than role names and role names change more
frequently than the rights of a data model (e.g. IEC 61850).
It is thus advisable to have the frequently changing entities centrally stored and administered
whereas the entities with a long lifetime are stored decentralized in the object.

– The subject-to-role mapping is stored out-side the object at the identity provider
(repository).
– Thus, the role-to-right mapping is stored inside the object.
4.3.3 Introducing roles reduces complexity
Without roles, the complexity of the subject-to-right assignment amounts to
O(s× ri) (1)
where │s│ is the number of subjects and │ri│ is the number of rights.
The introduction of roles results in two mappings: one mapping of subjects to roles and a
second one of roles to rights. The complexity of these two mappings yields

TS 62351-8 © IEC:2011(E) – 17 –

O(s× ro)+ O(ro× ri) (2)
where │ro│ is the number of roles.

Equation (2) can be smaller than Equation (1). In fact, this is always the case if the number of

roles is smaller than the half of the minimum of the number of subjects and rights. Thus, the
concept of roles is recognized as a possibly efficient means to control access rights.

5 Definition of roles
5.1 Role-to-right assignment inside the object in general
5.1.1 General
Roles shall be assigned a set of rights.
Remark: The rights are defined by the data model in
...