I've added Raif's comment about Tomcat realms to this issue: "Add notion of realm" http://restlet.tigris.org/issues/show_bug.cgi?id=504
Regarding the plumbing, we have a design approach for Restlet that says that everything should be configurable programmatically first (via the Restlet API). Then, on a case-by-case basis, we can offer alternative ways of configuring the Restlet API beans (ex: Component and connectors for now, Application and guards in the future). I agree that things that are likely to be changed by an administrator should be modifiable without recompilation, but there are many ways to support this scenario. Using local static XML/JSON/properties files is just one way. Some alternatives are REST APIs, HTML console, GWT console, JMX, database. Finally, I very much agree on the ideas of authentication grades and impact on authorization. I've added them in the "Analysis/Synthesis" section: http://wiki.restlet.org/developers/172-restlet/212-restlet.html Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -----Message d'origine----- De : Raif S. Naffah [mailto:tig...@naffah-raif.name] Envoye : samedi 20 decembre 2008 01:01 A : discuss@restlet.tigris.org Cc : Stephan Koops Objet : Re: securing Restlet hello Stephan, my comments are in-lined. On Friday 19 December 2008 19:49:12 Stephan Koops wrote: > Hi Raif, > > I think it is good, if a developer could build a HTML application with > Restlet, where he could give a typical login HTML web page and the user > could login without the browsers HTTP authentication prompt (because you > can't design it and so on). In Servlet apps you typically use sessions, > but this we don't want. But we can use Cookies for it, which shows, who > is logged in. It would be very good, if we (optionally) use a cryptical > check, so that nobody could create it's own Cookie by hand to fake a > logged in user. > This should be a ready-to-use-class a developer could instantiate, plug > an authentication mechansim in it (Basic, Digest, ...), an authenticator > (against a file (as in apache e.g.), a database, a JSecurity, ...) and > go. yes. this is where i started from: essentially a clone of what is available with servlets in Apache Tomcat. if we have this in Restlet then a developer would be able to configure Authentication based on credentials accessed from different Realms. this with developer's own HTML (JSP really) form provided the user-name and the password fields are specifically named. the page here (http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html) has more details. plumbing-wise i thought of using the restlet.xml as the primary way for configuring the Realm. directly using the classes should also work albeit is not recommended. for one, you don't want to modify and recompile your code if you decide later you want to use another Realm, and two, sometimes choosing which Realm to use is the privilege of the Administrator running the application not its developer. > 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. > best regards > Stephan > > Raif S. Naffah schrieb: > > hello all, > > > > as a follow up to my original post re. contributing to the project (see > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId= > >981057), and after digesting the suggestions and responses that > > followed, here's a summary of the discussion threads and issues (see > > list at the end) related to the above subject i was able to find > > to-date. pls. let me know if i missed, mis-interpreted, or overlooked > > anything pertaining to the issue: > > > > * there's a recognized need for better, more pluggable authentication > > and authorization (AA) capabilities within the Restlet project. > > > > * successful integration with both Spring Security (Acegi Security > > http://acegisecurity.org/) and JSecurity (http://jsecurity.org/) were > > reported. > > > > * the Guard class does not seem to always suit developers' needs when > > it comes to integrating external security libraries to offer AA > > capabilities. Filter was used successfully and Resolver was suggested > > for authorization needs beyond URIs. > > > > * there was no direct mention about securing the Restlet library code > > itself separately from users application; e.g. if using the Java SE > > Security what would be a conservative security policy and permissions > > to use/grant. > > > > * it's unclear (to me at least) whether the desired outcome is to > > integrate one (of many) external security library, or build within > > Restlet a "commons" layer and artifacts (configuration data) to allow > > (and map to) different ones. > > > > the other two subjects mentioned in the other post remain of interest > > to me as well. i look forward to the input of the project maintainers > > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=98 >7262 -- cheers; rsn ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=987927 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=992844
