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. 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). The important thing here, I think, is the observation that JAAS is not so useful for authorization as it is for authentication. Cheers, Greg.
