ISO/IEC 29146:2024

International
Standard
ISO/IEC 29146
Second edition
Information technology — Security
2024-01
techniques — A framework for
access management
Technologies de l'information — Techniques de sécurité — Cadre
pour gestion d'accès
Reference number
© ISO/IEC 2024
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2024 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 4
5 Concepts . 5
5.1 A model for controlling access to resources .5
5.1.1 Overview .5
5.1.2 Relationship between identity management system and access management
system .6
5.1.3 Security characteristics of the access method .7
5.2 Relationships between logical and physical access control .7
5.3 Access management system functions and processes .8
5.3.1 Overview .8
5.3.2 Access control policy .8
5.3.3 Privilege management.9
5.3.4 Policy-related attribute information management .10
5.3.5 Authorization .11
5.3.6 Monitoring management . 12
5.3.7 Alarm management . 12
5.3.8 Federated access control . 13
6 Reference architecture . 14
6.1 Overview .14
6.2 Basic components of an access management system . 15
6.2.1 Authentication endpoint . 15
6.2.2 Policy decision point . 15
6.2.3 Policy information point . 15
6.2.4 Policy administration point .16
6.2.5 Policy enforcement point .16
6.3 Additional service components .16
6.3.1 General .16
6.3.2 Subject centric implementation .16
6.3.3 Enterprise centric implementation .18
7 Additional requirements and concerns . 19
7.1 Access to administrative information .19
7.2 AMS models and policy issues .19
7.2.1 Access control models .19
7.2.2 Policies in access management .19
7.3 L egal and regulatory requirements. 20
8 Practice .20
8.1 Processes . 20
8.1.1 Authorization process . 20
8.1.2 Privilege management process . 20
8.2 Threats .21
8.3 Control objectives . 22
8.3.1 General . 22
8.3.2 Validating the access management framework . 22
8.3.3 Validating the access management system .24
8.3.4 Validating the maintenance of an implemented AMS . 28
Annex A (informative) Common access control models .31

© ISO/IEC 2024 – All rights reserved
iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
This second edition cancels and replaces the first edition (ISO/IEC 29146:2016), of which it constitutes a
minor revision. It also incorporates the Amendment ISO/IEC 29146:2016/Amd.1:2022. The changes are as
follows:
— the text has been editorially revised and normative references updated.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2024 – All rights reserved
iv
Introduction
Management of information security is a complex task that is based primarily on a risk-based approach and
that is supported by several security techniques. The complexity is handled by several supporting systems
that can automatically apply a set of rules or policies consistently.
Within the management of information security, access management plays a key role in the administration
of the relationships between the accessing party (subjects that can be human or non-human entities) and the
information technology resources. With the development of the Internet, information technology resources
can also be located over distributed networks. The management of access is expected to comply to a policy
and to have common terms and models defined in a framework.
Identity management is also an important part of access management. Access management is mediated
through the identification and authentication of parties that seek to access information technology
resources. Access management relies on the existence of an underlying identity management system.
A framework for access management is one part of an overall identity and access management framework.
The other part is the framework for identity management, which is defined in the ISO/IEC 24760 series.
This document describes the concepts, actors, components, reference architecture, functional requirements
and the practice of an access control framework.
The document focuses mainly on the access control for a single organization. It provides additional
considerations for access control in collaborative arrangements across multiple organizations. The
document includes examples of access control models.

