On 8/9/2011 3:56 PM, Greg Trasuk wrote:
Comments below... On Tue, 2011-08-09 at 12:39, Gregg Wonderly wrote:I too believe that Authorization is not served well by Subject, at all. The reason being that it is not "Role" oriented, but rather "permission" oriented and the "permission set" is not always the right "mask" to set in front of a decision process, without a lot of permissions that soon become confusing to manage without some sort of structured view such as a simple "database" or "collection view". What I did, was create a mechanism that uses "XML" to specify what is needed for each method in an interface. I've posted about this before, and have not really received much feedback either way about it, so I'll hang it out on a stick again. Basically, think of these steps as the process. 1. Design the service interface. 2. Take each method, and decide what Roles use those methods and note the roles in a list. 3. Decide what types of objects will need to be controlled by role based access. 4. Design permissions that use the values of arguments to the methods to segregate access based on role as needed.I pretty much agree. You've also added in the idea of role-based access to data objects, not just methods, which is cool. If I were going to implement this, I'd want to make sure we had: 1 - A pluggable Subject -> Role and Subject -> Group -> Role mapping mechanism. You might want database, text file, LDAP, or some other service-oriented system.
I have support for groups. Historically, I've used group names for "role" names with my customers. Then, you just put people into the groups that you want them to participate in the roles thereof.
2 - Annotation-based config as an alternative to XML. I tend to think you need XML in case you can't (or don't want to) annotate the original interfaces or classes, but if you have source access, annotation makes for a much cleaner configuration. Separate metadata gets tedious after a while (just ask anyone who's used EJB2).
My design was driven completely from the fact that I didn't want "developers" deciding on "authorization design" as part of their development, too much. Keeping authorization on the outside in the form of a "proxied" object, also allows you to "test" without any of that in the mix which simplifies test logic, and allows "pluggable" dummy objects to be used for testing the "authorization" proxy object. It separates the two quite well, but also allows you to doctor up the dummy object with appropriate exception logic to test the client with as well, all locally.
The important thing here, I think, is the observation that JAAS is not so useful for authorization as it is for authentication.
Yes, that is the important thing to me. Subject is interesting, but using the JVMs policy is just too crippling from a number of perspectives.
Gregg Wonderly
