Specify for a variety of authorisation mechanisms

[vanrein]

The RemoteStorage 01 spec describes sessions with a strict dependency on one particular authorisation mechanism, OAuth2's Implicit Grants. Such a directed choice should either be loosened or explained, I think. There may be solid reasons to make a deliberate choice based on the problem domain at hand -- but none I can think of.

One specific form of authorisation that is not supported (but ought to be, I think) is authorisation in the backend, away from the web sphere. If we want RemoteStorage provided by various parties across the Internet, as well as do it ourselves and see network administrators run services for it, then we should give them a way to circumvent the security hazards and added delays of hopping from one secure website to another.

To spell it out: The OAuth model centralises computation stress on server-side TLS, it decentralises credentials, decentralises credential caching and introduces multiple parties who need to do a lot of talking and verifying each other. It is not ideal ;-) and specifically in many situations where we would like to see RemoteStorage, it is likely that administrators don't want this overhead on top of relatively light storage services.

An obvious alternative approach would be to stick to filesystem permissions, or ACLs which may or may not be centrally managed in a directory. This gives more reliable policy enforcement, it adds no overhead relative to file systems, and the only added responsibilities for supporting RemoteStorage is authenticated HTTP. Depending on the local situation and personal preference, this may not even require TLS.

Imagine how simple it then becomes to serve RemoteStorage on a trusted local network: Simply layer the HTTP protocols over a local filesystem or Samba share, incorporate something as lightweight as Kerberos authentication over HTTP, and after registering it for webfinger your RemoteStorage is ready to go! This would even be possible in an embedded/router environment, which already offer Samba-mounts for USB-sticks. Current RemoteStorage is not nearly as likely in that sort of environment.

In short, I think the strict dependency on OAuth and zooming in on Implicit Tokens is too strict, and could easily hold back the success of the RemoteStorage concept. Both simpler and more complex schema's are likely to be useful to someone -- and should be supported in the spec and, hopefully at some point, in the JavaScript toolkit.

[michielbdejong]

authorisation in the backend

there is no backend, that's why. the OAuth spec explains why client-side apps can only use Implicit Grant, but you're right it's worth explaining this choice more specifically in the spec.

you can of course do so something less specific, and more like Samba, but then i wouldn't call it remoteStorage, i would just call it Samba. :)

[vanrein]

Hi Michiel,

there is no backend, that's why.

This is probably a matter of definitions. There is a form of storage, somewhere. That is what I mean with the term backend.

the OAuth spec explains why client-side apps can only use Implicit Grant, but you're right it's worth explaining this choice more specifically in the spec.

In general, picking only such a small part from the spec sounds like "cherry picking" -- it would probably be useful to explain how RemoteStorage fits into the spec, and makes its choices for the concrete protocol specification.

you can of course do so something less specific, and more like Samba, but then i wouldn't call it remoteStorage, i would just call it Samba. :)

Ah, I see. But Samba is a rather different system -- it is not usable for the web, which is precisely the added value of RemoteStorage.

I see no reason to exclude other methods of authorisation if they can work well. Especially if they can be implicit -- arranged by the browser. A spec that only leaves one pattern open for use invites alternatives with cryptographically better protocols, leaving the landscape scattered and confusing. This is precisely the sort of thing I suggest you to avoid.

-Rick

[michielbdejong]

oh right, yeah i commented on the other ticket that it would be nice to bind bearer tokens to the device if that is possible

[michielbdejong]

after seeing the pull request i now understand how the implied auth would work :) https://github.com/remotestorage/remotestorage.js/pull/602/files

we can add this option to the -03 spec. this would not burden storage providers, nor storage users, who do not use it, and the burden on the remotestorage.js client-side library (and other client implementations) is tiny, as that pr shows.

thanks for researching this, @vanrein!

[silverbucket]

:)

On Sun, Feb 2, 2014 at 3:00 PM, Michiel@unhosted
notifications@github.comwrote:

after seeing the pull request i now understand how the implied auth would
work :) https://github.com/remotestorage/remotestorage.js/pull/602/files

we can add this option to the -03 spec. this would not burden storage
providers, nor storage users, who do not use it, and the burden on the
remotestorage.js client-side library (and other client implementations) is
tiny, as that pr shows.

thanks for researching this, @vanrein https://github.com/vanrein!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/39#issuecomment-33900921
.

[michielbdejong]

ah, a sidenote i just though of: we would have to specify that no "funny stuff" should be presented to clients that request a document under the /public folder. they should be available publically without any kind of auth. but that's possible. it only becomes impossible if we choose to implement support for sharing/collaboration #58 later

[raucao]

How does authorization for categories work with Kerberos? Is this all thought through and with feedback included? Seems like a quick shot to me.

[michielbdejong]

For Kerberos, only all-or-nothing root access is supported afaik