Access Control

As the LWM2M Client MAY support one or more LWM2M Servers, there is a need to determine which operation on a given Object Instance is authorized for which LWM2M Server: Access Control Object is designed for supporting that capability

In the particular case where a single LWM2M Server Account exists in the LWM2M Client, the Server MUST have full access right on all the Object Instances in the LWM2M Client, and the Access Control Object MAY be not instantiated. As a consequence the section 7.3.1 and its sub-sections MUST be used in multiple LWM2M Servers environment but can be supported in single LWM2M Server environment, for reducing the efforts for the LWM2M Client when switching from single to multiple LWM2M Servers environment after deployment.

Access Control Object

Access Control Object overview

Access Control Object MUST be instantiated with the following rules:

• A unique Access Control Object Instance is assigned per Object Instance (see Figure 15 ), for registering which operations can be performed by a given LWM2M Server on this associated Object Instance.
• Each Access Control Object Instance MUST only be managed by the Access Control Owner Server of that Object Instance via the Device Management and Service Enablement Interface. Within the Access Control Object Instance is an ACL Resource which MAY have zero or several Instances (see Figure 15 ):
  • Each ACL Resource Instance is associated to a different LWM2M Server and represents an access right determining which operations a LWM2M Server can perform on the Object Instance.
  • For a given Access Control Object Instance, the Access Control Owner LWM2M Server which doesn’t have ACL Resource Instance, have full access right on Object Instance it refers to.
  • For a simple association between an ACL Resource Instance and a given LWM2M Server, the Short Server ID is assigned to ACL Resource Instance ID (see Figure 15 ).
  • A default ACL Resource Instance MAY be used to grant access rights to LWM2M Servers which doesn’t have its own ACL Resource Instance. ID of this default ACL Resource Instance MUST be 0.
• Access Control Object is described in Appendix E.3 and Examples of Access Control Object Instances are presented in Appendix F.

Figure 16: Illustration of the relations between the LWM2M Access Control Object and the other LWM2M Objects

Access Control Object Management

• • • • 1. Access Control Object Instantiation

Access Control Object MUST be instantiated by the LWM2M Client under two circumstances:

• During Bootstrap for specifying which Server is authorized to instantiate (“Create” operation) which Object.

• When a LWM2M Server sends “Create” operation.

• Bootstrap case

During Bootstrap, for each Object supported by the LWM2M Client, an Access Control Object Instance per Object SHOULD be created by the LWM2M Client. This Access Control Object Instance MUST be managed via the Bootstrap Interface only. The Resources value of the Access Control Object MUST be set as follows:

1. “Create” operation case

When a LWM2M Server sends “Create” operation on a certain Object Instance and is authorized to create that Object Instance (see section 7.3.2 Authorization) in the LWM2M Client, the LWM2M Client MUST instantiate an Access Control Object Instance with the following Resource values. The Access Control Owner Resource is configured with Short Server ID of the LWM2M Server.

• • • • 1. Access Control Object update

There are several cases in which a given Access Control Object Instance can be updated:

• When the LWM2M Server which is the “Access Control Owner” adds or modifies (using “Write” operation) access right on the Object Instance for a given LWM2M Server,
  1. first an ACL Resource having the targeted Short Server ID as ACL Resource Instance ID, has to be instantiated by the LWM2M Client if ACL Resource Instance for the LWM2M Server doesn’t exist yet
  2. second: the appropriate access right (R,W,D,E) for that targeted Server on the Object Instance has to be set as ACL Resource Instance value
• When an Object Instance is removed via “Delete” operation performed by the LWM2M Server which is the “Access Control Owner”, the associated Access Control Object Instance MUST be removed by the LWM2M Client.

Authorization

The LWM2M Client MUST authorize operations requested by a LWM2M Server either on an Object Instance, or on Resource after performing a two-steps check:

• 1^st step: the LWM2M Client gets the access right of the targeted Object Instance (as described in section 7.3.2.1) - and checks whether this access right is sufficient for performing the LWM2M Server requested operation.
• 2^nd step: if at step 1, the Server is granted to perform the operation the LWM2M Client needs to check if the LWM2M Server requested operation is supported by the targeted Resource or Object Instance (details are described in section 7.3.2.2, 7.3.2.3, and 7.3.2.4).

The LWM2M Object specification defines which operations are allowed to be performed on Resource within an Object Instance (Refer to Supported Operations in Appendix C LWM2M Object Template and Guidelines). The operations allowed on a given Resource MUST apply to all the Resource Instances of that Resource.

The LWM2M Client MUST support the authorization procedure described in Section 7.3.2 and its sub-sections.

Obtaining Access Right

For “Create” operation on an Object Instance sent from the LWM2M Server, the LWM2M Client MUST obtain access right by either way

• If this LWM2M Server is the only LWM2M Server Account declared in the LWM2M Client (ie single Server environment), the LWM2M Server has full access right.
• If the LWM2M Client has more than one LWM2M Server Account, then the LWM2M Client has to get access right from the ACL Resource Instance associated to this LWM2M Server on that Object Instance, which is contained in the Access Control Object Instance provisioned during Bootstrap (Access Control Owner is MAX_ID=65535). If this access right doesn’t have the “Create” value, or cannot be obtained, the LWM2M Server has no access right.

