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.
