The present document specifies access control for management services.

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

• References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

Identity and Access Control Network Management systems are becoming a challenge to manage in terms of the users of the system as well as the access control that needs to be applied continuously on a need-to-know basis. Flexibility and agility to adapt to these growing needs is the key for a sustainable identity and access control implementation. The service based architecture needs to factor seamless integration to any system for authentication and authorization of Management Service (MnS) consumers. The need to make continuous access control related changes should be supported with ease and simplicity. Today there are various human users, machine users and various resources that are continuously growing with complexities below:

• Human users seem to require various levels of access control.
• Machine type of communication in the direction towards automated systems require another type of access and may not necessarily be user name password based.
• Resources and modules themselves require various level of clearance depending on the sensitivity of the data being accessed.

The identity and access control system should be designed for role based access control. Also the authorization rules may support the fine grained permissions i.e. based on MnS component A, B and C. Role based access control This is based upon the concept of assigning the appropriate permissions and privileges to authorized users. The combinations of the permissions and privileges make up a role. The users who belong to a role should be assigned to resources based on a least privilege principle and access rules associated to the resource. The principle of least privileges states that the users should be granted access only to the data and the operations that are required to perform the job. This minimizes the possibility of a security breach. The management system should be setup for access control by a system administrator who will have the know-how of creating the required users and roles. Roles will use the various access rules. Additionally, the system administrator will also need to setup the access rules for a MnS producer. Roles could be in various categories like full access and restricted access.

The Figure 4-1 shows how a user is assigned to a role. The roles in turn are able to act upon a resource with the required operation on a MnS Producer. The operations that can be performed are defined by the access rules. The Figure 4-2 shows an example of how role based access control is adapted to service based management architecture. In the service based management architecture, the user is regarded as MnS consumer, and the combination of resource and operation is represented by management services. Different MnS consumers can be assigned to one role or different roles. The access rules for roles will be configured according to the MnS consumer access right of management service instances which are composed by different MnS component A and component B or component C.

MnS consumers belonging to different domains (e.g. NOP domain and Vertical domain) are assigned to different roles respectively. For each role, there is an associated access rule list which shows the allowed accessing scope of MnSs. MnS 1, MnS 2 and MnS 3 are different with each other in at least one of the component A, component B and component C. Entities in access control In a distributed system the responsibilities of authentication and authorization is split between several entities (Figure 4-3):

The Figure 4-3 shows the various entities that need to be involved in setting up and using access control. Irrespective of any implementation and functional split, the concept of access control is based on the following steps:

• The resource server needs to relate to the request coming from the user to a known identity
• The resource server needs to relate to the request coming from the user to resource, which in case of SBMA means a combination of MnS components as defined in TS 28.533, i.e. MnS operations (component A), object instances or classes from the NRMs (component B), and alarm information or performance data (component C).
• The resource server needs to check whether the requesting identity is allowed to perform the requested operation on the requested resources. These checks can be assigned to a functional block for authentication and a block for authorization, no matter whether these functional blocks are internal parts of a management function (e.g. as part of a Netconf server) or whether these blocks are visible as standalone services (e.g. like a dedicated OAuth authorization server).
• As precondition for any access control and irrespective of any implementation or deployment, the owner of the resources needs to configure these functional blocks in order to define which identity is allowed to access which resources.

Access control is highly specific to the solution set, the protocol and the CRUD operations defined by the solution underlying the solution set. For example, oAUTH offers the possibility of the authentication and authorization function integrated and Netconf has the possibility of authentication taking place separately on the transport layer and the authorization separately on the Netconf server. Netconf will use standardized RFC 8341 Network Configuration Access Control Model (NACM). REST solutions with OpenAPI will use OAUTH2.0. The different entities need to have a common notion of the security-related parameters. E.g. Authentication and authorization function and potential user need to use the same notion of identity, as well as authentication and authorization function and potential resource server need to use the same notion of resource. Therefore the involved entities need to be based on an overarching security-related information model (explained in next clause related to Information Model), which is the basis for the concrete data models of the security-related interfaces that are needed to fulfil the security-related use cases of access control Use case: authentication and authorization Authorization function and resource server need to have a common understanding of resources and refer to the same resources and corresponding actions. The access control information needs to be provisioned in the authentication and authorization function. To carry out authentication and authorization based on role-based access the following tasks needs to be in place. Pre-deployment task - This relates to the identification of the resources represented by the MnS component B and C and it associated operations represented by MnS component A. This is typically done by a Network Equipment Provider (NEP) during the design phase. Post deployment task - this relates to the set of administrative tasks which are requires to enable role-based access control typically caried out by a network operator (NOP). This is done once the system is up and running and access control needs to be administered. Post the above tasks there is the possibility to have role-based access in operation with every service call being authenticated and authorized. When an MnS is invoked, the MnS consumer authenticates towards an authentication service producer. This is then followed by checking the access rights with respect to the role-based access. This takes place in the authorization service producer which is invoked from the MnS producer to check if its resources can be accessed with respect to the related operation. Use case: identity to roles association The identity or user of the system needs to be assigned the permissions to carry out the management operations. A set of permissions is defined as a role. An efficient and flexible means is to define various roles by a network operator. In a second step, association of the roles to an identity (entity or human user) is carried out. Roles associated to resources (consisting of IOCs, MOIs and corresponding operations) Role-based access control defines roles. Roles are associated to access rules which are combinations of resources and operations (e.g., CRUD operations). The resources can be represented by IOCs(static) and/or MOIs (dynamic). Hence the resources in context are typically Component B and the operations are Component A. Component C which represents that management data is also a possible resource to be access control protected. The present TS specifies the information model allowing to configure access control rules into the system. Access control for CRUD operations, notifications and performance metrics is covered.