Skip to content

Access Control Polices

oneM2M defines several access control mechanisms to control access of oneM2M resources.

This article provides a basic overview of Access Control Polices based access control mechanisms in oneM2M. It provides details about the oneM2M resource type <accessControlPolicy>, its attributes, its linking with other resources and an example to explain how these policies are checked for access control.

What are the access control policies in oneM2M?

oneM2M defines <accessControlPolicy> resource for defining and managing access control for oneM2M resources. These policies can be created under <CSEBase>, <AE>, <remoteCSE> resources. These policies, when linked to a resource, are used for making access decision for that resource.

These policies contain Access Control Rules which define

  • who (via the attribute accessControlOriginators or acor) is authorized to access the resources,
  • what operations (via the attribute accessControlOperations or acop) are allowed on resources, for example CREATE, RETRIEVE, DISCOVER,
  • what attributes of resources can be accessed (via the accessControlAttributes or aca), and
  • under which conditions (via the attribute accessControlContexts or acco) access is allowed for operating on oneM2M resources, for example for time, location, IP address, and limits.

Each Access Control Rule contain privileges and selfPrivileges attributes as depicted in the figure below (for simplicity only who and what is shown):

AccessControlPolicies-Privileges and selfPrivileges

Figure 1: AccessControlPolicies-Privileges and selfPrivileges
  • privileges in an <accessControlPolicy> resource define the Access Control Rules for resources other than accessControlPolicy resource.
  • selfPrivileges in an <accessControlPolicy> resource define the Access Control Rules for the <accessControlPolicy> resource itself. It is used to protect from unauthorized modification of the access control policy.

Access Control Policy linking

<accessControlPolicy> resources can be linked to other oneM2M resources using the accessControlPolicyIDs (ACPI) attribute in those other resources. This is depicted in figure below:

Resource linking with Access Control Policy

Figure 2: Resource linking with Access Control Policy

Access Control Policy checks

How access control policies are checked is depicted in the figure below:

Access Control Policy check

Figure 3: Access Control Policy check

When a request to a resource is sent then the following sequence occurs at the CSE:

  1. Get the ACPI attribute associated with the targeted resource.
  2. Find the <accessControlPolicy> (ACP) resource(s) corresponding to this ACPI attribute.
  3. Check if the originator is present in the accessControlOriginators of any of Access Control Ruls (ACR) in the ACP resource(s).
  4. Check if the request operation is present in the accessControlOperations of the ACR.
  5. When both the conditions are matched then access to the resource is granted to the originator and for the operation requested.
  6. When any of the conditions do not matched then resource access is not granted to the originator, and an error response is given to the originator with status code "4103 (ORIGINATOR_HAS_NO_PRIVILEGE)".

For cases when the ACPI attribute is not present in a target resource, please refer to Access Control Mechanisms in oneM2M for other access control mechanisms.

More features of AccessControlPolicies

It is important to note that there are more complex features support by oneM2M's access control. Examples are control over what child resources can be created, what attributes of a resource can be accessed etc. These concepts wiil be covered in more Advanced articles.

by Poornima Shandilya, 2024-06-09