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

[Alon Bar-Lev]

----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>, "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen" <ecohen at redhat.com>,
> "Itamar Heim" <iheim at redhat.com>, "Juan Hernandez" <jhernand at redhat.com>, "engine-devel" <engine-devel at 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