> On Oct. 6, 2016, 4:46 p.m., Stephan Erb wrote:
> > docs/operations/security.md, line 181
> > <https://reviews.apache.org/r/51893/diff/12/?file=1525261#file1525261line181>
> >
> > Does this require modifications of the scheduler? How does it pick up
> > the necessary information in your implementation?
>
> Giulio Eulisse wrote:
> No modification to the scheduler is required. The frontend adds a few
> HTTP headers for autheticated users which contain login and groups they
> belong to. The headers can eventually be used by a Shiro plugin which
> extracts authentication information and applies authorization rules. The
> frontend and the scheduler are on the same machine and only the frontend can
> talk to the backend, hence we are guaranteed that the headers cannot be
> spoofed.
>
> David McLaughlin wrote:
> It's a little concerning to only add support to the client, it sends a
> false message to anyone reading the code or documentation that we have
> first-class support for cookies. It would be analogous to only adding
> Kerberos support to the client and assuming some Shiro plugin handles the
> Kerberos logic in the Scheduler.
>
> You can also achieve what you're doing here with a custom client plugin
> and an internal build. This is what we do at Twitter for things that are
> specific to our deployment.
>
> David McLaughlin wrote:
> For some reason this conversation moved to e-mail. Giulio's response to
> my concern was:
>
> > IMHO, this is analogous to having basic auth authentication, but
> restricting access to the backend by having the frontend only allowing
> requests signed by certificates emitted by a given CA. You would still be
> using Basic-Auth, however you’d need the right certificate to be used by the
> client when doing a request.
>
> > This is exactly the same, just with a cookie in place of the
> certificate.
>
> > What would you consider "first class cookie support"?
>
> As a user I would expect the Scheduler to provide a CookieAuth module.
> The scheduler would create a cookie and know how to extract the user from it
> when it's sent with the request.

Advertising

Ok. I see what you mean. However what you propose would not solve my issue. As
a user I need to pass a cookie to be able to go through the frontend and reach
the scheduler in the first place. Basically what I am after is the ability to
decorate client requests with a cookie (and eventually a certificate) so that I
can be authenticated by the frontend and reach the scheduler. Notice that as a
Aurora Scheduler operator I've no control on the frontend which is managed at a
different level by a completely different group within our organization. Maybe
I should rename the auth_method to "EXTERNAL_COOKIE" to be more explicit? Or
maybe, rather then using auth_method I should use a different configuration
option (e.g. http_frontend_cookie)?
- Giulio
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/51893/#review151674
-----------------------------------------------------------
On Oct. 11, 2016, 1:58 p.m., Giulio Eulisse wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51893/
> -----------------------------------------------------------
>
> (Updated Oct. 11, 2016, 1:58 p.m.)
>
>
> Review request for Aurora, Joshua Cohen and Stephan Erb.
>
>
> Repository: aurora
>
>
> Description
> -------
>
> Allow cookie based authentication
>
> This allows aurora client to connect to servers which are behind a frontend
> which expects some sort of cookie to autheticate and authorize users. The
> cookie should be stored in MozillanCookieJar format in a file named
> `~/.aurora-token`.
>
>
> Diffs
> -----
>
> RELEASE-NOTES.md 1819eaa20cf5014228643a1e120316d646cc2824
> docs/operations/security.md 46e0b8a9db654f52467f9adf36307a6a97a7a3ec
> src/main/python/apache/aurora/admin/aurora_admin.py
> fbebbab8c827b5695042d18770d850e31fc38122
> src/main/python/apache/aurora/client/cli/client.py
> fa0c2648c5ff7ea6c9d949cf8cd9b9795d452e98
> src/main/python/apache/aurora/common/cookie_auth_module.py PRE-CREATION
> src/test/python/apache/aurora/common/test_cookie_auth_module.py
> PRE-CREATION
>
> Diff: https://reviews.apache.org/r/51893/diff/
>
>
> Testing
> -------
>
> $ cat ~/aurora/clusters.json
> [
> {
> "name": "build",
> "scheduler_uri": "https://aliaurora.cern.ch&quot;,
> "auth_mechanism": "COOKIE"
> }
> ]
> $ dist/aurora.pex quota get build/root
>
>
> Thanks,
>
> Giulio Eulisse
>
>