> In my application we have been using T2 "groups" as what I think you are > referring to as ProjectGroups, instead of "groups" as methods to > restrict access per application. Under T2 I have deduced that this > kind of scheme was the intent:
[snip of a long and interesting description of alternate security needs] These are all good points. That got me started thinking that perhaps we ARE trying to do too much with Turbine's security system. Perhaps we should just focus on answering the following questions: * Are these credentials valid for this user? * Change the credentials for this user. * Does this user have this capability? Period! Maybe just provide those services in a pluggable way within Turbine, and be done with it. This means leaving out of Turbine the following concepts: * The abstraction for how users and permissions are grouped (permissions as part of roles, users belonging to groups, etc.), given that the grouping can be very different for different apps. * The methods to administer that grouping. * Where and how the security information is stored (DB, LDAP, NT, etc.). In favor of this position, let me remind you that JAAS is a role-based abstraction. Well, what if you really DO NOT want or need roles at all within your app? I LIKE roles, but I certainly think there might be apps where role-based security is not the answer. Just trying to be open minded (and playing devil's advocate), -- Gonzalo A. Diethelm [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