© ISO/IEC 2024 – All rights reserved
v
International Standard ISO/IEC 29146:2024(en)
Information technology — Security techniques — A
framework for access management
1 Scope
This document defines and establishes a framework for access management (AM) and the secure
management of the process to access information and information and communications technologies (ICT)
resources, associated with the accountability of a subject within some contexts.
This document provides concepts, terms and definitions applicable to distributed access management
techniques in network environments.
This document also provides explanations about related architecture, components and management
functions.
The subjects involved in access management can be uniquely recognized to access information systems, as
defined in the ISO/IEC 24760 series.
The nature and qualities of physical access control involved in access management systems are outside the
scope of this document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements 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.
ISO/IEC 24760-1, Information technology — Security techniques — A framework for identity management —
Part 1: Terminology and concepts
ISO/IEC 29115, Information technology — Security techniques — Entity authentication assurance framework
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 24760-1, ISO/IEC 29115, and
the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
access control
granting or denying an operation to be performed on a resource (3.14)
Note 1 to entry: A primary purpose of access control is to prevent unauthorized access to information or use of
ICT resources based on the business and security requirements; that is, the application of authorization policies to
particular access requests.
Note 2 to entry: When an authenticated subject (3.15) makes a request, the resource owner will authorize (or not)
access in accordance with access policy and subject privileges.

© ISO/IEC 2024 – All rights reserved
3.2
access management
set of processes to manage access control (3.1) for a set of resources (3.14)
3.3
access token
trusted object encapsulating the authority for a subject (3.15) to access a resource (3.14)
Note 1 to entry: An access token is issued by the policy decision point (PDP) and consumed by the policy enforcement
point (PEP) for the resource.
Note 2 to entry: An access token may contain access permission information for a subject to access the resource and
identifying information for the authority of the authorization decision.
Note 3 to entry: An access token may contain information that enables its integrity to be validated.
Note 4 to entry: An access token may take a physical or a virtual form.
3.4
attribute
characteristic or property used to describe and to control access to a resource (3.14)
Note 1 to entry: The rules for accessing a resource are defined in an access control (3.1) policy which specifies the
attributes required for the granting of access by a subject (3.15) to a resource for a specific operation.
Note 2 to entry: Attributes can include subject attributes, resource attributes, environmental attributes and other
attributes used to control access as specified in the access control policy.
3.5
endpoint
location in an access management (3.2) system where an access control (3.1) function is performed
Note 1 to entry: There can be the following different types of endpoints:
— authentication endpoint, where subject (3.15) authentication is performed;
— authorization endpoint, where subject authorization is performed;
— endpoint discovery service, that searches for and locates endpoints;
— initial endpoint discovery service, used at the start of subject interactions with an access management system.
Note 2 to entry: Endpoint discovery services are commonly used in distributed and networked systems.
3.6
enterprise centric implementation
access management (3.2) conducted under the control of a policy decision point
3.7
need-to-know
security objective of keeping the subject’s (3.15) access to data resources (3.14) to the minimum necessary
for a requesting user to perform their functions
Note 1 to entry: Need-to-know is authorized at the discretion of the resource owner.
Note 2 to entry: Need-to-have is the security objective of the requester for the fulfilment of specific tasks that may be
limited at the resource owner’s discretion.

