Re: RE: [Mx4j-user] RE: mx4j-Bugs-969175: Security and delegation

Ron,

I have logged a Request For Enhancement for this, which you should soon 
be able to see on bugs.sun.com with bug id 6173706.  My current feeling 
is still that this is too specialized an application to justify 
supporting it in the generic API, especially since a way does exist to 
implement it with the existing API.  However, if people chime in on 
bugs.sun.com to say that they also think it's a good idea, we could 
consider including it in JSR 255 (JMX API 2.0).

Regards,
-- 
Éamonn McManus, JSR 255 Spec Lead

Ron Vered wrote:
> Eamonn,
> 
> Thank you for detailed response.
> We implemented something very similar to what you propose. It would be nice, however, if you could do it in a straight forward manner, maybe in a way similar to what I suggested. This way, connection reuse will happen explicitly for ALL TRANSPORTS without hacks and tricks.
> 
> BTW, your comment about why not to have delegation can be asked on existing API. JSR already decided to have delegation. So the only question remaining is whether to support only one security model or allow for other possibilities.
> 
> Note that Server side already has PasswordAuthenticator (or similar) class, so it already knows how to convert credentials to Subject.
> 
> Regards,
> Ron.
> 
> 
> -----Original Message-----
> From: Eamonn McManus [mailto:[email protected]] 
> Sent: Tuesday, September 28, 2004 9:01 AM
> To: Ron Vered
> Cc: MX4J-Dev (E-mail); Bordet, Simone; Luis Miguel Alventosa
> Subject: Re: [Mx4j-devel] RE: [Mx4j-user] RE: mx4j-Bugs-969175: Security and delegation
> 
> 
> Ron,
> 
> I am not sure that your point about reusing the same SSL connection is 
> really that important.  If two different connections specify equal 
> RMIClientSocketFactory objects and connect to the same server, then they 
> are eligible to share the same RMI connection.  The RMI infrastructure 
> arranges this.  Two SslRMIClientSocketFactory objects are always equal, 
> so this should be true for you.  Therefore you should find that you are 
> only establishing an SSL connection once to a given server, even if you 
> have several different JMXConnector connections.
> 
> The JNDI lookup cost is not great and with a little more effort you can 
> explicitly do it just once and reuse the retrieved object for every 
> connection.
> 
> Concerning the proposed API changes, we would of course need 
> corresponding API changes on the server side to specify how to validate 
> the client's credentials.
> 
> Without excluding the possibility of adding this functionality, I'd just 
> note that it should be possible to do it with today's API.  Here's how. 
>   The connector server allows you to specify an MBeanServerForwarder via 
> the method JMXConnectorServer.setMBeanServerForwarder.  The idea is that 
> this object is a kind of interceptor between the real MBean Server and 
> the Connector Server:
> 
>    JMXConnectorServer --> MBeanServer
> becomes
>    JMXConnectorServer --> MBeanServerForwarder --> MBeanServer
> 
> MBeanServerForwarder extends MBeanServer, so in a configuration like 
> this each method of the MBeanServerForwarder could check the client 
> credentials before forwarding the request to the real MBeanServer. 
> Something like this:
> 
> public class CheckingForwarder implements MBeanServerForwarder {
>      public CheckingForwarder(MBeanServer mbs) {
>          this.mbs = mbs;
>      }
> 
>      public Object getAttribute(ObjectName on, String attrName)
>              throws MBeanException, AttributeNotFoundException,
>                     InstanceNotFoundException, ReflectionException {
>          checkCallerCredentials();
>          return mbs.getAttribute(on, attrName);
>      }
>      ...likewise for all the other methods of MBeanServer...
> }
> 
> The question is obviously how the checkCallerCredentials() method can 
> get the caller's credentials to check them.  You can do this by using 
> subject delegation.  The client uses getMBeanServer(Subject) to specify 
> the Subject to use, including its credentials.  The server can access 
> this Subject using Subject.getSubject(AccessController.getContext()). 
> Then it can examine the credentials and throw a SecurityException if 
> they are not correct.  (The details of verifying credentials are up to 
> you but for example it could involve consulting a password file or doing 
> a check with LDAP.)
> 
> One obvious problem here is that the serialized form of a Subject does 
> not include its credentials as returned by 
> Subject.getPrivateCredentials() and Subject.getPublicCredentials().  So 
> you cannot communicate your credentials in that way.  Instead you need a 
> little hack, which is to encode the credentials inside a Principal in 
> the Subject.  For example, you could define PasswordPrincipal and put 
> PasswordPrincipal("elderberries") in the Subject to communicate a 
> password of "elderberries".  The checkCallerCredentials() method would 
> check this, and probably destroy the credentials afterwards so that they 
> would not be visible to the MBeans being invoked.  (Each request will 
> deserialize a new copy of the Subject with its Principals, so destroying 
> the PasswordPrincipal for one request doesn't affect subsequent ones.)
> 
> Implementing every single method of MBeanServer in the CheckingForwarder 
> is very tedious, especially because of the "throws" clauses, so a nicer 
> approach is to use java.lang.reflect.Proxy.  I am imagining something 
> like this:
> 
> public class CheckingHandler implements InvocationHandler {
>      public CheckingHandler(MBeanServer mbs) {
>          this.mbs = mbs;
>      }
> 
>      public Object invoke(Object proxy, Method method, Object[] args)
>              throws Throwable {
>          if (method.getName().equals("getMBeanServer"))
>              return mbs;
>          else if (method.getName().equals("setMBeanServer"))
>              throw new IllegalArgumentException("MBeanServer already set");
>          else {
>              checkCallerCredentials();
>              return method.invoke(mbs, args);
>          }
>      }
> 
>      private final MBeanServer mbs;
> }
> 
> MBeanServerForwarder forwarder = (MBeanServerForwarder)
>      Proxy.newProxyInstance(MBeanServerForwarder.class.getClassLoader(),
>                             new Class[] {MBeanServerForwarder.class},
>                             new CheckingHandler(mbs));
> 
> connectorServer.setMBeanServerForwarder(forwarder);
> 
> Regards,


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl