Re: fine grained security with SubjectTrackingMBeanSe rver example

Alper Akture <[email protected]>
Newsgroups gmane.comp.java.mx4j.user
Message-ID <DB67197B2E16D411831E00508B71566902622ED7@caysapp001.intersperse.com>
Thanks to both for the help! That clears up the mystery for me. I think I
could do the work around, or use a policy file in addition to the
MBeanServerForwarder for now to solve my issue.

Alper

-----Original Message-----
From: Luis-Miguel Alventosa [mailto:[email protected]]
Sent: Wednesday, June 28, 2006 7:34 AM
To: Simone Bordet
Cc: [email protected]; [email protected]
Subject: Re: [Mx4j-user] fine grained security with
SubjectTrackingMBeanServer example


Hi Simone,

Well, I think this issue is not an easy one because you have pros and
cons on each possible solution.

Sun's implementation of the connector server tries to differentiate
when a call is made on behalf of a remote user and when a call is made
on behalf of the connector server itself.

When using a security manager and a policy file there aren't any issues
because the remote user calls are checked against the remote user codebase
plus Subject whereas the connector server calls are checked against the
connector server codebase.

The issue arises when an MBeanServerForwarder is put in between the
connector server and the MBeanServer. When an MBeanServerForwarder
is used any call whose destination is the MBeanServer will go through
the MBeanServerForwarder. This means, in Sun's implementation, remote
user calls will have a Subject whereas connector server calls will not
have a Subject (unless you login to your application at startup and
set a Subject for the connector server itself).

I don't know how you did implement this in MX4J but I'm not sure the
remote user call should have more privileges than needed.

If the connector server needs addNotificationListener permission and
getClassLoader permission and getClassLoaderFor permission in my opinion
it's not a great idea to give these permission to the remote user because
he/she is not supposed to have access granted to these methods.

If the connection to your agent is secure (password files/SSL/...) you
could write your MBeanServerForwarder based on the following policy:

- if Subject is null then this is a connector server call that shouldn't
   be blocked/forbidden/stopped

- if Subject is not null then this is a remote user call that should be
   checked against your custom access rights.

Of course, this policy may not be acceptable in many cases so I will
praise people to use a Security Manager plus a policy file for such
more advanced cases.

Let me know what are your thoughts.

Regards,
Luis

 > Simone Bordet wrote:
 >
 > Hi Luis-Miguel,
 >
 >
 >>When the JMX client calls mbsc.addNotificationListener() for the first
time
 >>the connector server needs to register a listener on the
MBeanServerDelegate
 >>MBean to listen for register/unregister MBean notifications. This call is
made
 >>on behalf of the connector server (and not on behalf of the authenticated
user)
 >>and thus no Subject will be available in the thread's context but the
call will
 >>still go through the MBeanServerForwarder (i.e. your
SubjectTrackingMBeanServer)
 >>and that's where your code throws a NullPointerException.
 >
 >
 > This is an implementation detail of the RI, and IMHO it is bad that it
 > behaves this way, breaking the least surprise rule.
 > If I am calling the remote MBeanServer *once* to add a listener, why
 > the forwarder gets called *twice* ?
 >
 >
 >>A solution to this problem might be having a special case for adding
listeners
 >>to the MBeanServerDelegate MBean in your MBeanServerForwarder where a
null
 >>Subject might be accepted.
 >
 >
 > This is even worse, because you cannot distinguish when a call is
 > really made without credentials, or it's an implementation artifact.
 > How can I distinguish when I should reject the call (because there are
 > no credentials) or let it through (because it's an implementation
 > artifact) ?
 > Furthermore, this solution makes code non-portable and heavily
 > dependent on the implementation used, which was the reason JMX was
 > standardized.
 >
 > I consider this a bug of the RI. Your thoughts ?
 >
 > Simon

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Mx4j-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mx4j-user

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.