© ISO/IEC 2024 – All rights reserved
3.8
privilege
access right
permission
authorization to a subject (3.15) to access a resource (3.14)
Note 1 to entry: Privilege is a necessary but not sufficient condition for access. Access occurs when the access request
is granted according to its access control policy. The access control policy is based on privileges and may include other
environmental factors (e.g. time-of-day, location, etc.)
Note 2 to entry: Privileges take the form of data presented by a subject or obtained for a subject that is used by a policy
decision point in order to grant or deny an operation that a subject is willing to perform on a resource.
Note 3 to entry: A resource may have multiple distinct privileges associated with it which correspond to various
defined levels of access. For example, a data resource could have read, write, execute and delete privileges available
for assignment to subjects. A request by a subject for access to the resource might be allowed for some levels of access
request but disallowed for other levels depending on the level of access requested and the resource privileges that
have been assigned to the subject.
3.9
role
name given to a defined set of system functions that may be performed by multiple entities
Note 1 to entry: The name is usually descriptive of the functionality.
Note 2 to entry: Entities can be but are not necessarily human subjects.
Note 3 to entry: Roles are implemented by a set of privilege (3.8) attributes to provide the necessary access to data
resources or objects.
Note 4 to entry: Subjects assigned to a role inherit the access privileges associated with the role. In operational use,
subjects will need to be authenticated as members of the role group before being allowed to perform the functions of
the role.
3.10
policy decision point
PDP
service that implements an access control policy to adjudicate requests from entities to access resources
(3.14) and provide authorization decisions for use by a policy enforcement point (3.11)
Note 1 to entry: Authorization decisions are used by a policy enforcement point to control access to a resource. An
authorization decision may be communicated through the use of an access token (3.3).
Note 2 to entry: PDP also audits the decisions in an audit trail and is able to trigger alarms.
Note 3 to entry: The term corresponds to access decision function (ADF) in ISO/IEC 10181-3. It is presumed that this
function is located over a network from the subject (3.15) and may be located over a network from the corresponding
policy enforcement point.
3.11
policy enforcement point
PEP
service that enforces the access decision by the policy decision point (3.10)
Note 1 to entry: The PEP receives authorization decisions made by the PDP and implements them in order to control
access by entities to resources (3.14). An authorization decision may be received in the form of an access token (3.3)
presented by a subject (3.15) when an access request is made.
Note 2 to entry: The term corresponds to access enforcement function (AEF) in ISO/IEC 10181-3. It is presumed that
this function is located over a network from the subject and may be located over a network from the corresponding
policy decision point.
© ISO/IEC 2024 – All rights reserved
3.12
policy administration point
PAP
service that administers access authorization policy
3.13
policy information point
PIP
service that acts as the source of attributes (3.4) that are used by a policy decision point (3.10) to make
authorization decisions
Note 1 to entry: Attributes can include resource (3.14), subject (3.15) and environment privileges (3.8)/permissions.
3.14
resource
object
physical, network, or any information asset that can be accessed for use by a subject (3.15)
3.15
subject
entity requesting access to a resource (3.14) controlled by an access control (3.1) system
3.16
security token service
STS
service that builds, signs, exchanges and issues access tokens (3.3) based on decision made by a policy
decision point (3.10)
Note 1 to entry: This service may be split into separate components.
3.17
subject centric implementation
access management (3.2) implemented as component services that are called by a subject (3.15) to acquire
the means recognized by the policy enforcement point (3.11) for accessing a resource (3.14)
Note 1 to entry: Component services may include policy decision point service, policy enforcement point service and
associated discovery services that enable the subject to locate and contact the access control (3.1) services.
4 Abbreviated terms
AA attribute authority
ABAC attribute-based access control
ACL access control list
AM access management
AMS access management system
CBAC capabilities-based access control
DAC discretionary access control
IBAC identity-based access control
ICT information and communication technology
IMS identity management system

© ISO/IEC 2024 – All rights reserved
IT information technology
MAC mandatory access control
PBAC pseudonym-based access control
PAP policy administration point
PEP policy enforcement point
PDP policy decision point
PII personally identifiable information
PIP policy information point
RBAC role-based access control
REDS resource endpoint discovery service
STS security token service
TLS transport layer security
XACML extensible access control markup language
5 Concepts
5.1 A model for controlling access to resources
5.1.1 Overview
The conceptual sequence in giving access to a resource is as follows.
a) Subject authentication is needed before giving access to a resource. However, authentication is a
separate function that is typically implemented on a session basis rather than for each access request.
b) Authorization decision to allow or deny access to the resource is made based on a policy, and an access
token is issued to convey the result of the decision.
c) Authorization enforcement is conducted on the resource based on the decision result and resource
access will be given.
Figure 1 shows this decision sequence.
Figure 1 — Access control model sequence
Subject and resource are depicted as balloons while conceptual functions are depicted as rectangles.
For the purpose of being accessed, a resource is characterized by the following:
— an identifier, either for a specific resource or for a resource class;
— one or more modes of access;

