> > the framework already defines an exiting object model which includes > principals , roles , groups , permissions , tokens , etc ...
You're right, this is an object model, but it is not a data model backed by a datasource. Our mechanisms only facilitate data models that you define. For example, a PrincipalCollection is used by JSecurity internally to wrap one or more principals. But your principals can be whatever you want - a String, an Integer, an Object, Collection, etc. We perform Role checks based on String names - that a Role class might exist is purely up to your application. Permissions are interfaces that can be implemented in a java Class, or you can just use Strings, and JSecurity can automatically convert them to objects as it sees fit. There has been a lot of work to make these constructs as flexible as possible to work with any data model. the aspects for querying them are well defined , how does defining aspects > for creating , updating and deleting them , limits implementation? > Its not so much as the implementation of how to perform CRUD operations, it is instead the idea that your data model would be forced to conform to our expectations. The large majority of our end-users can't be forced to use our ideals - they have 3rd party systems and legacy applications to use, and quite often can't change anything in these systems to make life with JSecurity easier. This is why we've abstracted away these details into something that an end-user can write themselves (AuthenticationInfo/AuthorizationInfo) that would never intrude on their own data model. > i am also going to make a very bold statement , and say that any > application that requires row-level or method level access control , will > have core requirements that include roles , groups , permissions, etc..., > and CRUD operations for all of them. You're right, but _how_ exactly should that happen? I define a Group as a collection of User objects. I define a Role as a collection of Permission objects. But what if, in your application, a User also has a collection of Permission objects? My applications don't do that - every User has a private Role, and any per-User permissions are assigned to that private Role - not directly to the user. But your application may not like that idea. Also, many applications don't use Groups at all - they're quite happy with just Roles. Many apps don't even use Permissions. Can a Group have Roles assigned as well? In my application they might be able to, but in your application, you might not have that association. Then, what if your user management is backed by LDAP? There are no Group/Role/Permission java mechanisms in LDAP - they have their own constructs to determine how that stuff is managed. And, it is usually the case that these things are managed entirely outside of the JSecurity-enabled application. These reasons, and a bunch others, are why we can't enforce an object model - there are so many data sources that exist, that we couldn't cleanly support them all in a pluggable manner if we defined a 'gold standard' data model. i am not sure that one size fits all is the best option. Exactly my point above. I think we're in agreement :) > Take my case for example I'm writing a new app from scratch; no legacy , no > limitations , i just don't want to write again the same code that i wrote > numerous times before for other companies , which ends up looking identical. Now we *might* be able to specify a set of interfaces and default implementations that make this much easier for 80% of end-users out there, especially if their app will be RDBMS-backed. But if we ever did this, it would be in addition to the already-flexible mechanisms in place. It would never be required for a jsecurity user to use them. That is why the sample apps exist - to help fill in the gaps of what JSecurity supports out of the box vs what would be a best practice that we can't enforce. please don't take my comments as any kind of criticisms with regards to > JSecurity , it is a great library, and much better then anything out there , > including Acegi; I'm just trying to encourage discussion and maybe affect > the roadmap. I don't feel this is criticism at all - I'm really happy that you made your thoughts known, and they're really good ideas - if you'd like to see a default object model supported in addition to the flexible mechanisms already in place, please, by all means, open a Jira issue. I think a lot of people could benefit from what you describe. We would first all need to discuss how to do that cleanly, and without confusing users so they don't think those interfaces are required. there is always the valid option that i might have defined my requirements > in the wrong way , in which case , i hope that this discussion will point me > in the right way. Absolutely - and we're glad you asked - it is certainly a worthwhile discussion :) Cheers, Les
