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

[Michael Pasternak]

On 05/16/2013 08:58 PM, Alon Bar-Lev wrote:
> 
> 
> ----- 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 12:27:35 PM
>> 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,
> 
> I am taking exactly on that... good on demand authentication mechanism should allow concurrent multiple users processing. This is what API is all about.

works like a charm with today's authentication methods.

> Of course this can somehow achieved via cookie, but doing so is so complex that one probably wish to use plain header, 

complex only for browsers.

> or worse case a cookie that does not conflict with the application that loaded the static content.
> 
>> 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)
> 
> Because of this, authorization mechanism should not use cookies.

?, sorry, you lost me.

> 
>>>>>
>>>>> 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.
> 
> Yes they are, they cannot provide challenge response sequence required to establish trust.

you're right the GSSAPI negotiation mechanism is nowhere near the standard cookie auth, however
we where talking about passing the password over the wire, and this is what my response was
about, not conceptual differences between SPENGO & session-cookie+ssl auth.

> 
>>
>>>
>>>> "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.
> 
> I know very few principles that have no exceptions in software engineering.
> 
>>> 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.
> 
> Per your interpretation.

this is not correct, you're welcome to read Roy Fielding doctoral dissertation on
top of which REST was build, (that's what i did before my first reply on REST related
threads).

and to put the things on a right shelf (so i won't be wrongly interpreted again),
i have nothing against the SPENGO - just nothing, my problem is forcing users to
access dedicated URI for authentication/authorization (as was suggested by
you) before being able to fetch/change resource representation.

again don't get me wrong, i'm not justifying Cookies (actually i even wasn't the
one that decided to use this mechanism), but saying "I know very few principles that
have no exceptions in software engineering" is not helping, anything can be done
differently, the question is 'why?' (i'd agree with this only if auth could not be
made differently, but obviously this is not the case)

>  
>>>
>>>> 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.
> 
> But will force you to face more issues in future.
> 
>>> 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
> 
> I am tired to answer this over and over...
> 
>>>  
>>>>>
>>>>> 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,
> 
> So happy to know!

Alone, none is trying to offend you, or your knowledge, just that a lot of people
CC'ed in this tread, so in sake of fair discussion (have everyone in sync), i'm
going to these levels.

> 
>> 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.
> 
> REST accept cookie that was obtained from former authentication, so it breaks your above statement.
> The cookie can and usually is acquired by different URI.

i never said this.

> 
>> now saying this i think is clear that you have no place to put at the login()
>> method you've mentioned,
> 
> Exactly from which you took the cookie, in your language from the Session resource.

:), you told something completely different at the beginning, it was:
"we better force people to use single URI to perform the login and return authenticated 'ticket'",
now by saying "session resource", i'll assume that you mean any resource (cause cookie can be obtained
from the any URI), e.g

/api
/api/vms/xxx
/api/vms/xxx/disks/yyy

i.e any of these can serve as an entry point to api and a place to obtain the ticket from,
and this is how it works today btw.,

so IIUC, this is one of the ways to go.

>  
>> 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.
> 
> Well, it is  clear that this is not a discussion, but dictation...
> So do whatever you think...

this is not true, if it was like this i wouldn't start this discussion
to begin with,

the power of OS is that a lot of people sharing theirs knowledge and
at the end best approach is chosen,

not agreeing on some part/s of suggestion != exclusive locking, i'm
always open for new ideas and ready to learn from others.

>>> Regards,
>>> Alon
>>>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D