Hi Michael, ----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "Einav Cohen" <ecohen@redhat.com>, "Itamar Heim" <iheim@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, "Barak Azulay" <bazulay@redhat.com> Sent: Tuesday, May 21, 2013 11:53:07 AM Subject: Re: [REST-API] Support passing auth information without having to use HTTP Authorization header #958874
Hi Vojtech,
On 05/14/2013 05:13 PM, Vojtech Szocs wrote:
Hi guys,
I followed this thread, there are some interesting points, sending my comments below.
First of all, I understand that REST API should follow common REST principles, and implement additional features (such as authentication) seamlessly on top of these principles, if possible.
It's just that sometimes, especially in JavaScript/HTML world, there are known issues (limitations) for which a good REST API implementation should provide reasonable workarounds. For me, this means two things: (a) issue with browser-specific HTTP 'Authorization' header handling for JavaScript apps [https://bugzilla.redhat.com/958861] (b) issue with browser-specific cookie handling restriction for JavaScript apps [*]
this is to avoid cross-site/cross-subdomain cookie attacks.
You're right, but my point was, dealing with cookies in JavaScript/HTML world is problematic in general, and good API should provide reasonable workaround for this. For example, a web application at "/myapp" interacts with "/restapi" via AJAX and due to same-path restriction (on top of same-origin), the application doesn't have full control over (cannot get/set) cookies obtained from "/restapi", it can only rely on the standard browser behavior, i.e. browser should take care of sending cookies for "/restapi" for any subsequent request to "/restapi".
[*] long story short: JavaScript app hosted from "/myapp/index.html" cannot access cookies for say "/api" path, only for "/myapp" path, i.e. cookies are under control of browser and not JavaScript app, more details: http://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_Path
Both issues written above have something (very important) in common: "browser-specific" + browser having control (over 'Authorization' header / cookies) instead of JavaScript app..
none of these two is a REST specific, those just two (another) authentication methods,
True, but both of these are currently required for Engine REST API persistent session mechanism to work, i.e. you have to use Authorization header for passing credentials, and you have to send JSESSIONID cookie in order to reuse given session.
and there are plenty of others that can be used.
Yes, my original idea/suggestion was to use special (non-Authorization) header for credentials, and also special (non-Cookie) header for the JSESSIONID cookie.
@Michael: is there some RFE/document for your "URI based authentication" proposal? Assuming JSESSIONID could be passed via URI, we could use this as a workaround for browser-specific cookie handling restriction. In practice, this would mean any JavaScript (WebAdmin itself, UI Plugin, any other web app) could talk to REST API without relying on cookies entirely. Even better, if we could pass auth credentials via URI, we could talk to REST API without relying on HTTP 'Authorization' header entirely.
in order to avoid link sharing problems and fixation attacks, for this pattern to work, we will have to regenerating SID on each request,
I agree.
this approach will give us a better view on given plugin activity via web server/proxy logs/etc., but doubt if it worth the effort, cause same may be tuned on the engine side,
This approach would fix our two issues mentioned above: 1) need for Authorization header, 2) need for JSESSIONID cookie.
i guess it's just another way to do the same.
Also, I'm not strictly against HTTP Basic Auth used in REST API, I just pointed out some of its drawbacks (a while ago). Originally, I proposed to support alternative (extra) auth scheme that is better and more secure, but in the end, I guess we should settle for one reasonably good auth scheme. I looked at SPNEGO [http://en.wikipedia.org/wiki/SPNEGO] - it looks interesting, basically a protocol for negotiating specific auth scheme based on what server supports, the question is if we really need to support multiple auth schemes, or just one that is reasonably good.
we may have to support kerberos auth in future. - SPNEGO/OAuth are good candidates for this.
I agree.
One auth scheme I really like is [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html] - basically preventing password from being sent over the network entirely, which is always a good thing. The disadvantage is that the server has to know password ("secret key") in plain-text for the given user, in order to re-produce & compare signature (hash) of relevant request information.
and this is a giant "cons".
Yes, there's no silver bullet :) But why is Amazon S3 using this auth scheme, if it has such a big con? (just teasing) :)
On the other hand, Gerrit REST API uses HTTP Digest Auth [https://gerrit-review.googlesource.com/Documentation/rest-api.html#_protocol...] but IMHO Digest Auth is over-complicated protocol, most importantly its too complex for clients to implement.
and this why we having this discussion, currently options are: 1. adapt session based authentication 2. introduce new concept
I'd vote for auth scheme that doesn't contradict general REST principles but is reasonably good (easy & secure). One thing is the auth protocol itself (HTTP Basic Auth), another is how auth-related information is transmitted between client and server (HTTP 'Authorization' header, JSESSIONID cookie) - for now I'd just proposed to revisit the "auth-related info transmission" part..
i tend to agree on this, the most simple way of supporting browsers in this stage is among cookie, obtaining SID from the headers.
If it's non-Set-Cookie header, I'm all for it! As mentioned many times in this thread, cookie handling is problematic in JavaScript/HTML clients, which are not full-blown web clients, they are essentially sandboxed "tabs" running in a full-blown web client -> browser :)
Regards, Vojtech
--
Michael Pasternak RedHat, ENG-Virtualization R&D