[Acegisecurity-developer] (no subject)
Greetings, I am trying to set up Acegi (using HTTP BASIC Auth) for a set of RESTful web services (implemented using the Atom Publishing Protocol) And I have the basic setup running. But REST complicates matters because the exact same URL is used for "reads" and "writes", with the HTTP method determining which. I want to set up Acegi so that it will allow different Roles for the same URL but different HTTP Methods. For example class="org.acegisecurity.intercept.web.FilterSecurityInterceptor"> ref="authenticationManager"/> CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /**=ROLE_ALL Would need something like this??? POST /items ROLE_WRITER PUT /items/** ROLE_WRITER DELETE /items/** ROLE_WRITER GET /items/** ROLE_READER GET /items ROLE_READER How would I go about this?? Does Acegi somehow understand REST already?? Any suggestions would be greatly appreciated. Thanks, -- Chris S'all good --- [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] (no subject)
Thanks for the reply! I've been googling for quite a while and haven't come up with too much. This is a bit odd because REST is quickly becoming The Way. Acegi is a nice solution because it is entirely Filter based, and thus, a separate aspect applied externally (via Spring) to the webapp. And Acegi allows for an easy, transparent upgrade to different Authorization techniques (e.g. SSO) as the webapp evolves So I expected to find more interest in REST from the Acegi community?? Anyway, AFAICT, the solution is to provide a custom FilterInvocationDefinitionSource I plan to extend PathBasedFilterInvocationDefinitionMap. And will 1) override getAttributes() which will call lookupAttributes suppling the HTTP method 2) overload lookupAttributes as lookupAttributes( String url, String httpMethod) where the mapping will now look like this:: /foo/bar.html:POST,DELETE=ROLE_FOO (for GET or POST HTTP methods) /secure/*:GET=ROLE_BAR (only for GET HTTP method) /account/something=ROLE_BAR(implies all (Note that this format was suggested in a post by Ben Alex to the Spring forums) Does that sound about right?? It sure would be nice if this was the default (with "implies all" assumed) ;-) Thanks, -- Chris On Aug 21, 2007, at 6:39 PM, Brian Moseley wrote: On 8/21/07, Chris Berry <[EMAIL PROTECTED]> wrote: Greetings, I am trying to set up Acegi (using HTTP BASIC Auth) for a set of RESTful web services (implemented using the Atom Publishing Protocol) And I have the basic setup running. But REST complicates matters because the exact same URL is used for "reads" and "writes", with the HTTP method determining which. I want to set up Acegi so that it will allow different Roles for the same URL but different HTTP Methods. i've implemented this by providing a custom Voter that checks for a hard-coded role name for all read methods and a different hard-coded role name for all write methods. i didn't particularly need flexible role name configuration, and there's never a case in my application where a method can signify a read operation on one resource but a write operation on a different resource (and the only time i can imagine this is when you're overloading POST), this was good enough. i'd love to see a better solution baked into the framework. -- --- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer S'all good --- [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] (no subject)
Unfortunately, this package isn't well suited for extension. I could extend PathBasedFilterInvocationDefinitionMap but since it provides no way to access requestMap & pathMatcher I had to duplicate all of that code. But I could workaround that, what I don't see is how to get around the FilterInvocationDefinitionSourceEditor I want to be able to do something like this: class="org.acegisecurity.intercept.web.FilterSecurityInterceptor"> ref="authenticationManager"/> ref="filterDefinitionMap" /> class="com.homeaway.hcdata.utils.acegi.RESTfulPathBasedFilterInvocationD efinitionMap" > CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /**=ROLE_SUPERVISOR But I don't see how to accomplish it?? Must I extend FilterInvocationDefinitionSourceEditor ?? I'm no Spring expert, so I'm unclear how the Property Editors get wired in... Thanks, -- Chris On Aug 21, 2007, at 7:10 PM, Brian Moseley wrote: On 8/21/07, Chris Berry <[EMAIL PROTECTED]> wrote: Anyway, AFAICT, the solution is to provide a custom FilterInvocationDefinitionSource I plan to extend PathBasedFilterInvocationDefinitionMap. [...] sure, that looks good to me, with the following caveat: to support http-based protocols that extend the basic method set, like webdav with its PROPFIND, PROPPATCH, MKCOL, LOCK etc, and to keep mapping files brief, it might be handy to be able to configure named sets of methods on the FilterInvocationDefinitionSource. perhaps something like this: and: /foo/bar.html:READ_METHODS,WRITE_METHODS=ROLE_FOO /secure/*:READ_METHODS=ROLE_BAR /account/something=ROLE_BAR -- --- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer S'all good --- [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] (no subject)
I managed to answer this one myself, by trolling the Internet and reading the Acegi source. The final answer was to create a RESTfulDefinitionSource. I used Spring constructor injection to load in the "security patterns": class="org.acegisecurity.intercept.web.FilterSecur ityInterceptor"> class="com.homeaway.hcdata.utils.acegi.RESTfulDefi nitionSource" > /**:GET=ROLE_READER /**:PUT,DELETE,POST=ROLE_WRITER The easiest thing was to then delegate within RESTfulDefinitionSource to a RESTfulPathBasedFilterInvocationDefinitionMap, which is essentially a clone of the PathBasedFilterInvocationDefinitionMap. (But one that takes into account Http Methods). I would have liked to extend PathBasedFilterInvocationDefinitionMap, but it is basically not friendly to subclassing. Although I followed the logic of that class almost exactly so that I could be sure that I got things wired correctly. It seems that Acegi might consider this form as the default form?? So that patterns like this /**=ROLE_SUPERVISOR default to "all methods". But patterns like this are also acceptable; /**:PUT,DELETE,POST=ROLE_SUPERVISOR It could be entirely backwards compatible. And Acegi would then support REST!! You might also consider refactoring the org.acegisecurity.intercept.web package. It doesn't lend itself well to extension or variation. Thanks, -- Chris On Aug 21, 2007, at 9:20 PM, Chris Berry wrote: Unfortunately, this package isn't well suited for extension. I could extend PathBasedFilterInvocationDefinitionMap but since it provides no way to access requestMap & pathMatcher I had to duplicate all of that code. But I could workaround that, what I don't see is how to get around the FilterInvocationDefinitionSourceEditor I want to be able to do something like this: class="org.acegisecurity.intercept.web.FilterSecurityInterceptor"> ref="authenticationManager"/> ref="filterDefinitionMap" /> class="com.homeaway.hcdata.utils.acegi.RESTfulPathBasedFilterInvocatio nDefinitionMap" > CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /**=ROLE_SUPERVISOR But I don't see how to accomplish it?? Must I extend FilterInvocationDefinitionSourceEditor ?? I'm no Spring expert, so I'm unclear how the Property Editors get wired in... Thanks, -- Chris On Aug 21, 2007, at 7:10 PM, Brian Moseley wrote: On 8/21/07, Chris Berry <[EMAIL PROTECTED]> wrote: Anyway, AFAICT, the solution is to provide a custom FilterInvocationDefinitionSource I plan to extend PathBasedFilterInvocationDefinitionMap. [...] sure, that looks good to me, with the following caveat: to support http-based protocols that extend the basic method set, like webdav with its PROPFIND, PROPPATCH, MKCOL, LOCK etc, and to keep mapping files brief, it might be handy to be able to configure named sets of methods on the FilterInvocationDefinitionSource. perhaps something like this: value="POST,PUT,DELETE,PROPPATCH,LOCK"/> and: /foo/bar.html:READ_METHODS,WRITE_METHODS=ROLE_FOO /secure/*:READ_METHODS=ROLE_BAR /account/something=ROLE_BAR - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer S'all good --- [EMAIL PROTECTED] S'all good --- [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] (no subject)
Will do. It sure would be nice to incorporate this back into Acegi. IMHO, REST will (or is ;-) supplant all other web service methodologies. Acegi should support it natively. I need to soon do the same work for securing methods by Http Method Cheers, -- Chris On Aug 23, 2007, at 1:16 PM, Ray Krueger wrote: Nice work Chris, any chance you could open some Jiras on that? On 8/23/07, Chris Berry <[EMAIL PROTECTED]> wrote: I managed to answer this one myself, by trolling the Internet and reading the Acegi source. The final answer was to create a RESTfulDefinitionSource. I used Spring constructor injection to load in the "security patterns": ref="authenticationManager"/> ref="filterDefinitionMap" /> /**:GET=ROLE_READER /**:PUT,DELETE,POST=ROLE_WRITER The easiest thing was to then delegate within RESTfulDefinitionSource to a RESTfulPathBasedFilterInvocationDefinitionMap, which is essentially a clone of the PathBasedFilterInvocationDefinitionMap. (But one that takes into account Http Methods). I would have liked to extend PathBasedFilterInvocationDefinitionMap, but it is basically not friendly to subclassing. Although I followed the logic of that class almost exactly so that I could be sure that I got things wired correctly. It seems that Acegi might consider this form as the default form?? So that patterns like this /**=ROLE_SUPERVISOR default to "all methods". But patterns like this are also acceptable; /**:PUT,DELETE,POST=ROLE_SUPERVISOR It could be entirely backwards compatible. And Acegi would then support REST!! You might also consider refactoring the org.acegisecurity.intercept.web package. It doesn't lend itself well to extension or variation. Thanks, -- Chris On Aug 21, 2007, at 9:20 PM, Chris Berry wrote: Unfortunately, this package isn't well suited for extension. I could extend PathBasedFilterInvocationDefinitionMap but since it provides no way to access requestMap & pathMatcher I had to duplicate all of that code. But I could workaround that, what I don't see is how to get around the FilterInvocationDefinitionSourceEditor I want to be able to do something like this: class="org.acegisecurity.intercept.web.FilterSecurityInterceptor"> ref="authenticationManager"/> ref="filterDefinitionMap" /> class="com.homeaway.hcdata.utils.acegi.RESTfulPathBasedFilterInvocati onDefinitionMap" CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /**=ROLE_SUPERVISOR But I don't see how to accomplish it?? Must I extend FilterInvocationDefinitionSourceEditor ?? I'm no Spring expert, so I'm unclear how the Property Editors get wired in... Thanks, -- Chris On Aug 21, 2007, at 7:10 PM, Brian Moseley wrote: On 8/21/07, Chris Berry <[EMAIL PROTECTED]> wrote: Anyway, AFAICT, the solution is to provide a custom FilterInvocationDefinitionSource I plan to extend PathBasedFilterInvocationDefinitionMap. [...] sure, that looks good to me, with the following caveat: to support http-based protocols that extend the basic method set, like webdav with its PROPFIND, PROPPATCH, MKCOL, LOCK etc, and to keep mapping files brief, it might be handy to be able to configure named sets of methods on the FilterInvocationDefinitionSource. perhaps something like this: and: /foo/bar.html:READ_METHODS,WRITE_METHODS=ROLE_FOO /secure/*:READ_METHODS=ROLE_BAR /account/something=ROLE_BAR - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer S'all good --- [EMAIL PROTECTED] S'all good --- [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer -- --- This
Re: [Acegisecurity-developer] (no subject)
Done http://opensource.atlassian.com/projects/spring/browse/SEC-531 Cheers, -- Chris On Aug 23, 2007, at 1:44 PM, Chris Berry wrote: Will do. It sure would be nice to incorporate this back into Acegi. IMHO, REST will (or is ;-) supplant all other web service methodologies. Acegi should support it natively. I need to soon do the same work for securing methods by Http Method Cheers, -- Chris On Aug 23, 2007, at 1:16 PM, Ray Krueger wrote: Nice work Chris, any chance you could open some Jiras on that? On 8/23/07, Chris Berry <[EMAIL PROTECTED]> wrote: I managed to answer this one myself, by trolling the Internet and reading the Acegi source. The final answer was to create a RESTfulDefinitionSource. I used Spring constructor injection to load in the "security patterns": ref="authenticationManager"/> ref="filterDefinitionMap" /> /**:GET=ROLE_READER /**:PUT,DELETE,POST=ROLE_WRITER The easiest thing was to then delegate within RESTfulDefinitionSource to a RESTfulPathBasedFilterInvocationDefinitionMap, which is essentially a clone of the PathBasedFilterInvocationDefinitionMap. (But one that takes into account Http Methods). I would have liked to extend PathBasedFilterInvocationDefinitionMap, but it is basically not friendly to subclassing. Although I followed the logic of that class almost exactly so that I could be sure that I got things wired correctly. It seems that Acegi might consider this form as the default form?? So that patterns like this /**=ROLE_SUPERVISOR default to "all methods". But patterns like this are also acceptable; /**:PUT,DELETE,POST=ROLE_SUPERVISOR It could be entirely backwards compatible. And Acegi would then support REST!! You might also consider refactoring the org.acegisecurity.intercept.web package. It doesn't lend itself well to extension or variation. Thanks, -- Chris On Aug 21, 2007, at 9:20 PM, Chris Berry wrote: Unfortunately, this package isn't well suited for extension. I could extend PathBasedFilterInvocationDefinitionMap but since it provides no way to access requestMap & pathMatcher I had to duplicate all of that code. But I could workaround that, what I don't see is how to get around the FilterInvocationDefinitionSourceEditor I want to be able to do something like this: class="org.acegisecurity.intercept.web.FilterSecurityInterceptor"> ref="authenticationManager"/> ref="filterDefinitionMap" /> class="com.homeaway.hcdata.utils.acegi.RESTfulPathBasedFilterInvocat ionDefinitionMap" CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /**=ROLE_SUPERVISOR But I don't see how to accomplish it?? Must I extend FilterInvocationDefinitionSourceEditor ?? I'm no Spring expert, so I'm unclear how the Property Editors get wired in... Thanks, -- Chris On Aug 21, 2007, at 7:10 PM, Brian Moseley wrote: On 8/21/07, Chris Berry <[EMAIL PROTECTED]> wrote: Anyway, AFAICT, the solution is to provide a custom FilterInvocationDefinitionSource I plan to extend PathBasedFilterInvocationDefinitionMap. [...] sure, that looks good to me, with the following caveat: to support http-based protocols that extend the basic method set, like webdav with its PROPFIND, PROPPATCH, MKCOL, LOCK etc, and to keep mapping files brief, it might be handy to be able to configure named sets of methods on the FilterInvocationDefinitionSource. perhaps something like this: and: /foo/bar.html:READ_METHODS,WRITE_METHODS=ROLE_FOO /secure/*:READ_METHODS=ROLE_BAR /account/something=ROLE_BAR - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer S'all good --- [EMAIL PROTECTED] S'all good --- [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.source
[Acegisecurity-developer] conditional filters?
Greetings, I was wondering if there was a way to conveniently switch off all the Acegi Servlet Filters In testing we generally want to run over straight http And sometimes in Staging we just want to switch off SSL Today, I am using two different web.xml files; one w/ the Filters commented out, and the other not. And it is a PITA to switch back and forth (comment/uncomment) -- or I have to violate DRY and make copies of the "real" web.xml Is there some convenient way to tell Acegi just to "short-circuit" the FilterChainProxy?? Using some kind of variable on startup?? Thanks, -- Chris S'all good --- chriswberry at gmail dot com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] conditional filters?
I went with this solution. I created a ConfigurableFilterChainProxy with the ability to turn off/ on the Filters. It works great. Thanks, -- Chris On Sep 15, 2007, at 11:40 AM, Sharad Jain wrote: Or that other solution could be to extend FilterChainProxy and make it configurable to behave differntly in each environment. Message: 5 Date: Fri, 14 Sep 2007 14:45:43 -0500 From: "Ray Krueger" <[EMAIL PROTECTED]> Subject: Re: [Acegisecurity-developer] conditional filters? To: acegisecurity-developer@lists.sourceforge.net Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 That's really going to be fully dependent on your applications configuration. Maybe break up your Spring xml files so that all the acegi stuff is in it's own file. Then have your app load the right file based on the environment you want. The full file has all the normal Acegi stuff in it. The test environment file would have one single bean in it: On 9/14/07, Chris Berry <[EMAIL PROTECTED]> wrote: Greetings, I was wondering if there was a way to conveniently switch off all the Acegi Servlet Filters In testing we generally want to run over straight http And sometimes in Staging we just want to switch off SSL Today, I am using two different web.xml files; one w/ the Filters commented out, and the other not. And it is a PITA to switch back and forth (comment/uncomment) -- or I have to violate DRY and make copies of the "real" web.xml Is there some convenient way to tell Acegi just to "short- circuit" the FilterChainProxy?? Using some kind of variable on startup?? Thanks, -- Chris S'all good --- chriswberry at gmail dot com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer -- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer End of Acegisecurity-developer Digest, Vol 17, Issue 7 ** -- --- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer S'all good --- chriswberry at gmail dot com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
