[Engine-devel] [REST-API] Support passing auth information without having to use HTTP Authorization header #958874

[Michael Pasternak]

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.

> [*] 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,
and there are plenty of others that can be used.

> 
> @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,

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,

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.

> 
> 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".

> On the other hand, Gerrit REST API uses HTTP Digest Auth [https://gerrit-review.googlesource.com/Documentation/rest-api.html#_protocol_details] 
> 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.

> 
> Regards,
> Vojtech
> 

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D