© ISO/IEC 2024 – All rights reserved
— a set of attributes associated with the modes of access and other access criteria as specified in the access
control policy.
An access management system is responsible for the administration and operation of authorizations to
access. Authorizations are supported by administrative activity which assigns and maintains resource
attributes and subject privileges in accordance with the access management policy.
Resources in IT systems are typically dynamic. They run a lifecycle from creation to destruction and this is
a continuous process.
a) Resources have a life-cycle which runs from creation to destruction.
b) Resources are continually being created, updated and destroyed.
c) Resources need to be assigned access attributes (usually at the time of creation) which will be used by
the access management system to control access by subjects to the resources. [Typically this is done by
pre-defining recognized resource types with associated access attribute templates. When a resource of
a known type is created, it inherits the access attributes of the corresponding template].
d) Resources are owned by a party which might be a person or an organization. The owner is often the
creator of the resource but not always and the ownership may change during the life of the resource.
5.1.2 Relationship between identity management system and access management system
In the model described here, the subject is authenticated using an identity management system (IMS), as
described in ISO/IEC 24760-2. The authenticated subject then requests access using the access management
system (AMS). The access management system determines whether or not to authorize the subject request
to access the resource. Subject authorization comprises two distinct activities:
— the pre-assignment of resource access privileges to subjects, and
— the granting of access to resources by subjects in operational use.
Figure 2 shows the relationship between an identity management system and an access management system.
Figure 2 — Identity management system and access management system relationship

© ISO/IEC 2024 – All rights reserved
Authentication is supported by an identity management system. In an access management system using the
IBAC model, identity is the basis for the assignment of resource access privileges to subjects and for the
authorization of resource access requests by subjects in operational use.
NOTE Granting access to a resource can require a minimum stated level of authentication assurance for the subject
which depends on the risk profile of resource. The required level depends on the identity-related risk pertaining to the
resource to be accessed. For further information on authentication level of assurance, see ISO/IEC 29115.
Authorization is provided by the access management system that supports access information management.
Implementation practice for access management systems can vary according to the architecture and the
access control model used, for example:
a) when an AMS is implemented as a Web service system, a subject may request access to a resource
without first being authenticated. In this case, the AMS will direct the subject to request the IMS to
provide authentication, and
b) when an ABAC model is adopted, there is a possibility that the subject does not require any
authentication. In this case, an anonymous entity may be allowed to go directly to the AMS, and an
authorization decision will be made based on a credential that can be validated to prove that the subject
possesses the asserted attributes.
5.1.3 Security characteristics of the access method
Consideration should be given to address the security aspects of access control systems implementation and
processes, particularly where federated architectures are employed.
For security reasons, the integrity of the access request may first require validation before it is further
processed by the access management system.
Where communication channels can be trusted, such as for private connections within an organization,
additional protection may not be needed. However, where communication channels run across public
networks or other unprotected channels, measures to protect the integrity and confidentiality of access
requests and associated data should be provided for both the access request itself (privileges, subject
authentication data, resource, requested operation, etc.) and the data sent to or received from the resource
during the period of access.
There are two approaches to establish a secure communication channel between the subject and the access
management system. The following approaches consider the time at which that secure communication
channel will be established:
a) a secure communication channel may be established before the transmission of the privileges or of the
data that will be used to obtain the privileges [e.g. by the construction of a Transport Layer Security
(TLS) session with the server supporting the resource];
b) a secure communication channel may be established after the successful transmission of the privileges
or of the data that has been used to authenticate an identifier of the subject.
In the latter case, the secure communication channel is established either after a successful authentication
exchange or after the successful acceptance of an access token; the integrity and the confidentiality keys
are derived from the authentication exchange or derived from information contained in the access token
or from information linked to the access token. Then, the transmission of the operation requested on the
resource can be made through that secure communication channel.
5.2 Relationships between logical and physical access control
This document mainly focuses on logical access control. Logical access control is supported by physical
access control.
Logical access to a resource in an enterprise system should be supported by a secure physical infrastructure
which provides an effective set of controls and actions that cannot be subverted.

