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

From: "Michael Pasternak" <mpastern(a)redhat.com&gt; To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt;, "Vojtech Szocs" <vszocs(a)redhat.com&gt;, "Einav Cohen" <ecohen(a)redhat.com&gt;, "Itamar Heim" <iheim(a)redhat.com&gt;, "Juan Hernandez" <jhernand(a)redhat.com&gt;, "engine-devel" <engine-devel(a)ovirt.org&gt; 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.

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