[Engine-devel] [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.
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
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com>, "Einav Cohen" <ecohen@redhat.com>, "Itamar Heim" <iheim@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, "engine-devel" <engine-devel@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
On 05/07/2013 07:44 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com>, "Einav Cohen" <ecohen@redhat.com>, "Itamar Heim" <iheim@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, "engine-devel" <engine-devel@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
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#_protocol...] 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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Vojtech Szocs" <vszocs@redhat.com>, "Einav Cohen" <ecohen@redhat.com>, "Itamar Heim" <iheim@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, "Barak Azulay" <bazulay@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com>, "Einav Cohen" <ecohen@redhat.com>, "Itamar Heim" <iheim@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, "engine-devel" <engine-devel@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
--=-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@redhat.com>
> To: "Alon Bar-Lev" <alonbl@redhat.com>
> Cc: "Vojtech Szocs" <vszocs@redhat.com>, "Einav Cohen" <ecohen@redhat.com=
>, "Itamar Heim" <iheim@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>=
, "engine-devel" <engine-devel@ovirt.org>, "Barak Azulay" <bazulay@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@redhat.com>
> >> To: "Alon Bar-Lev" <alonbl@redhat.com>, "Vojtech Szocs" <vszocs@redhat=
.com>, "Einav Cohen" <ecohen@redhat.com>,
> >> "Itamar Heim" <iheim@redhat.com>, "Juan Hernandez" <jhernand@redhat.co=
m>, "engine-devel" <engine-devel@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--
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@redhat.com> To: "engine-devel" <engine-devel@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#_protocol...] 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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Vojtech Szocs" <vszocs@redhat.com>, "Einav Cohen" <ecohen@redhat.com>, "Itamar Heim" <iheim@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, "Barak Azulay" <bazulay@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com>, "Einav Cohen" <ecohen@redhat.com>, "Itamar Heim" <iheim@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, "engine-devel" <engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Hi Vojtech, On 05/14/2013 05:13 PM, Vojtech Szocs wrote:
Hi guys,
I followed this thread, there are some interesting points, sending my comments below.
First of all, I understand that REST API should follow common REST principles, and implement additional features (such as authentication) seamlessly on top of these principles, if possible.
It's just that sometimes, especially in JavaScript/HTML world, there are known issues (limitations) for which a good REST API implementation should provide reasonable workarounds. For me, this means two things: (a) issue with browser-specific HTTP 'Authorization' header handling for JavaScript apps [https://bugzilla.redhat.com/958861] (b) issue with browser-specific cookie handling restriction for JavaScript apps [*]
this is to avoid cross-site/cross-subdomain cookie attacks.
[*] long story short: JavaScript app hosted from "/myapp/index.html" cannot access cookies for say "/api" path, only for "/myapp" path, i.e. cookies are under control of browser and not JavaScript app, more details: http://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_Path
Both issues written above have something (very important) in common: "browser-specific" + browser having control (over 'Authorization' header / cookies) instead of JavaScript app..
none of these two is a REST specific, those just two (another) authentication methods, and there are plenty of others that can be used.
@Michael: is there some RFE/document for your "URI based authentication" proposal? Assuming JSESSIONID could be passed via URI, we could use this as a workaround for browser-specific cookie handling restriction. In practice, this would mean any JavaScript (WebAdmin itself, UI Plugin, any other web app) could talk to REST API without relying on cookies entirely. Even better, if we could pass auth credentials via URI, we could talk to REST API without relying on HTTP 'Authorization' header entirely.
in order to avoid link sharing problems and fixation attacks, for this pattern to work, we will have to regenerating SID on each request, this approach will give us a better view on given plugin activity via web server/proxy logs/etc., but doubt if it worth the effort, cause same may be tuned on the engine side, i guess it's just another way to do the same.
Also, I'm not strictly against HTTP Basic Auth used in REST API, I just pointed out some of its drawbacks (a while ago). Originally, I proposed to support alternative (extra) auth scheme that is better and more secure, but in the end, I guess we should settle for one reasonably good auth scheme. I looked at SPNEGO [http://en.wikipedia.org/wiki/SPNEGO] - it looks interesting, basically a protocol for negotiating specific auth scheme based on what server supports, the question is if we really need to support multiple auth schemes, or just one that is reasonably good.
we may have to support kerberos auth in future. - SPNEGO/OAuth are good candidates for this.
One auth scheme I really like is [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html] - basically preventing password from being sent over the network entirely, which is always a good thing. The disadvantage is that the server has to know password ("secret key") in plain-text for the given user, in order to re-produce & compare signature (hash) of relevant request information.
and this is a giant "cons".
On the other hand, Gerrit REST API uses HTTP Digest Auth [https://gerrit-review.googlesource.com/Documentation/rest-api.html#_protocol...] 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
Hi Michael, ----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "Einav Cohen" <ecohen@redhat.com>, "Itamar Heim" <iheim@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, "Barak Azulay" <bazulay@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#_protocol...] 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
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Vojtech Szocs" <vszocs@redhat.com>, "Einav Cohen" <ecohen@redhat.com>, "Itamar Heim" <iheim@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, "Barak Azulay" <bazulay@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com>, "Einav Cohen" <ecohen@redhat.com>, "Itamar Heim" <iheim@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, "engine-devel" <engine-devel@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
On 05/16/2013 08:58 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Michael Pasternak" <mpastern@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Vojtech Szocs" <vszocs@redhat.com>, "Einav Cohen" <ecohen@redhat.com>, "Itamar Heim" <iheim@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, "engine-devel" <engine-devel@ovirt.org>, "Barak Azulay" <bazulay@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com>, "Einav Cohen" <ecohen@redhat.com>, "Itamar Heim" <iheim@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, "engine-devel" <engine-devel@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
participants (4)
-
Alon Bar-Lev -
David Jaša -
Michael Pasternak -
Vojtech Szocs