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

Eamonn,

You are right about the RMI argument.
Please consider the fact that a "JMX client" may very well be a server too.
We would be happy to see real implementation of SASL JMXMP in Reference Implementation and MX4J.

Regards,
Ron.

-----Original Message-----
From: Eamonn McManus [mailto:[email protected]] 
Sent: Monday, September 06, 2004 5:29 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,

Thanks for these interesting comments.  My replies inline.

Ron Vered wrote:
> Other comments, which are not at all critical to us, but are worth 
> some consideration are the following:
> 
> We know that when a client connects to an Mserver, a subject is 
> eventually created and associated with the running thread, so if some 
> Mbean is invoked, the subject's permissions are considered. The RMI 
> implementation and spec provide means for the client to specify who he 
> is by supplying credentials, but provide no means for the client to 
> identify the server.
> 
> However, if this client registers for some notification and later 
> notified, on the client there is no information what so ever about 
> which entity initiated the notification and thus the client side code 
> associated with the listener is executed (probably) with the 
> connector's permission. In practice, the "server" may possibly be 
> running with several different associated subjects. In current 
> implementation, the client does not know of any (not even one) and 
> thus is likely running with the wrong set of permissions when a 
> notification is received.

Indeed, there is a fundamental asymmetry in the current design, in that 
the server does not trust the client, but the client does trust the 
server.  This is mostly due to the fact that the client can do 
relatively powerful things to the server (invoke methods on MBeans), 
while all the server can do is send objects (method return values and 
notifications) to the client.

When a client adds a listener for handling a notification, it does so 
for a particular MBean in a particular MBean Server.  So it should know 
what the server is.  The listener does not need special logic to 
determine what server is sending the notification, because it can 
already know that.

On the other hand, it is true that the client could want to determine at 
connect time whether the server is who it says it is.  It is possible, 
though tricky, to configure RMI to use SSL and certificates for this.

For the most part, when we were designing the JMX Remote API, we felt 
that we should not be designing a complete security model for RMI -- it 
makes more sense for that to do be done for RMI in general rather than 
the particular use that the JMX Remote API makes of it.  It is in fact 
possible to do quite a lot with the fairly limited security support that 
is present.  In particular, you can do challenge/response authentication 
by having your JMXAuthenticator.authenticate method throw a special 
exception that the client recognizes as a challenge, and having the 
client redo the authentication with the response to the challenge. 
Admittedly this is not very straightforward.

For a more complete security solution, the JMX Remote API defines an 
optional part that includes another protocol called JMXMP.  This 
protocol interacts with TLS (basically SSL) and SASL (the Simple 
Authentication and Security Layer) to provide a much more configurable 
security solution that can interact with various security 
infrastructures.  MX4J does not currently include an implementation of 
JMXMP, but the Reference Implementation does.

This does not mean that we could not envisage augmenting the security 
support of the RMI connector in the future, but it is unlikely to have 
the same degree of security configurability as the JMXMP connector.

Regards,
-- 
Éamonn McManus, JSR 160 (JMX Remote API) Spec Lead

> Last, I think it should be made easier to plug-in different 
> authentication models. Currently, while I like the Kerberos based 
> idea, I think its not really an option and is more difficult to deploy 
> (leave it in though!).
> 
> If we look at RMI, than we get JMXAuthenticator, which allows for 
> client-only authentication with a single unidirectional message (not 
> good enough). Of course I can write my own connector server, but if 
> the spec will either allow more options (e.g. real challenge-response) 
> AND allow to plugin your own thereby allowing client AND server 
> authentication, possibly arbitrary number of messages for 
> authentication stage, that would be great.
> 
> I leave it up to you to raise possible solutions.
> 
> Thank you,
> Ron.


------------------------------------------------------------------------------
This e-mail message is for the sole use of the intended recipient(s) and contains confidential and/or privileged information belonging to Siebel Systems, Inc. or its customers or partners.  Any unauthorized review, use, copying, disclosure or distribution of this message is strictly prohibited.  If you are not an intended recipient of this message, please contact the sender by reply e-mail and destroy all soft and hard copies of the message and any attachments.  Thank you for your cooperation.
====================================================



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id808&op=click