> 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.
That's true - it doesn't parse the path - just checks for token(s) equality or the wildcard. > > 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. > > In retrospect, after remembering exactly how the JSecurity filter works - I think I have to retract this statement. I forgot how incredibly powerful the [urls] config support actually is - way more powerful than just permission checks (see below). 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? The permissions defined in the [urls] section are turned into actual permission checks. But the URL paths defined in the [urls] section aren't 'permissioned' per se - it is up to how the user configures the Filter: In the web.xml or jsecurity.ini [urls] section, each url pattern (Ant path expression) maps to a user-defined filter chain. This means that for any explicit url (or url patterns, like /app/user/*), an arbitrary filter chain can execute. The URL that is matched against a predefined path/pattern is only 'permissioned' if the user defines the permission filter in that chain. For example: [urls] # This says that for the url path '/some/path', the user has to be # authenticated _and_ have the admin role. If they are not # authenticated, the 'authc' filter will automatically redirect them # to the login page so they can log in, then after a successful log-in, # redirect them back to '/some/path' so they can see what they # originally requested. At that point, if they don't have the 'admin' # role, they are shown a page (if configured) that says they don't # have the ability, or if no page is configured a 403 Access Denied msg. /some/path = authc, roles[admin] # This says that any user visiting '/newsletter/edit*' urls, they must have # the 'newsletter:edit' permission. /newsletter/edit* = perms[newsletter:edit] So, you see that any url - or more correctly, path expression - can be 'permissioned' using the 'perms' filter in that particular path's filter chain definition. And yes, the permissions defined for the perms filter do result in real permission checks. Its just we don't convert the path itself into a permission object - that is defined arbitrarily by the end-user in the chain definition. The benefit of this is that the user can specify any filter in their chain, and we provide a decent amount to get started (form-based authentication filter, HTTP Basic Authentication filter, roles, perms, anonymous/passthrough, etc). This is more flexible for security policy definition in the web tier because not only are the normal 'you can do this / you can't do this' checks enabled (as permissions do), but you also get the added functionality of redirecting users, handling responses directly, implementing HTTP protocols (HTTP Basic), and anything else that a Filter can do. Very powerful stuff indeed. > > 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. So, in summary, the [urls] support provides actual permision checks, but through the above chain-mapping technique with the 'perms' filter (which in turn uses actual string-based permission definitions as necessary), not, say, by instantiating UrlPermission instances. I hope that helps! Please let me know if you need more clarification.
