4:53 a.m.
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#_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.
Regards,
Vojtech
--
Michael Pasternak
RedHat, ENG-Virtualization R&D