9:13 a.m.
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 [*]
[*] 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..
@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.
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.
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. 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..
Regards,
Vojtech
----- Original Message -----
From: "Michael Pasternak" <mpastern(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: "Vojtech Szocs" <vszocs(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: Thursday, May 9, 2013 11:27:35 AM
Subject: Re: [REST-API] Support passing auth information without having to use HTTP
Authorization header #958874
On 05/07/2013 07:44 PM, Alon Bar-Lev wrote:
----- Original Message -----
> From: "Michael Pasternak" <mpastern(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>, "Vojtech Szocs"
<vszocs(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>
> Sent: Monday, May 6, 2013 9:46:31 AM
> Subject: [REST-API] Support passing auth information without having to use HTTP
Authorization header #958874
>
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=958874
>
> Hi Alon,
>
> (In reply to comment #2)
>>
>> Regardless of this specific RFE I would like to write that I don't like the
>> REST API session mechanism
>> [http://wiki.ovirt.org/Features/RESTSessionManagement] solution, as it
>> relays on cookies and not explicit API interaction.
>
> authentication in RESTful application is a matter of debate, it can be
> achieved
> in various ways, but session + cookie auth. method is very common and usually
> effective,
>
> it's biggest disadvantage is that it's not exactly RESfull cause client
> have to maintain (story) the cookie and not the server (but i wouldn't call
> it an
> issue at all), besides that it's works perfectly well from the REST PoV,
>
> also some may say that cookies are not strong enough and OAuth for instance
> should be used instead, but this is a different story cause in our case,
> cookie
> are for the clients (not browsers [1]) that can store them in a secure way or
> even
> not to store at all (in-memory cookie).
>
> [1] another disadvantage is that webbrowsers not able to access cookie
> namespace,
> but lately i've suggested URI based authentication [2] to support web
> browsers
> as well.
>
> [2] http://lists.ovirt.org/pipermail/engine-devel/2013-April/004235.html
>
> the biggest advantage of the cookie is a session expiration that maintained
> by the server and abstracted from the client what is much better from
> security
> PoV than standard authentication mechanisms such as HTTP basic auth for
> instance
> which can be potentially cached.
Expiration is always managed by server side, regardless the cookie vs ticket debate.
>
>> I would have expected a
>> 'ticket' to be retrieved and that 'ticket' to be disconnected
from the
>> application server objects. Although we can refer the 'cookie' as a
ticket,
>> however the requirement to parse it should not be required, there be a
>> conflict between two separate applications running on same server, and
>> there
>> may be a problem to transfer credentials between servers.
>
> well, this is not exactly correct:
>
> 1. client desn't have to decode/parse the cookie and pass credentials, all it
> need is
> just to store the cookie and pass it as is to server on every request.
You just described what cookies are.
And if I understand we want better control of application authentication, disconnected
from 'default browser behavior'.
> 2. "conflict between two separate applications running on same server"?
> different cookie
> uses different domain & path by spec., can you pls explain what do you
> mean by this?
If you call the cookie JSESSIONID....
different applications cannot live under same path,
this what for cookie has a "path" attribute,
but it can create a bit of confusion indeed, but you not
talking with more than one application in same time right ?!,
i.e container/client fetches the JSESSIONID cookie from the
specific request/response,
so i'm not sure how possibly client can get in reply two
cookies with a same name (even if all applications are using
same cookie)
>>
>> If we modify authentication we should support more authentication types, at
>> least SPNEGO.
>>
>> In order to allow SPNEGO and other authentication mechanisms, we better
>> force people to use single URI to perform the login and return
>> authenticated
>> 'ticket' to continue interaction with application.
>
> this is good for the backend authentication, but is not for the RESTful
> application, it's like buying an aeroplane and driving it on a road,
And why is that? who are you to decide what authentication mechanism is to be used by
customers?
alon, you misunderstood, i'm not talking about authentication method,
but about your sentence ^ "we better force people to use single URI"
If customer has a policy of not transmitting passwords over the
network, then SPENGO is your friend.
But let's ignore it for now.
cookie is not any different from the SPENGO token in this meaning,
it's just another data container.
> "force people to use single URI to perform the login" means SOAP while we
> wanted REST
> where any URI is considered as entry point and actually a resource address
> that should
> be accessible/manipulatable and authentication should be
> abstracted/disconnected from
> this concept.
Again, you provide statements that are not written in stone.
this is main REST principal.
Having custom authentication header breaks the 'plain simple
rest'.
Having a URI is only makes it easier to manage this breakage.
for us, but this is breaks a REST concept.
> SPNEGO is only an implementation detail that can be abstracted for the API.
I don't follow.
>> This will be much simpler
>> implementation at the api side and much more efficient, and as we are
>> discussion application-to-application interaction there should be no user
>> experience visible issues.
>
> i'm not sure: "force people to use single URI to perform the login" and
no
> "no user experience visible issues."?
Please describe how the prefer mechanism suggested can be implemented in standard
browser.
it cannot because authorization header has to be supplied only when
client wishes to reinitialize the JSESSION, and web browsers can't omit
it during the lifetime.
all this cause we don't support web browsers in api yet, session based
authentication mechanism was designed for http clients,
and this why we having this discussion, currently options are:
1. adapt session based authentication
2. introduce new concept
personally i prefer #1 as it's less noisy and easily achievable.
And if it cannot, and custom logic is required, why a custom logic
that accesses a custom URI to perform login is any different.
it's not RESTful
>>
>> What I recommend is purely applicative rest login command...
>
> IIUC this is SOAP and not REST ...
Again... please refrain from these kind of void statements.
SOAP is a protocol, it has specific format and rules.
It may or may not use this or any other suggested authentication mechanism.
i'm not talking about the protocol, but about the conceptual differences
between SOAP and REST services.
SOAP is a RPC (Remote Procedure Call) and has single entry point on which
different methods are invoked, having single dedicated method for login
works in this case,
REST is a ROA (Resource Oriented Architecture), i.e everything is REST is a
resource, and you have to operate on these resources, authentication is only
an implementation detail that should not break this concept.
now saying this i think is clear that you have no place to put at the login()
method you've mentioned,
standard way for authentication in REST/HTTP is via 'authorization' header (per
request),
optimizing this we've introduced new concept via sessionid,
user can choose between two by passing 'prefer:persistent_auth' header,
hope it's clear now, please let me know otherwise.
>> ---
>> Input: authentication type, authentication credentials
>> authentication=http
>> authentication=password
>> credentials:
>> user=user
>> password=password
>> [OPTIONALLY] HTTP authentication headers
>> Output:
>> ticket
>> ticket issue time (required to avoid clock sync)
>> ticket expiration time
>> Logic:
>> if authentication is http, use http authentication headers to establish
>> user
>> authentication. This will allow future SSO.
>> if authentication is password, use embedded credentials.
>> ---
>>
>> For every other rest call add http header:
>> oVirt-Authentication-Ticket: <ticket>
>
> this is not any different from the today's session based auth. only
> instead of oVirt-Authentication-Ticket added cookie.
I did not claim otherwise, I wrote that I don't like cookies, I do like explicit
headers.
As I wrote, cookies has limited storage at client, cookies may conflict, cookies has
issues with clusters.
Headers do not.
using headers has own drawbacks, WebAdmin core is not only entity that
requires authentication in the app, i'll give you one use-case:
today we have plugin interface in WebAdmin, WebAdmin may have different
plugins installed, to maintain different permissions for every plugin,
each will have to send own authorization data on every request,
as you see this turns to be truly complex, almost not feasible via headers,
btw in other thread i suggested to used URL parameters for passing authentication
tokens.
>>
>> The backend side will attach the correct security context to the action if
>> the header is received.
>
> this is how it's works today.
I could not imagine that.
Regards,
Alon
--
Michael Pasternak
RedHat, ENG-Virtualization R&D