We started to implement the security part of OneM2M and we set about implementing Access Control Policy(ACP) first. While we are investigating the oneM2M example of the Access Control Policy, we see that the privileges (PV) and self privileges (PVS) can be any originator which can be any Application Entity (AE) or Common Service Entity(CSE).
In a privilege, each access control rule defines which AE/CSE is allowed for which operation. So for sets of access control rules an operation is permitted if it is permitted by one or more access control rules in the set.
TS-0001 v3.12.0 | Ln 3432-3433
After that, we also looked at the Eclipse version of the OneM2M implementation and run the application for each CSEs (IN-CSE & MN-CSE). A web interface welcomes you with a login screen and waits for a username and password. Then the weird part comes up. After we did a successful login, the entered username & password seems to be used as originator for the resources that we want to access. In addition to this, also a test user has been also added to the default ACP.
The example ACP is taken from a eclipse forum's thread.
<m2m:acp xmlns:m2m="http://www.onem2m.org/xml/protocols">
<pv>
<acr>
<acor>admin:admin</acor>
<acop>63</acop>
</acr>
<acr>
<acor>test</acor>
<acop>34</acop>
</acr>
</pv>
<pvs>
<acr>
<acor>admin:admin</acor>
<acop>63</acop>
</acr>
</pvs>
</m2m:acp>
The question is, is it suitable to put some kind of username & password logic to the ACP itself ? Whatever it is, I understand the necessity of that kind of usage. But I am not sure it is the right way to do that in OneM2M.
Assume that we have an AE that has a web interface and used by many users. So each user has different privileges for accessing the other resources in OneM2M, but the access control policies only have originators that can be any AE/CSE and not users. How to implement this kind of scenario ?
Related question is from the OneM2M website
The Cgateway_ae (It seems to be the MN-AE) sends an ACP create request to the MN-CSE. But where the permission comes from for the MN-AE to create a ACP to the MN-CSE. Somehow it should be created before it wants to create another ACP ?
Who has the responsibility to create that ACP ? How that responsible party will know the related AE-ID/CSE-ID even before it is created.
POST /home_gateway?rcn=0 HTTP/1.1
Host: mn.provider.com:8080
X-M2M-Origin: Cgateway_ae
Content-Type: application/vnd.onem2m-res+xml; ty=1
X-M2M-RI: mncse-62948
<m2m:acp xmlns:m2m="http://www.onem2m.org/xml/protocols" rn="MN-CSEAcp">
<pv>
<acr>
<acor>Cgateway_ae Clight_ae1 Clight_ae2 /in-cse/Csmartphone_ae</acor>
<acop>63</acop>
</acr>
</pv>
<pvs>
<acr>
<acor>Cgateway_ae</acor>
<acop>51</acop>
</acr>
</pvs>
</m2m:acp>
------------------ EDITED ---------------------------
This is a really good document.
http://www.onem2m.org/tr-0038/procedures/authorization/configuration-of-accesscontrolpolicy
The Eclipse om2m implementation brings its own integrated web UI that has a special handling of the access control originator (acor). If the acor contains a ":" character, then the originator is split into a username/password combination for the UI. As far as I know it still regards the access policies that are defined for that user in the <ACP> resources. And, as shown in the example, a single <ACP> resource can support more than one originator. The Eclipse om2m implementation might not fully compliant when allowing this format.
See TS-0001 chapter "10.2.2.2 Create <AE>". This explains how this identifier is created (by the CSE). After reading this, it becomes much clearer when, in the oneM2M examples, the AE-ID's start with a 'C' or an 'S'. Also check in TS-0001 chapter "7.2 M2M-SP-ID, CSE-ID, App-ID and AE-ID and resource Identifier formats" for further details on the identifier format.
A CSE should always have a kind of "root" originator together with a privileged <ACP> that allows management AE's to perform management functions. Without an <AE> this could be the CSE-ID. For Eclipse om2m this would be the "admin:admin" originator. With this originator a management AE can add further <ACP>'s and originators with lesser privileges for other AE's. Please note, that this kind of user/identity/access management is usually part of the business logic and not part of oneM2M.
Is it sufficiently secure? As always, this depends. Many IoT systems assign a "secret" token to a device to authenticate a connection request. But keep in mind that the originator identifier always comes from an AE that must have successfully registered with the CSE in the first place and is therefore trusted.
To the second part of the question: in the example from the oneM2M website there must be an <ACP> that allows the originator "Cgateway_ae" to CREATE a new <ACP> resource under the resource path "/home_gateway" (the MN-CSE in the example). This <ACP> seems to be missing in the example, but the gateway AE that registers the new <ACP> resource to grant the other AE's the access rights must have the privileges to do so. This can be done either by pre-shared originator authentication information (such as a smart card or similar mechanisms), or another way of distribution of the originator information (e.g. the exchange of a file when the AE is actually running together with the CSE in a secure and trusted environment).
(Updated according to discussion)