On Dec 20, 2008, at 6:49 PM, Raif S. Naffah wrote:
> On Sunday 21 December 2008 09:05:46 Rhett Sutphin wrote:
>> On Dec 20, 2008, at 3:34 PM, Raif S. Naffah wrote:
>>> hello Stephan,
>>>
>>> On Sunday 21 December 2008 00:41:48 Stephan Koops wrote:
Hi Raif,
Another possibility to not require the browser login prompt
is to
use an AJAX reqeust and set the credentials in it. I've
implemented
this, but I needed a new return status for it, because if the
server
returns 401 (authentication required / invald) to the client,
then
the browser would open a login prompt. If needed, a could
attach it
to issue 505
It is also good, if it is allowed to have multiple
authentication
mechanims allowed for one resource, e.g. with cookies as
descibed
above for browsers and with a HTML authentiction for software
clients, which requesting e.g. XML or JSON.
>>>
>>> correct me if i'm wrong but if the aim of the Authentication
>>> is to
>>> assert "who are you" then your identity should be the same
>>> whatever
>>> Authentication mechanism was used. in that respect _one_
>>> Authentication mechanism should be enough. on the other hand,
>>> "what
>>> are you allowed to do" (incl. what type of Representation for a
>>> requested Resource) is the domain of Authorization. in that
>>> respect
>>> one (of potentially several conditions, incl. for example the
>>> time-of-day) for authorizing a type of Representation could be
>>> the
>>> "grade" of the Authentication mechanism used to establish your
>>> identity; i.e. an Authentication mechanism based on a personal
>>> X.
>>> 509
>>> Certificate has a higher grade than one based on non-encrypted
>>> user-name and password.
>>>
>>> what could be gained though from having an "aggregation/
>>> compounded"
>>> style of user-credentials gathering mechanisms would be to
>>> increase
>>> the trust in the established identity. e.g. i would have more
>>> confidence in your identity if i can check your credentials from
>>> two
>>> separate sources; as a consequence i can then authorize you to
>>> do
>>> more.
>>
>> Here I was not precise enough: I meant alternative authentication
>> mechanisms, not both must be passed.
>> If I use a software client (web service), than basic or digest is
>> fine, but if the client is a browser, than the cookie based may
>> be
>> better, because it allows corporate design: I think, a reason for
>> not
>> using REST styled web apps in the commercial is, that
>> authentication
>> in corporate design is more difficult than with Servlets: If the
>> developer says to the manager: We have two alternatives: One
>> allows
>> corporated design to be used easily, and the other options has
>> problems with it, what would he say? Right, he will say: "Use the
>> options which allows it".
>
> i see what you mean but just to clarify: Cookies per se are not
> an
> authentication mechanismbut a technique to maintain a state which
> could
> be used to claim previous alleged successful authentication.
Right, I fully agree with you; that was my idea.
> even then, i see two problems with Cookies:
> (a) users can have their Browsers reject them,
Yes, I know. That is really a problem.
> and (b) they contradict the REST principle (see section 6.3.4.2 of
> R.
> Fielding dissertation
> http://roy.gbiv.com/pubs/dissertation/evaluation.htm).
You are right, that cookies produces problems, if they contain
application state, e.g. to match a Servlet session. But IMO it is
not a
problem, if you only save, that the user is logged in and it's user
name
(perhaps secured by an additional crypto hash or something like
that).
> i agree with you that allowing Restlet users/developers to plug-in
> their own customized log-in form where user credentials can be
> obtained
> will be a selling point. this i think can be achieved by
> implementing
> in Restlet something similar to what the Servlet specs' config>
> and elements provide.
And how do a Servlet Container check the authentication? It could
only
set a cookie or use a session and save it in the session. No we
have
back the cookies, or - worse - a session.
>>>
>>> but doesn't the current Guard implementation obviate the need for
>>> both
>>> sessions and cookies, and yet provide us with basic authentication?
>>> if yes,
>>> then a solution for providing customizable form-based login could be
>>> to
>>> extend its capabilities to allow declaring and re-directing to a
>>> resource
>>> URI to
