> 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.
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. - David ----------------------------------------------------------- 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";, > "auth_mechanism": "COOKIE" > } > ] > $ dist/aurora.pex quota get build/root > > > Thanks, > > Giulio Eulisse > >