For the operations except than “Create” operation the LWM2M Client MUST perform the following procedure:

1. if this LWM2M Server is the only LWM2M Server Account declared in the LWM2M Client (ie single Server environment) , the LWM2M Server has full access right If the LWM2M Server has more than one LWM2M Server Account, the LWM2M Client gets an Access Control Object Instance associated with the Object Instance the LWM2M Server has requested access to and MUST follow the procedure below:
   1. If the LWM2M Server is declared as Access Control Owner of this Object Instance and there is no ACL Resource Instance, then LWM2M Client gets full access right.
   2. If the Client has an ACL Resource Instance for the LWM2M Server, the LWM2M Client gets access right from that ACL Resource Instance.
   3. If the Client doesn’t have ACL Resource Instance for the Server, the LWM2M Client gets access right from the default ACL Resource Instance if it exists.
   4. If the Client doesn’t have default ACL Resource Instance then, the LWM2M Server has no access right, and an “Access Right Permission Denied” error code is reported to the LWM2M Server.

Operation on Resource

When the LWM2M Server accesses a Resource, the LWM2M Client MUST obtain an access right for the LWM2M Server on the Object Instance that Resource belongs to according to Section 7.3.2.1 and MUST checks whether the access right is granted prior to perform the requested operation.

• If the operation is not permitted, the LWM2M Client MUST send an “Access Right Permission Denied” error code to the LWM2M Server.
• If the operation is permitted, the LWM2M Client verifies whether the Resource supports the operation.
• If the operation is not supported by the Resource, the LWM2M Client MUST send an “Operation is not supported” error code to the LWM2M Server.
• If the Resource supports the operation, the LWM2M Client MUST performs the requested operation.

Operation on Object Instance

When the LWM2M Server accesses an Object Instance, the LWM2M Client MUST obtain an access right for the LWM2M Server on Object Instance according to Section 7.3.2.1 and MUST check whether the access right is granted prior to perform the requested operation.

• If the operation is not permitted, the LWM2M Client MUST send an “Access Right Permission Denied” error code to the LWM2M Server.
• If the operation is permitted, the following cases apply, according to the requested operation:
• For the “Write” operation on an Object Instance, the LWM2M Client MUST perform the operation, if all the Resources conveyed in the operation are allowed to perform the “Write” operation. If any Resource does not support the “Write”operation, the LWM2M Client MUST inform the LWM2M Server, the Object Instance doesn’t perform the requested “Write” operation by sending a “Operation is not supported” error code.
• For the “Read” operation, the LWM2M Client MUST retrieve all the Resources except the Resource(s) which doesn’t support the “Read” operation and sends the retrieved Resource(s) information to the LWM2M Server.
• For the “Execute” operation, the LWM2M Client MUST NOT perform the operation, and MUST send an “Operation is not supported” error code to the LWM2M Server.
• For the “Create” operation, the LWM2M Client MUST perform the operation on the Object Instance only if all the Resources conveyed in the operation are writable and all the mandatory Resources are specified. If any conveyed Resource does not support the “Write” operation, the LWM2M Client MUST inform the LWM2M Server it doesn’t support the operation by sending “Operation is not supported” error code. If all the mandatory Resources are not specified, the LWM2M Client MUST send an “Bad Request” error code to the LWM2M Server.
• For the “Delete”, “Observe”, “Write Attributes”, and “Discover” operations, the LWM2M Client MUST perform the operation since those operations have no effect on the Resource.

Operation on Object

If a given LWM2M Server sends “Write” or “Execute” operation, the LWM2M Client MUST NOT perform such an operation and MUST send an “Operation is not supported” error code to the LWM2M Server.

• Authorizing “Create” operation on Object is no more than Authorizing “Create” operation on anObject Instance so the rules specified for the Create on Object Instance in section 7.3.2.3 apply for this operation.
• The “Discover” operation on Object is specific in the sense, that no access right is needed; the LWM2M Client MUST perform the operation.
• For the “Read” operation, the LWM2M Client MUST obtain the access right for the LWM2M Server on each Object Instance according to Section 7.3.2.1 Obtaining Access Right and the LWM2M Client MUST retrieve all the Object Instances for which the LWM2M Server has “Read” access right; for each of these qualified Object Instances, the LWM2M Client MUST retrieve all the Resources except the Resources which do not support the “Read” operation. The LWM2M Client MUST then aggregate all the information individually produced by the operation on each of these Object Instances and send that to the LWM2M Server.
• For the “Observe” or “Write Attributes” operation, the LWM2M Client MUST perform the operation.

Notify Operation Consideration

If the LWM2M Client needs to send a “Notify” operation containing an Object Instance or a Resource to the LWM2M Server, the LWM2M Client MUST check whether the LWM2M Server is authorized for the “Read” operation. If the LWM2M Server is not authorized, the Client MUST NOT send the “Notify” operation.