Hello,
(OT: does anyone know why the beginning of this thread and a few other
messages don't seem to have made it to Gmane recently?)
Admittedly, I don't know much about the security implementation in
Spring, but this looks like the right way to do it. I had started to
work on something similar (without Spring) after starting this thread
back in May [1].
The problem is that the I've tried to use the existing Guard and related
classes to keep it compatible with the 1.1 branch, so the result is a
bit convoluted. I've also been straight to the features that I needed,
but haven't finished the more general implementation. Now that 1.1 has
been released, it might be a better time to do this.
I'd be willing to put this code into the Restlet subversion repository,
but it should be treated as experimental (and unfortunately, not
particularly clean). Jerome, any preferred place to put this code? (I'll
also put the SPNEGO filter that I've been planning to commit for a long
time.)
Best wishes,
Bruno.
[1] http://restlet.tigris.org/servlets/ReadMsg?list=discuss&msgNo=5328
Karel Vervaeke wrote:
I recently made a stab at spring security integration for Kauri. There
is not much yet and it's Kauri-specific, but it gives more flexibility
than the existing spring-security integration IMHO.
(http://code.google.com/p/restlet-spring-security/)
Here's how it works in a bird's eye overview:
The spring security filters (ServletFilters) that process authentication
(basic, digest, PKI, ...) are replaced with
"AuthenticationRequestProviders (ARPs)".
An ARP tries to find an authentication attempt in the request.
(e.g. the BasicARP looks at WWW-Authenticate headers, the
BrowserIDBasedARP looks at a BrowserID cookie, ...).
The ARPs are registered with the KauriSpringSecurityFilter (which is a
restlet Filter). The filter loops over the ARPs until one of them
returns a non-null Authentication object and tries to validate it using
Spring's AuthenticationManager and AccessDecisionManager.
On top of that there is the concept of Realms (to make it possible to
have different URIs map to different security configurations).
We still intend to add the concept of 'authentication strength' which
should make it possible to let an application request a specific
authentication scheme).
I really made a serious attempt to use Restlet's Guards, but in the end,
we thought it better to just write a filter.
Here is an example configuration snippet, it should give a rough idea of
how things are configured:
<realm>
<authentication-request-providers>
<authentication-request-provider moduleId="security"
beanId="basicARP"/>
<authentication-request-provider moduleId="security"
beanId="browserIdARP"/>
</authentication-request-providers>
<authentication-manager moduleId="security" beanId="authManager"/>
<access-decision-manager moduleId="security"
beanId="accessDecisionManager"/>
<modules>
<module id="my-module1">
<protect path="/user" access="ROLE_USER"/>
<protect path="/admin" access="ROLE_ADMIN"/>
<protect path="/data" method="PUT" access="ROLE_ADMIN"/>
<protect path="/data" method="GET" access="ROLE_USER"/>
</module>
</modules>
</realm>
http://www.kauriproject.org/issues/browser/trunk/core/kauri-runtime/src/main/java/org/kauriproject/runtime/auth/KauriSpringSecurityFilter.java
Regards,
Karel
On Mon, 2008-11-03 at 17:30 +0100, Stephan Koops wrote:
Hi Jerome,
also if we already talked about this: better authentication and an
authorization. I also want to give input to it, if it is time for that.
best regards
Stephan
Hi all,
Could you tell me, from your point of view, what are the three most
important features missing from Restlet ?
__________________________________________________________________
"Run, Fatboy, Run" sowie "Rails & Ties" kostenlos anschauen!
Blockbuster-Gutscheine sichern unter http://www.blockbuster.web.de
