Hi all, Let's continue this discussion in the developers mailing list.
See my reply there: http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458&dsMessageId=1022072 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 3 janvier 2009 00:19 A : discuss@restlet.tigris.org Objet : securing Restlet 1.2 hello all, i went through the 13 "High priority enhancements for Restlet 1.2" in the "Requirements" section of "Security re-factoring" found here (http://wiki.restlet.org/developers/172-restlet/212-restlet.html) and tried to classify them in order to come up with an implementation plan. here are my thoughts: * the only one comprehensive approach for covering Authentication and Authorization needs is JSecurity ([I658] Add support for JSecurity). if implemented, this would IMO also achieve: # [I288] Support pre-emptive authentication # [I503] Give access to connector authentication # [I504] Add notion of realm # [I605] Support cookie based authentication the other requirements, excluding [I505] Re-factor authentication and authorization, can be classified as: * add support for more/other authentication mechanisms. these could be achieved by implementing JSecurity classes (in org.jsecurity.authc packages) either in the JSecurity project, or here and contributing them to that project: # [I444] Support SPNEGO authentication # [I446] Support OpenID authentication # [I447] Support JAAS authentication * improving the current mechanisms. these could be achieved by designing the framework to allow (at least the Guard) to inject security constraints and have the (Guard) methods delegate the work to the security framework. this way the existing (and future) work done on the Guard would not be lost or in need of (too much) re-writing: # [I485] Support htpasswd encrypted files in Guard # [I567] Improve HTTP Digest support # [I606] Improve OAuth extension # [I634] Guard.checkSecret should accept a Response object i'm seeking feedback on the following proposed plan: * adopt JSecurity (http://www.jsecurity.org/) as the base Authentication and Authorization provider for Restlet. their code is published under an Apache 2.0 Open Source License, and the project itself is in incubation state for becoming an Apache product. * hide as little as possible JSecurity classes in Restlet. this basically means adding a dependency to the Restlet Core on the JSecurity JARs --for JDK 5 and later, the following is a minimum (when the security services are enabled): jsecurity.jar, commons-logging.jar; for heterogeneous clients, SSO support: ehcache.jar, and backport-util-concurrent.jar. * add one service (SecurityService in org.restlet.service) and enough classes in Restlet (mainly org.restlet.security package) to configure, enable/disable and use the JSecurity classes. * re-factor Guard to re-use the above so its existing sub-classes can continue to work unchanged. at a later stage, i think it could be beneficial to look at how we can configure and use this security framework separately or in collaboration at the Component, VirtualHost and Application levels. cheers; rsn ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1000150 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1022074
