On Jun 30, 2012, at 2:39 AM, Dan Creswell wrote:

> I'd also suggest that too much permission is granted because the current
> Java security infrastructure inevitably works on a highly granular level
> with long lists of detailed security options for this or that. That brings
> a lot of overhead and complexity. Unix filesystems essentially reduce the
> problem to user, group, other that classification whilst sometimes unwieldy
> also makes for a level of sanity in terms of the number of permissions that
> need playing with or expressing.
> 
> It seems to me that we should be looking at similar tactics for
> grouping/abstracting that take out the need to hit a long list of very
> granular permissions.

This is the whole, complete and total issue from my perspective.  For me, Java 
permissions represent the totality of exposure you want to give the system, to 
your software.  It has nothing to do with what "roles" or "users" need, it's 
just a ton of detail, which practically might be different from day to day, 
deployment to deployment and otherwise creates tedium which, turns people off.

For me, the services "features" are what I want the user to be controlled with. 
 At the method level, I want to be able to say "which role" gets to use "which 
arguments".  This can turn into a lot of tedium too though.

However, I really feel it makes more sense to say things like the following 
which enumerate "functions" which certain roles can perform.

admins -> browse,add,edit,delete,admin
techs ->browse, edit
viewers->browse
managers->browse,add,edit,delete

If you create this kind of role mapping, and then take each of the services 
methods, and lump them into one of the functions, you've mapped out a decently 
concise view of what you need to happen.

My http://java.net/projects/authlib project provides a complete mechanism which 
allows you to formulate XML descriptions of this type, and from that XML, 
generate delegating service classes, which then use a JDBC database, to 
load/maintain an in memory view of the security model. 

There is an admin ServiceUI which lets you create all the roles and permissions 
etc.  

I suspect that this seems quite complicated, compared to managing permissions, 
but, it actually allows you to configure security using what I feel is the 
right domain of details, which then makes it a lot easier to actually use 
security.

Gregg Wonderly

Reply via email to