© ISO/IEC 2024 – All rights reserved
For logical access to a resource hosted by an outsourced service, the outsourced service should be
accountable for its physical and logical access control so that it can be trusted by the subject.
5.3 Access management system functions and processes
5.3.1 Overview
An access management system enforces an access control policy and provides two core operational
functions:
a) to assign resource access privileges to subjects in advance of operational use; alternatively, to assign
access privileges to attributes (as in the ABAC model) and then assign attributes to subjects who inherit
the associated access privileges;
b) to use these privileges (together with other information where appropriate) to control subject access to
system resources in operational use.
In addition, an AMS provides administrative functions to support the core functions, including:
— policy management;
— policy-related access attribute management;
— monitoring and record keeping management.
Resource access policy should implement the following principles:
a) setting access attributes on a “need-to-know” basis;
b) minimalizing data access in order to restrict access to only strictly required data and minimize data
leakage and disclosure risk;
c) segregating and protecting of sensitive data;
d) protecting of PII;
e) using multifactor authentication based on the criticality and sensitivity of resource accessed.
5.3.2 Access control policy
An access management system enforces an access control policy. A number of access control models exist
(see Annex A). This document focuses on the following models which are sufficiently flexible to be suitable
for use in both centralized and distributed network environments:
— identity-based access control (IBAC) model;
— role-based access control (RBAC) model;
— attribute-based access control (ABAC) model.
Access control policy should be described in natural language or another suitable representation, e.g. a
formal language, to express the objectives for the control of access to resources, the methods and processes
for exercising the control, and any requirements for monitoring, auditing and other non-core functions.
There may be multiple access control policies within an organization. Typically, a group of resources on one
technology may be accessed under the control of a decision point responding to one policy, while access to
another group of resources developed with a different technology will be managed under a different decision
point responding to a second access control policy. Both decision points may also respond to the same access
control policy, which is recommended.
Where multiple access control systems operate within an organization and they are to be integrated into a
single system, policy differences should be reconciled and a common access control policy developed and

© ISO/IEC 2024 – All rights reserved
documented. An alternate approach can be to integrate the systems as an intra-organization federation, in
which case, the considerations and requirements described in 5.3.8 shall be applicable.
Access control is provided through mechanisms for granting or denying operations to be performed on
resources based on an access control policy.
Authorization decisions are made based on the evaluation of subject privileges and attributes against access
rules set out for the relevant resource. Rules can also include environmental attributes such as time of
day and location from which the request is made. For example, no operation can be done on the resource
between 9:00 p.m. and 7:00 a.m.
If a mandatory access control (MAC) model applies, a rule will necessarily be global to a set of resources. For
example, subjects should be cleared to “Top Secret” for any operation that they would like to perform on a
given set of resources.
NOTE As multiple rules can be applied sequentially, the order of application can affect the efficiency of the
decision process. However, the optimum ordering will depend on the relative likelihood of grant/deny access decisions
in operational use.
In general, individual rules may be implemented by means of an access control matrix associated with each
resource which contains one or more entries.
Each entry will indicate the condition(s) that a subject shall fulfil in order to perform one or more operations
on the resource. The major condition to fulfil is that the subject shall possess some privilege(s).
ABAC is the common situation where access control is based on AMS defined attributes possessed by
subjects. IBAC model, a similar IBAC model called pseudonym-based access control (PBAC) model, and RBAC
model are particular cases of ABAC where the attributes are, respectively, an identity, a pseudonymous
identity, and a role. These four models may be implemented using ACLs.
When the subject presents a capability ticket for authorization (also referred as a capability-based access
control (CBAC) model), it is necessary to verify that the capability ticket as an access token is effective for
that operation.
In access management systems that embody more than one access model, care should be taken to ensure
that policies specifying access to resources by subjects do not result in conflicting access decisions for the
same subject via different paths: a policy administration point should be able to manage various models of
ABAC, IBAC, PBAC, RBAC, or CBAC.
An access control policy should have the following characteristics:
a) be based on policy requirements common to required models in place, to protect information to meet
business requirements and for reasons of legal and regulatory compliance and intellectual property;
b) contain a policy hierarchy, based upon the common policy, from which access control rules applying to
individuals with same characteristics may be defined;
c) describe the attributes supporting a defined classification. This categorization will enable policy
interoperability and compliance across organizations;
d) describe procedures for the provisioning and management of privileges, the access control process and
exception handling.
5.3.3 Privilege management
The requirements for privilege management are defined by the access control policy as mentioned in 5.3.2.
Under identity-based access control policy, privilege management is conducted on the basis of subject
identity. IBAC policy employs mechanisms such as access control lists (ACLs) to specify the identities of those
allowed to access a resource and the types of operation on the resource that they are allowed to perform.
In the IBAC model, the granting of resource access privileges to a subject is made prior to any subject access
request, and subject identity and access privileges are added to the relevant resource ACL(s).

