hello Stephan, On Saturday 20 December 2008 22:32:50 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 mechanism but a technique to maintain a state which could be used to claim previous alleged successful authentication. even then, i see two problems with Cookies: (a) users can have their Browsers reject them, 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). 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' <login-config> and <auth- method> elements provide. > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=98 >8124 -- cheers; rsn ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=988300
signature.asc
Description: This is a digitally signed message part.
