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_details] > 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" <[email protected]> > To: "Alon Bar-Lev" <[email protected]> > Cc: "Vojtech Szocs" <[email protected]>, "Einav Cohen" <[email protected]>, > "Itamar Heim" <[email protected]>, "Juan Hernandez" <[email protected]>, > "engine-devel" <[email protected]>, "Barak Azulay" <[email protected]> > 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" <[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.... > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
