On Thu, Jul 24, 2008 at 11:50 AM, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> Wow. This is much more powerful then standard servlet security, because it > takes physical urls and converts them to logical permission. This mapping > abstraction makes permission assignment more stable and understandable to an > admin. Very nice. I was never happy with the way standard servlet security works either, or how difficult it is to do the same thing in Acegi (I'm not sure it is even possible), so I came up with something I thought was better. I'm glad you like it :) Do you all have a similar system for method level checks on a service > object? We have two annotations at the moment: @RequiresRoles( <comma delimited string of role names> ) @RequiresPermissions( <comma delimited string of perm definitions> ); Enabling these annotations is very AOP-framework dependent. So far, we have support for Spring environments using Spring AOP (technically AOP Alliance actually), but not much else. We don't currently have any @Authenticated or @User or anything like that. If we did, they would probably have a 1-to-1 correspondence with our JSP tag library. Is this what you're talking about? - Les On Jul 24, 2008, at 7:10 AM, Jeremy Haile wrote: > > Also, it's important to note that the URL matching in the [urls] section >> of jsecurity.ini uses ant-style path matching, so you have a lot of >> flexibility in defining complex paths such as: >> /myapp/**/images/* = anon >> >> You can also do role based checks by using the roles filter, like so: >> /myapp/**/admin/* = roles[admin] >> >> On Jul 24, 2008, at 9:45 AM, Les Hazlewood wrote: >> >> 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. >>> >> >> >
