[Engine-devel] [REST-API] Support passing auth information without having to use HTTP Authorization header #958874
9:46 a.m.
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.
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.
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 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,
"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.
SPNEGO is only an implementation detail that can be abstracted for the API.
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."?
What I recommend is purely applicative rest login command...
IIUC this is SOAP and not REST ...
---
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.
The backend side will attach the correct security context to the action if
the header is received.
this is how it's works today.
No need for the prefer mechanism nor multiple authentications. It should be
easy for javascript implementation to perform the authentication via the
designated URI, and then pass the ticket if not expired, when expired to
perform re-authentication with or without involving the user.
again this is how it works today, and you not solving web browser problem as
when ticket expires, they cannot re-authenticate with new oVirt-Authentication-Ticket
cause this header is cached and cannot be changed by the browser in runtime.
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
7:44 p.m.
----- 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....
>
> 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?
If customer has a policy of not transmitting passwords over the network, then SPENGO is
your friend.
But let's ignore it for now.
"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.
Having custom authentication header breaks the 'plain simple rest'.
Having a URI is only makes it easier to manage this breakage.
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.
And if it cannot, and custom logic is required, why a custom logic that accesses a custom
URI to perform login is any different.
>
> 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.
> ---
> 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.
>
> 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.
>
> No need for the prefer mechanism nor multiple authentications. It should be
> easy for javascript implementation to perform the authentication via the
> designated URI, and then pass the ticket if not expired, when expired to
> perform re-authentication with or without involving the user.
again this is how it works today, and you not solving web browser problem as
when ticket expires, they cannot re-authenticate with new
oVirt-Authentication-Ticket
cause this header is cached and cannot be changed by the browser in runtime.
Header is cached? Can you please explain?
If I use XMLHTTPRequest() to perform the request, I control the headers explicitly.
Regards,
Alon
12:27 p.m.
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
5:13 p.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
6:49 p.m.
--=-9LSxtO2jtW2b8wAGRRYW
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Vojtech Szocs p=C3=AD=C5=A1e v =C3=9At 14. 05. 2013 v 10:13 -0400:
Hi guys,
=20
I followed this thread, there are some interesting points, sending my com=
ments
below.
=20
First of all, I understand that REST API should follow common REST princi=
ples,
and implement additional features (such as authentication) seamlessly=
on top of these principles, if possible.
=20
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
JavaScrip=
t apps [*]
[*] long story short: JavaScript app hosted from
"/myapp/index.html" cann=
ot 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
=20
Both issues written above have something (very important) in common: "bro=
wser-specific" + browser having control (over 'Authorization' header /
cook=
ies) instead of JavaScript app..
=20
@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 bett=
er, if we could pass auth credentials via URI, we could talk to REST API wi=
thout relying on HTTP 'Authorization' header entirely.
=20
Also, I'm not strictly against HTTP Basic Auth used in REST API, I just p=
ointed out some of its drawbacks (a while ago). Originally, I proposed to s=
upport 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 interest=
ing, basically a protocol for negotiating specific auth scheme based on wha=
t server supports, the question is if we really need to support multiple au=
th schemes, or just one that is reasonably good.
Well, there are long-standing RFEs for kerberos support to the portals so i=
t would make sense from that POV.
David
=20
One auth scheme I really like is [http://docs.aws.amazon.com/AmazonS3/lat=
est/dev/RESTAuthentication.html] - basically preventing password from being=
sent over the network entirely, which is always a good thing. The disadvan=
tage is that the server has to know password ("secret key") in plain-text f=
or the given user, in order to re-produce & compare signature (hash) of rel=
evant request information. On the other hand, Gerrit REST API uses HTTP Dig=
est Auth [https://gerrit-review.googlesource.com/Documentation/rest-api.htm=
l#_protocol_details] but IMHO Digest Auth is over-complicated protocol, mos=
t importantly its too complex for clients to implement.
=20
> and this why we having this discussion, currently options are:
> 1. adapt session based authentication
> 2. introduce new concept
=20
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 itse=
lf (HTTP Basic Auth), another is how auth-related information is transmitte=
d between client and server (HTTP 'Authorization' header, JSESSIONID cookie=
) - for now I'd just proposed to revisit the "auth-related info transmissio=
n" part..
=20
Regards,
Vojtech
=20
=20
----- 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.c=
om>
Sent: Thursday, May 9, 2013 11:27:35 AM
Subject: Re: [REST-API] Support passing auth information without having t=
o use
HTTP Authorization header #958874
=20
On 05/07/2013 07:44 PM, Alon Bar-Lev wrote:
>=20
>=20
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern(a)redhat.com>
>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>, "Vojtech
Szocs" <vszocs@redhat=
.com>, "Einav Cohen"
<ecohen(a)redhat.com>,
>> "Itamar Heim" <iheim(a)redhat.com>, "Juan
Hernandez" <jhernand(a)redhat.co=
m>, "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=3D958874
>>
>> Hi Alon,
>>
>> (In reply to comment #2)
>>>
>>> Regardless of this specific RFE I would like to write that I don't li=
ke the
>>> REST API session mechanism
>>> [http://wiki.ovirt.org/Features/RESTSessionManagement] solution, as i=
t
>>> 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 clien=
t
>> 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 Po=
V,
>>
>> also some may say that cookies are not strong enough and OAuth for ins=
tance
>> should be used instead, but this is a different story cause
in our cas=
e,
>> 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.ht=
ml
>>
>> the biggest advantage of the cookie is a session expiration that maint=
ained
>> by the server and abstracted from the client what is much
better from
>> security
>> PoV than standard authentication mechanisms such as HTTP basic auth fo=
r
>> instance
>> which can be potentially cached.
>=20
> Expiration is always managed by server side, regardless the cookie vs t=
icket
debate.
>=20
>>
>>> I would have expected a
>>> 'ticket' to be retrieved and that 'ticket' to be
disconnected from th=
e
>>> application server objects. Although we can refer the
'cookie' as a t=
icket,
>>> however the requirement to parse it should not be
required, there be =
a
>>> conflict between two separate applications running on
same server, an=
d
>>> 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 reque=
st.
>=20
> You just described what cookies are.
> And if I understand we want better control of application authenticatio=
n,
disconnected from 'default browser behavior'.
>=20
>> 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?
>=20
> If you call the cookie JSESSIONID....
=20
different applications cannot live under same path,
this what for cookie has a "path" attribute,
=20
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,
=20
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)
=20
> =20
>>>
>>> If we modify authentication we should support more authentication typ=
es, at
>>> least SPNEGO.
>>>
>>> In order to allow SPNEGO and other authentication mechanisms, we bett=
er
>>> 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 RESTfu=
l
>> application, it's like buying an aeroplane and driving
it on a road,
>=20
> And why is that? who are you to decide what authentication mechanism is=
to
be used by customers?
=20
alon, you misunderstood, i'm not talking about authentication method,
but about your sentence ^ "we better force people to use single URI"
=20
> If customer has a policy of not transmitting passwords over the network=
,
then SPENGO is your friend.=20
> But let's ignore it for now.
=20
cookie is not any different from the SPENGO token in this meaning,
it's just another data container.
=20
>=20
>> "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 add=
ress
>> that should
>> be accessible/manipulatable and authentication should be
>> abstracted/disconnected from
>> this concept.
>=20
> Again, you provide statements that are not written in stone.
=20
this is main REST principal.
=20
> Having custom authentication header breaks the 'plain simple rest'.
> Having a URI is only makes it easier to manage this breakage.
=20
for us, but this is breaks a REST concept.
=20
>=20
>> SPNEGO is only an implementation detail that can be abstracted for the=
API.
>=20
> I don't follow.
>=20
>>> 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" an=
d no
>> "no user experience visible issues."?
>=20
> Please describe how the prefer mechanism suggested can be implemented i=
n
standard browser.
=20
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.
=20
all this cause we don't support web browsers in api yet, session based
authentication mechanism was designed for http clients,
=20
and this why we having this discussion, currently options are:
=20
1. adapt session based authentication
2. introduce new concept
=20
personally i prefer #1 as it's less noisy and easily achievable.
=20
> And if it cannot, and custom logic is required, why a custom logic that=
accesses a custom URI to perform login is any different.
=20
it's not RESTful
=20
> =20
>>>
>>> What I recommend is purely applicative rest login command...
>>
>> IIUC this is SOAP and not REST ...
>=20
> 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 mechan=
ism.
=20
i'm not talking about the protocol, but about the conceptual differences
between SOAP and REST services.
=20
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,
=20
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 o=
nly
an implementation detail that should not break this concept.
=20
now saying this i think is clear that you have no place to put at the log=
in()
method you've mentioned,
=20
standard way for authentication in REST/HTTP is via 'authorization' heade=
r (per request),
optimizing this we've introduced new concept via sessionid,
=20
user can choose between two by passing 'prefer:persistent_auth' header,
=20
hope it's clear now, please let me know otherwise.
=20
> =20
>>> ---
>>> Input: authentication type, authentication credentials
>>> authentication=3Dhttp
>>> authentication=3Dpassword
>>> credentials:
>>> user=3Duser
>>> password=3Dpassword
>>> [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 establi=
sh
>>> 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.
>=20
> 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.
=20
using headers has own drawbacks, WebAdmin core is not only entity that
requires authentication in the app, i'll give you one use-case:
=20
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,
=20
as you see this turns to be truly complex, almost not feasible via header=
s,
=20
btw in other thread i suggested to used URL parameters for passing authen=
tication
tokens.
=20
>=20
>>>
>>> The backend side will attach the correct security context to the acti=
on if
>>> the header is received.
>>
>> this is how it's works today.
>=20
> I could not imagine that.
> =20
>=20
> Regards,
> Alon
>=20
=20
=20
--=20
David Ja=C5=A1a, RHCE
SPICE QE based in Brno
GPG Key: 22C33E24=20
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
--=-9LSxtO2jtW2b8wAGRRYW
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMdTCCBjQw
ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX
DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK
75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC
+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD
z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr
/+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc
fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG
XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt
UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R
HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv
sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s
sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq
+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT
zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq
Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1
9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGOTCCBSGg
AwIBAgIDBl1jMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN
MTMwNDEwMTE0ODI4WhcNMTQwNDEwMTM1MDM0WjBXMRkwFwYDVQQNExAxUktWVnliSEdDZnRMWjY3
MRkwFwYDVQQDDBBkamFzYUByZWRoYXQuY29tMR8wHQYJKoZIhvcNAQkBFhBkamFzYUByZWRoYXQu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx8unM64NLnlRZujXHb0ilCaqc7KB
r1MwlyCtOWAyH4M/24zvfyRQyTz4ZkHd1sMeewJ5ap1/128hLSqMY/6So5yhL6UlK3nM1r9H9PTz
CiPEMZmDazIzMb/Mt/4N3kkJBLpWPFRB5aB+COcex7a4dlmnUJASVWkVwvHRmfa06anME7DTccV5
cV95FKqoRUXawopdu5W2NhailCtbQJAbMIGf9FpH+J98swAsVHdvjZkSDnZcoQIPHzoPrEBawb7C
vsmCe8p7pv5Dxtx3T47FdAXJiO9u+QJkaBFjfiA9ywN8fFo3Q/Jr4vl6WqEr1SyQjgL9/dWeQSYI
8LzByChnXQIDAQABo4IC1jCCAtIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYI
KwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ5AqZ3fyU5HOme+iF4KA3f8RxHPjAfBgNVHSME
GDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAbBgNVHREEFDASgRBkamFzYUByZWRoYXQuY29tMIIB
TAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENl
cnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQg
YWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBT
dGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3Nl
IGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQv
MC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUF
BwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx
L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3Vi
LmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t
LzANBgkqhkiG9w0BAQUFAAOCAQEArlvH1bAdnpLvyeMQzPtJYs65ur7cpYnrxrIZ3P/r0F7juzIU
fb1S+M9sYBhalmBoZQMySlVveDYHUHPDsNJQtqUzYAJMbVTdRtviCSq3wmYtG/VJOOif11gM25u4
HcgXVuhF3di5G0CHwAIx0mjUi7fPJ3WMeFKWp550ZqpbFK/i9A5fJGfHk3MfXOhAu7vkEEjJY+gA
BpFqvk134+30mP4KoXfNGZpekWvj6lS/tfaxuuSTusPcY0yIGGtJqqFtL1tRlTIoaDGiok5O0k6W
pMFPtm+dGnOyKT4HQMFCaAgBOVCQFDYthuGlnUlJOP/BheuvaMfwgIqM4ir+DIqOyjGCAhswggIX
AgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwZdYzAJBgUrDgMCGgUAoF0wGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTE0MTU0OTIwWjAjBgkq
hkiG9w0BCQQxFgQUeUMi45pkz/QGd6S5e8lzrdExJkQwDQYJKoZIhvcNAQEBBQAEggEAsm2Mob5X
TUMBNhTnxbzYlyJ8kyQq43SsauAqDo+J0hzrtjEdyR5IQerV3LQStJTNgkJ6nphBW7IjBqbGyAF4
ZHABHygBkqj49qo2tub1Z3LcGrHPKM4gsTb5yCHKM2u52PO+PZh3hoF27PVyBsqoEct3uPkOtFmd
GeiM+ZKtl1a38s0ssnP/CuCbhjqPUQEwY3Xg/tWSWiIWCxzyh+tL5/AIdFCDag0bttFdqZ1NjmhF
7I6pbkP5FKwYh4blD2rqa7SHVyFjXx5HTo/kY1kRGuPdbW3inPK9y/3y+Y1Q8qNOKVyYkvGhJRXO
GmVV8rTH5U/UFGzRkPoOYxdlDy+wOAAAAAAAAA==
--=-9LSxtO2jtW2b8wAGRRYW--
3:03 p.m.
Hi David,
Well, there are long-standing RFEs for kerberos support to the
portals so it would make sense from that POV.
Yeah, if we should support extra auth schemes like kerberos, in addition to existing auth
scheme in REST API, SPNEGO makes sense in that case..
Vojech
----- Original Message -----
From: "David Jaša" <djasa(a)redhat.com>
To: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Tuesday, May 14, 2013 5:49:20 PM
Subject: Re: [Engine-devel] [REST-API] Support passing auth information without having to
use HTTP Authorization header #958874
Vojtech Szocs píše v Út 14. 05. 2013 v 10:13 -0400:
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.
Well, there are long-standing RFEs for kerberos support to the portals so it would make
sense from that POV.
David
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
>
--
David Jaša, RHCE
SPICE QE based in Brno
GPG Key: 22C33E24
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
12:53 p.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
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
8:58 p.m.
----- 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 12:27:35 PM
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,
I am taking exactly on that... good on demand authentication mechanism should allow
concurrent multiple users processing. This is what API is all about.
Of course this can somehow achieved via cookie, but doing so is so complex that one
probably wish to use plain header, or worse case a cookie that does not conflict with the
application that loaded the static content.
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)
Because of this, authorization mechanism should not use cookies.
>>>
>>> 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.
Yes they are, they cannot provide challenge response sequence required to establish
trust.
>
>> "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.
I know very few principles that have no exceptions in software engineering.
> 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.
Per your interpretation.
>
>> 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.
But will force you to face more issues in future.
> 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
I am tired to answer this over and over...
>
>>>
>>> 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,
So happy to know!
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.
REST accept cookie that was obtained from former authentication, so it breaks your above
statement.
The cookie can and usually is acquired by different URI.
now saying this i think is clear that you have no place to put at the
login()
method you've mentioned,
Exactly from which you took the cookie, in your language from the Session resource.
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.
Well, it is clear that this is not a discussion, but dictation...
So do whatever you think...
>
>>> ---
>>> 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,
No I cannot, every plugin can either use the current state of application (JSESSIONID) or
can authenticate and get its own ticket, pass it via its own requests.
btw in other thread i suggested to used URL parameters for passing
authentication
tokens.
I do not follow how it is relevant, and why URL parameters are better than HTTP header.
>
>>>
>>> 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
>
12:50 p.m.
On 05/16/2013 08:58 PM, Alon Bar-Lev wrote:
----- 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 12:27:35 PM
> 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,
I am taking exactly on that... good on demand authentication mechanism should allow
concurrent multiple users processing. This is what API is all about.
works like a charm with today's authentication methods.
Of course this can somehow achieved via cookie, but doing so is so
complex that one probably wish to use plain header,
complex only for browsers.
or worse case a cookie that does not conflict with the application
that loaded the static content.
> 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)
Because of this, authorization mechanism should not use cookies.
?, sorry, you lost me.
>>>>
>>>> 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.
Yes they are, they cannot provide challenge response sequence required to establish
trust.
you're right the GSSAPI negotiation mechanism is nowhere near the standard cookie
auth, however
we where talking about passing the password over the wire, and this is what my response
was
about, not conceptual differences between SPENGO & session-cookie+ssl auth.
>
>>
>>> "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.
I know very few principles that have no exceptions in software engineering.
>> 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.
Per your interpretation.
this is not correct, you're welcome to read Roy Fielding doctoral dissertation on
top of which REST was build, (that's what i did before my first reply on REST related
threads).
and to put the things on a right shelf (so i won't be wrongly interpreted again),
i have nothing against the SPENGO - just nothing, my problem is forcing users to
access dedicated URI for authentication/authorization (as was suggested by
you) before being able to fetch/change resource representation.
again don't get me wrong, i'm not justifying Cookies (actually i even wasn't
the
one that decided to use this mechanism), but saying "I know very few principles that
have no exceptions in software engineering" is not helping, anything can be done
differently, the question is 'why?' (i'd agree with this only if auth could
not be
made differently, but obviously this is not the case)
>>
>>> 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.
But will force you to face more issues in future.
>> 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
I am tired to answer this over and over...
>>
>>>>
>>>> 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,
So happy to know!
Alone, none is trying to offend you, or your knowledge, just that a lot of people
CC'ed in this tread, so in sake of fair discussion (have everyone in sync), i'm
going to these levels.
> 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.
REST accept cookie that was obtained from former authentication, so it breaks your above
statement.
The cookie can and usually is acquired by different URI.
i never said this.
> now saying this i think is clear that you have no place to put at the login()
> method you've mentioned,
Exactly from which you took the cookie, in your language from the Session resource.
:), you told something completely different at the beginning, it was:
"we better force people to use single URI to perform the login and return
authenticated 'ticket'",
now by saying "session resource", i'll assume that you mean any resource
(cause cookie can be obtained
from the any URI), e.g
/api
/api/vms/xxx
/api/vms/xxx/disks/yyy
i.e any of these can serve as an entry point to api and a place to obtain the ticket
from,
and this is how it works today btw.,
so IIUC, this is one of the ways to go.
> 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.
Well, it is clear that this is not a discussion, but dictation...
So do whatever you think...
this is not true, if it was like this i wouldn't start this discussion
to begin with,
the power of OS is that a lot of people sharing theirs knowledge and
at the end best approach is chosen,
not agreeing on some part/s of suggestion != exclusive locking, i'm
always open for new ideas and ready to learn from others.
>> Regards,
>> Alon
>>
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
4203
days inactive
4218
days old
9 comments
4 participants
participants (4)
-
Alon Bar-Lev -
David Jaša -
Michael Pasternak -
Vojtech Szocs