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