mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Mann <g...@mesosphere.io>
Subject Re: Review Request 46866: Enabled authorization of libprocess HTTP endpoints (libprocess).
Date Tue, 10 May 2016 04:13:01 GMT


> On May 9, 2016, 10:28 a.m., Alexander Rojas wrote:
> > 3rdparty/libprocess/include/process/http.hpp, line 85
> > <https://reviews.apache.org/r/46866/diff/4/?file=1375178#file1375178line85>
> >
> >     Is there a design doc or an overall explanation of how authorization will be
performed in libprocess?
> >     
> >     I find it cool if we provide an API which can be used in Mesos, similar to how
authentication works, also to keep them consistent.
> >     
> >     Of the top of my head, how about changing `route` to use a set of flags, similar
on how streams work in the stdlib so we can define if you want authentication + authorization,
etc.

No, there isn't a design doc, though perhaps there should be. I think we're in agreement that
we should provide a consistent interface for authentication and authorization in libprocess.
I was thinking about this after our discussion this morning: the key difference between the
existing HTTP authentication implementation and the authorization implementation proposed
here is the way in which endpoints are mapped to handlers. For AuthN, both endpoints and authenticators
get mapped into a space of realms, and thus endpoints are implicitly mapped to authenticators.
In the current proposal, authorization callbacks get directly mapped to endpoints via the
full endpoint path.

One question is: will most HTTP endpoints require unique authorization logic? If so, then
perhaps it's only cumbersome to have an intermediate mapping onto something like a "realm".
Or perhaps there's another good reason for this mapping that I'm not thinking of?

A difficulty in adding a new `route` function to handle these cases is that the authorization
logic lives in Mesos, but the endpoint is `route`d for the first time in libprocess. In order
to accomplish this, we would need to allow one process to override the `route` call of another
process. This is possible, but seems less than ideal to me.


- Greg


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46866/#review132237
-----------------------------------------------------------


On May 10, 2016, 3:23 a.m., Greg Mann wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46866/
> -----------------------------------------------------------
> 
> (Updated May 10, 2016, 3:23 a.m.)
> 
> 
> Review request for mesos, Alexander Rojas and Kapil Arya.
> 
> 
> Bugs: MESOS-5286
>     https://issues.apache.org/jira/browse/MESOS-5286
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> This patch enables libprocess to store and execute
> authorization callbacks provided by a client
> application.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/http.hpp 8f4eabcbb71ead1f5c28e1d8a2dd40db7af1f297

>   3rdparty/libprocess/src/process.cpp dcaa64633d1eea330649c563635642928164d73c 
> 
> Diff: https://reviews.apache.org/r/46866/diff/
> 
> 
> Testing
> -------
> 
> `make check` on OSX.
> 
> 
> Thanks,
> 
> Greg Mann
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message