1:40 p.m.
Hi Michael,
----- Original Message -----
From: "Michael Pasternak" <mpastern(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "Alon Bar-Lev" <alonbl(a)redhat.com>, "Einav Cohen"
<ecohen(a)redhat.com>, "Itamar Heim" <iheim(a)redhat.com>, "Juan
Hernandez" <jhernand(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>, "Barak Azulay" <bazulay(a)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#_proto...]
> 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