Since JAAS only provides a framework, ( policy files etc are only
designed for small deployments, they don't scale) I've often wondered if
we should be providing a "default framework".
Apache Shiro is an interesting project, it's probably worth
investigating too.
Cheers,
Peter.
Peter Firmstone wrote:
Gregg Wonderly wrote:
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".
To implement roles in JAAS, you can create a Role implementation like
this:
public class Role implements Principal, PrincipalComparator {
// implementation ...
}
public interface PrincipalComparator {
boolean implies(Subject subject);
}
Yeah, I know it's a com.sun interface.
Javadoc from com.sun.security.auth.PrincipalComparator:
/**
* An object that implements the
<code>java.security.Principal</code>
* interface typically also implements this interface to provide
* a means for comparing that object to a specified
<code>Subject</code>.
*
* <p> The comparison is achieved via the <code>implies</code>
method.
* The implementation of the <code>implies</code> method
determines
* whether this object "implies" the specified
<code>Subject</code>.
* One example application of this method may be for
* a "group" object to imply a particular <code>Subject</code>
* if that <code>Subject</code> belongs to the group.
* Another example application of this method would be for
* "role" object to imply a particular <code>Subject</code>
* if that <code>Subject</code> is currently acting in that role.
*
* <p> Although classes that implement this interface typically
* also implement the <code>java.security.Principal</code>
interface,
* it is not required. In other words, classes may implement the
* <code>java.security.Principal</code> interface by itself,
* the <code>PrincipalComparator</code> interface by itself,
* or both at the same time.
*
* @version 1.17, 05/05/07
* @see java.security.Principal
* @see javax.security.auth.Subject
*/
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.
Hang in there, this is difficult terrain and it isn't well understood,
people don't always digest the info.
I find it's hard to get feedback too, Fred Oliver has been most
helpful, so I'm hoping he's still following the list.
Many developers would like to ignore security, a benefit of Aspect
programming is you can weave in security later...
Basically, think of these steps as the process.
1. Design the service interface.
I'm interested, I've been thinking about this too, what's your current
service interface?
Cheers,
Peter.
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
