On Tue, Jan 27, 2015 at 2:23 PM, Francesco Mari <mari.france...@gmail.com> wrote: > My personal point of view is that the remote API should make Oak > interoperable between different software stacks. Some of these > software stacks may want to use their own authentication strategies > which may (or may not) be the authentication strategies provided by > Oak. > > In a typical web application, in example, every time a user A wants to > do something, the following happens: > > - The user U sends a request to the web application and provides his > personal credentials. > > - The web application connects to a database. This connection usually > uses a set of credentials D that are necessary to establish a > conversation with the database. > > - The web application extracts the credentials for U from the request > and authenticates them. Information about U are usually saved in the > database. > > - The web application reads and writes data on behalf of U, on top of > a database connection that was previously authenticated with the > credentials D. > > One of the goals of the remote interface, in my opinion, should be to > enable this scenario. It should be possible to replace the word > "database" with "Oak" in every point in the list above. If an > application uses Oak as a storage system, that application should not > be limited to the authentication strategies supported by Oak.
IIUC we're talking here about the remoting layer of the repository (oak), not about hypothetical applications. an oak client should IMO be able to use the same credentials regardless of the deployment (local vs remote), i.e. it should be transparent. requiring a remote client to provide oak 'admin' credentials just feels totally wrong. cheers stefan > > On the other end, we still want to leverage the authorization > mechanism built into Oak. The way authorization works in Oak is > strongly decoupled from authentication. As long as a user exists, > regardless of how it was authenticated, authorization will still work. > This is one of the strongest point of authorization in Oak, in my > opinion. > > 2015-01-27 12:11 GMT+01:00 Stefan Guggisberg <stefan.guggisb...@gmail.com>: >> On Tue, Jan 27, 2015 at 11:31 AM, Francesco Mari >> <mari.france...@gmail.com> wrote: >>> Should the API expose every authentication strategy implemented in >>> Oak? >> >> which strategy should be supported by the remoting layer is something >> that needs TBD. >> i'd say we start with the simple case (password credentials). >> >> cheers >> stefan >> >>> How is this API should look like? >>> >>> 2015-01-27 10:39 GMT+01:00 Stefan Guggisberg <stefan.guggisb...@gmail.com>: >>>> On Tue, Jan 27, 2015 at 10:16 AM, Francesco Mari >>>> <mari.france...@gmail.com> wrote: >>>>> Which other alternatives do we have regarding authentication? >>>> >>>> remote and local users should IMO use the same credentials. it should >>>> be transparent to the user whether he's accessing a local or a remote >>>> repo. >>>> >>>> cheers >>>> stefan >>>> >>>>> >>>>> 2015-01-27 9:16 GMT+01:00 Stefan Guggisberg <stefan.guggisb...@gmail.com>: >>>>>> hi francesco, >>>>>> >>>>>> On Fri, Jan 23, 2015 at 6:09 PM, Francesco Mari >>>>>> <mari.france...@gmail.com> wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> since I don't have access to the wiki, I started to write down a draft >>>>>>> for the remote API in a public GitHub repository [1]. >>>>>>> >>>>>>> I didn't write much so far, but I invite every interested party to >>>>>>> take a look at it for suggestions and improvements. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Francesco >>>>>>> >>>>>>> [1]: https://github.com/francescomari/oak-remote >>>>>> >>>>>> "To access the Oak Remote Interface a client needs to have the >>>>>> credentials of the master user." >>>>>> >>>>>> are you saying that a client needs master user credentials to access a >>>>>> remote oak instance? that would IMO be wrong. >>>>>> >>>>>> cheers >>>>>> stefan