© ISO/IEC 2024 – All rights reserved
If an authenticated subject identity matches an identity recorded in the relevant ACL, the subject is given
access to the resource in accordance with its access privileges. Each resource has an associated ACL in which
the access privileges for the subjects that are authorized to access the resource are recorded. In the IBAC
model, the authorization decisions are made prior to any specific access request and result in the subject
and the subject access privileges being added to the relevant resource ACL(s).
In the RBAC model, a role (or roles) is assigned to each subject and is recorded in the account for the subject.
Authorization decisions are made based on the access privileges assigned to the relevant role within the
access management system. In an RBAC model, the privileges are assigned to roles not subjects. A separate
activity assigns roles to subjects. This also affects the authorization process when requesting access to
resources that is a two-step process in an RBAC model:
— authorize the access request for the role;
— authenticate the subject to be a member of the role group.
Under the ABAC model, policy-related access attributes are assigned to subjects. Authorization decisions are
based on the attributes possessed by subjects.
A subject may access resources as a member of a group, the possessor of attributes or as an individual. Role-
based, attribute-based and identity-based access control schemes can exist concurrently in an access control
system.
Privilege management comprises the following activities:
a) creating the set of privileges to be used to denote and limit the types of operation that may be performed
on resources;
b) establishing the rules specifying the assignment of privileges in accordance with the access control
policy and the access control model employed, e.g. assignment to identities, roles, capabilities or other
defined attributes;
c) the update and revocation of privileges and identity attributes.
The implementation of access control policy results from the assignment of resource access privileges to
subjects, roles, groups, etc. Privileges should be assigned on a “need-to-know” basis, granting the lowest
level of privilege consistent with the subject being able to perform the relevant activity.
NOTE Privileges can be assigned to both human subjects and non-human subjects. For example, when a device or
a service is added to a network, it can be assigned resource access privileges.
5.3.4 Policy-related attribute information management
Management of information for setting of privileges to attributes is an administrative activity as illustrated
in Figure 5.
This kind of information is:
a) obtained from various sources including attribute authorities, resources and the environment;
b) managed through the policy administration point (PAP);
c) stored in the policy information point (PIP).
The resulting information is made available to the policy decision point (PDP) to control access to resources.
Attribute information is managed within an AMS in accordance with the access control policy described
previously.
In the case of an ABAC model, the policy is formulated in terms of the attributes that are used to govern
access to resources and how the attributes are mapped to resource access privileges. For an RBAC model,
the policy specifies how the resource access privileges are assigned to the various roles.

© ISO/IEC 2024 – All rights reserved
Under a DAC policy, attributes are managed by resource owners, while under a MAC policy, additional
attributes are managed by policy officers.
The PBAC model employs mechanisms such as ACLs which contain the pseudonyms of the subjects permitted
to access the resource, together with the subject access permissions for the resource. If a subject presents a
pseudonym that matches one held in the ACL, the subject may be given the right to perform the operation on
the resource, subject to its permissions and any other checks that may apply.
The IBAC model employs a similar mechanism where identities are used rather
...