OCAP vs ACL and evolving auth* standards

[Dodtsair]

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?

[tristan.slominski]

Howdy,

I had a similar problem and have over time built up requisite infrastructure in order to be able to do something of the sort you describe. I believe you’re missing two abstractions, the “revokable membrane”, and the “powerbox”.

The revokable membrane allows you to group capabilities together into bundles, and revoke them all at once when needed. To grant a user permissions, you’d create a membrane for that user, and then you’d export your root capabilities through that membrane, giving the user the resultant separate capabilities. When the user access is to be revoked, you’d revoke the appropriate membrane.

The powerbox manages capabilities on behalf of the user and provides an interface between principal and the capabilities they posses. This is also the abstraction that authenticates the prinicipal in order to give them access to capabilities they posses.

I built a Membrane Service to provide the revokable membrane abstraction as-a-service. Here’s a specific writeup on how to use membranes for something like account management. Additionally, the powerbox abstraction as-a-service is in progress, but documentation is not yet written, although the authentication entry point to the powerbox is available via the various Log In to the Console links in the membrane docs.

[Dodtsair]

I have been thinking this over and I see two undesirable side effects each affecting either powerbox or membranes.

For powerbox, assuming I use some oauth 2.0 service to login, the next thing I do is call my API endpoint with the bearer token, to get the powerbox capability. The powerbox is capable of creating other capabilities, so the next API call would be directed at the powerbox and requesting for the capability to reboot a particular device. Once I receive that capability from the powerbox I can make a third API call to that capability to actually reboot the device. This means for rebooting a device I must make three different calls, first to get the powerbox, second to use the powerbox to request the capability to reboot, third to the reboot capability to actually reboot the device.

For membrane, the application is going to have a lot of devices, and a lot of capabilities associated with those devices. I need to collect all these capabilities together and add them to the membrane. That itself would be a lot of work, but I would expect for each of these capabilities I would need to create a new capability that self-expires or that I can revoke when I revoke the membrane. That means every login I am creating a lot of capabilities that are not going to be used.

Am I understanding a membrane and a powerbox would be used?

[tristan.slominski]

Hopefully this helps a bit:

Initial Setup

Example of Admin rebooting or delegating to User the reboot capability:

With the above protocols in mind…

In the way I use it, powerbox isn’t so much the creator of capabilities but a secure storage for them. That means, capabilities have to exist prior to being put into the powerbox. So, the usual flow to reboot would be 1) log in 2) retrieve the reboot capability for the device you want 3) invoke reboot. Initial setup would be required to create and store all the reboot capabilities in the first place, as you correctly point out, this is a bit of work.

For the membrane, yes, lots of capabilities have to be collected and exported through the membrane. However, this need not happen on every log in. It only happens when the admin decides to delegate authority to the user, at that point, /user1 membrane would be created and capabilities delegated.

User1 does not need to use the powerbox and could store the delegated capabilities however they want. But, if they were to use the Powerbox, then their flow would be similar to the admin 1) log in 2) retrieve the reboot capability for the device they want 3) invoke reboot. This should work until the time the admin revokes the membrane (which could be on a timer, or otherwise).