----- Original Message ----- > From: "Michael Pasternak" <[email protected]> > To: "Alon Bar-Lev" <[email protected]>, "Vojtech Szocs" <[email protected]>, > "Einav Cohen" <[email protected]>, > "Itamar Heim" <[email protected]>, "Juan Hernandez" <[email protected]>, > "engine-devel" <[email protected]> > 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 _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
