Achieving authentication on a public OM2M-IN [message #1780436] |
Mon, 22 January 2018 12:37 |
Steffen Thielemans Messages: 1 Registered: January 2018 |
Junior Member |
|
|
In the oneM2M specification (TS-0003) Access Control Policies (ACP) are designed to authorize; they are not designed to provide any means of authentication. As far as we know there is currently no real form of authentication in OM2M (the username:password combination just links to an ACP). We would like to include authentication on our publicly available OM2M-IN on top of the HTTPS binding (other bindings are disabled). What are the possibilities? So far we have considered these solutions:
- Obfuscate/randomize the ACPs. We are currently doing this for the admin ACP but are not convinced this is the way to go while we keep adding new AEs and ACPs and give project partners access to this server. It is simply not designed for authentication purposes.
- We are currently looking into client certificates for authentication purposes. Authentication would work well in this way but will be cumbersome to deploy on the clients, or might not be supported on some clients at all. Is there any way to link certain client certificates with one or multiple ACP originators? I suppose client certificate verification has to be enabled/implemented on the Jetty server? How???
- In case client certificates are not supported by all clients we could fall back on Basic Authentication on top of the HTTPS binding. Would this be useful as it is similar to the X-M2M-Originator header used by the ACP? We know how to achieve basic authentication on a normal Jetty server but are struggling to achieve this on top of the Equinox bundled Jetty server and require assistance. Alternatively this could probably be implemented in the OM2M RestHttpServlet service function.
Which solution should be preferred to achieve authentication, and how feasible is it to integrate it into the oneM2M system?
|
|
|
Powered by
FUDForum. Page generated in 0.02937 seconds