I recently sent a PR for oauth token authentication in Foreman ( https://github.com/theforeman/foreman/pull/2052 ). Some people asked me why this is needed or if plugins need this? To clarify, plugins running inside Foreman do not need token authentication. T he user is already authenticated, so the API requests will work fine as there is already User.current.
I added the oauth token authentication for three reasons:
- I think it's a good security idea in general to send API requests using a temporary token (default 2 hours) rather than passing username/password on every request.
- I foresee future "plugins" that use the Foreman API, whether written in EmberJS or AngularJS, that will run "outside" of Foreman and thus will require authentication through the API.
3 ) I'm giving a talk at Config Management Camp 2015 in Ghent, Belguim on February 3-4 about EmberJS & Foreman and wanted to include authentication in my demo.
Regards,
Joseph Magen
Red Hat Engineering
I like this better than the current OAuth setup we have. Currently we
have to pass the X-FOREMAN-USER header in order to authenticate as a
certain user, which is clunkier than asking for a token in my opinion.
It also relies on the admin configuring OAuth which is easy but not
easier than 0 configuration which is what Doorkeeper brings to the
table.
It seems to me though that both options (having a bearer token or
passing the header w/consumer key) rely on HTTPS, so if HTTPS is
misconfigured (think of a MITM attack, with a forged certificate the
client won't check it) this is broken as well. I wonder if we could
add some kind of signing to Doorkeeper to protect these tokens.
There's an internal draft in OAuth about adding this in OAuth instead
of forcing clients to add it themselves. I'm not an expert in the
field so take everything I said with a pinch of salt!
All in all, OK but we should drop previous OAuth and check carefully
previous auth bugs we got cannot be reproduced in this setup. Looking
forward to hear about other people's (committers and users) opinions
on this.
···
On Mon, Jan 12, 2015 at 9:07 AM, Joseph Magen wrote:
> I recently sent a PR for oauth token authentication in Foreman
> (https://github.com/theforeman/foreman/pull/2052). Some people asked me why
> this is needed or if plugins need this? To clarify, plugins running inside
> Foreman do **not** need token authentication. The user is already
> authenticated, so the API requests will work fine as there is already
> User.current.
>
> I added the oauth token authentication for three reasons:
>
> 1) I think it's a good security idea in general to send API requests using a
> temporary token (default 2 hours) rather than passing username/password on
> every request.
> 2) I foresee future "plugins" that use the Foreman API, whether written in
> EmberJS or AngularJS, that will run "outside" of Foreman and thus will
> require authentication through the API.
> 3) I'm giving a talk at Config Management Camp 2015 in Ghent, Belguim on
> February 3-4 about EmberJS & Foreman and wanted to include authentication in
> my demo.
>
> Regards,
>
> Joseph Magen
> Red Hat Engineering
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
–
Daniel Lobato
@elobatoss
blog.daniellobato.me
daniellobato.me
GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
Indeed, we definitely shouldn't carry two OAuth implementations. This
should replace it if it's merged - which also means ensuring the
apipie-bindings stack, installer etc support it properly.
···
On 12/01/15 08:54, Daniel Lobato wrote:
> All in all, OK but we should drop previous OAuth and check carefully
> previous auth bugs we got cannot be reproduced in this setup. Looking
> forward to hear about other people's (committers and users) opinions
> on this.
–
Dominic Cleal
Red Hat Engineering
