> 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. > > Giulio Eulisse wrote: > 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)? > > David McLaughlin wrote: > So, it really sounds like this is organizational specific logic and I > think it belongs in a custom build of the Aurora client. I'm not sure if we > document how to do that anywhere? But we do this at Twitter for a whole bunch > of stuff. I can create a ticket to document this somewhere if it doesn't > exist. > > Giulio Eulisse wrote: > Ok, I can do the custom build of the aurora client, a pointer to > instructions is indeed welcome, thank you in advance if you can find the time > to document that. Right now I simply copy aurora.pex and aurora_admin.pex to > PATH. > > That said, I am surprised this kind of pattern (a frontend doing the > authentication a backend which gets the authenticated requests securely) is > considered as "organizational specific logic" rather than a reasonably common > practice (at least in my personal experience).
I added a review for the documentation. I still feel pretty strongly with what I said above, but if others feel like this is harmless and the use-case of a proxy that handles cookie management is common enough, then I'll withdraw my concern. - David ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/51893/#review151674 ----------------------------------------------------------- On Oct. 14, 2016, 12:40 p.m., Giulio Eulisse wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/51893/ > ----------------------------------------------------------- > > (Updated Oct. 14, 2016, 12:40 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";, > "auth_mechanism": "COOKIE" > } > ] > $ dist/aurora.pex quota get build/root > > > Thanks, > > Giulio Eulisse > >
