[Engine-devel] [REST-API] Support passing auth information without having to use HTTP Authorization header #958874
David Jaša
djasa at redhat.com
Tue May 14 15:49:20 UTC 2013
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" <mpastern at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "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>, "Barak Azulay" <bazulay at 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 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....
>
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3790 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130514/5d5b26c4/attachment.bin>
More information about the Engine-devel
mailing list