I think you may have lost me, but I'll try to respond...
On Jul 23, 2008, at 5:29 PM, Les Hazlewood wrote:
That's a good question. I had always thought that a UrlPermission class would make sense, doing something like this: new UrlPermission( "/some/path/here", "GET" ); But I wonder if the WildcardPermission be used in the same way, just represented slightly differently? For example: new WildcardPermission( "/some/path/here:GET" ); or new WIldcardPermission( "/other/path/there:POST" );
The problem is path globbing which I dont't think WildcardPermission supports.
BTW if you want a nice permission object for URLs, the JACC spec has one that handles the permissions from the Servlet spec. You can find an implementation in the Geronimo project (https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jacc_1.1_spec/src/main/java/javax/security/jacc/WebResourcePermission.java )
I don't know if that would be expressive enough for your requirements, plus because of the comma-delimited nature of WildcardPermission, if the URL had a comma in it at all, it would make things more complicated (requiring escaping or quoting). It is funny that you bring this up - using Permissions were (and still are) my preferred way of controlling access to URLs, instead of the [urls] mapping section that we support in jsecurity.ini or web.xml. Naturally we have to support the [urls] approach because that's what most users want, but in my own applications I would prefer to ignore that entirely and use a UrlPermission concept.
This is where I think you lost me. I assumed that the permission declaration in the jsecurity.ini file turned into permission checks (like JACC). If not, how are you checking these?
If you're restricting access to URLs, then you really are _permissioning_ access to those urls. Permissions make more sense to me to do this, which can be modified and assigned at runtime, rather than statically defined mappings in jsecurity.ini or in web.xml. Doing them in either of these files is essentially defining access control rules in an environment-specific location. If I configure roles and non-URL permissions elsewhere - as I almost always do, such as in an RDBMS - then I've essentially split my access control definitions in two places. That's not consistent or very clean feeling in my opinion, so I would abandon the [urls] definitions entirely. Again, this is my own preference for my applications - most end-users find the [urls] configuration so convenient that they don't care. The good thing is that JSecurity supports either approach, depending on your preference.
I'm have been working with JACC lately where all of the JEE permissions are turned into permission objects, so I'm curious what you are doing instead.
-dain
