river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Ease of use, development & deployment
Date Wed, 10 Aug 2011 02:37:34 GMT
On 8/9/2011 7:57 PM, 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?

The service interface is "the service interface".  The mechanism just uses a 
proxy, delegating object.   Thus, if you currently have a service object, you 
just create an instance of your security object, passing in the service object, 
and then export the security object for remote use.

That keeps you from having to support a "single" role model by having that 
codified into your application.  Instead, the service can be deployed with an 
arbitrarily complex authorization implementation making it quite flexible.  You 
can even use Configuration to specify the security implementation class.

Gregg Wonderly

Mime
View raw message