Where does the OCAP approach for authorization meet current standards for web applications for authentication and authorization?
I am planning on reimplementing my SaaS product, set aside some mistakes, build it better yada yada. It is an IoT product so I have been looking for ways to encode commands that could be generated from the cloud and sent to the device and have the device take some action. Some simple example like reboot(). My device’s WiFi firmware might corrupt or have some other transient issue and I want to be able to send someone to the device and reboot it, but only reboot it. Seems like a classic capabilities use case. So I have planned to include ses.js into the design of the application.
But that is a bottom up approach, what happens when you work from the top down. I am looking at deploying some prebuilt IAM service using OAUTH2, OIDC, etc, why reinvent the wheel when others have done a fine job. So my IAM service will manage users, they’ll login with user name and password, and then they’ll will want to reboot the device remotely. Well I need to grant the user permission to do that, using something like XACML (acl on steroids?) to do attribute based access control. Eventually they’ll call an API on my resource server to say reboot this device. In order to grant authorization to that capability my resource server needs to go back to the authorization server and ask, can this requesting party take this action on this resource and have it evaluate some complex policy to determine if the request is authorized. But that sounds very much like an ACL approach and very contrary to a capabilities approach.
Have you guys had any thoughts about this, is there a nice seam where a capabilities based device system can meet an ACL style IAM service?