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

Ron,

Ron Vered wrote:
>> Here's how we could consider changing the API.  Suppose a security 
>> context (subject and/or codebase and/or signers), say "creator", makes a
>> 
>> JMXConnectorServer and supplies a JMXAuthenticator.  Later, a connection
>> 
>> arrives, and the JMXAuthenticator returns a Subject for it containing 
>> the Principal "remote".  Today, basically both "remote" and "creator" 
>> must have all needed permissions for the reason I detailed.  However, 
>> suppose we say that an MBean operation that needs FilePermission is 
>> allowed if EITHER:
>> (1) both "remote" and "creator" have FilePermission (the current 
>> requirement); OR
>> (2) "remote" has FilePermission and "creator" has 
>> SubjectDelegationPermission("remote").
> 
> [Ron] This is OK provided the "remote" is some specified principal class
> and name, both of the policy writer's choosing and where it can
> potentially be "*" for all.

Right.  Check out the spec for SubjectDelegationPermission:
<http://java.sun.com/j2se/1.5.0/docs/api/javax/management/remote/SubjectDelegationPermission.html>
which already allows exactly this.

>> Concerning your second request, to be able to have several authenticated
>> 
>> Subjects use the same RMI connection without using delegation, I am not 
>> convinced that this gets you enough, compared with simply opening a 
>> connection per authenticated Subject, to justify the additional 
>> complexity.  RMI can share the actual network connections between a pair
>> 
>> of JVMs anyway -- it doesn't have to open a different TCP/IP connection 
>> for each RMI connection, except in circumstances (involving socket 
>> factories) where it would be impossible to share the JMX Remote 
>> connection anyway.
 >
> [Ron] I don't understand what complexity you are referring to, in
> addition to passing in Subject argument, have an overload accepting
> credentials, similar to a connect. Basically, make delegation and
> connection symmetric.
> Note that RMI may be able to do this multiplexing in some scenarios, but
> please also consider load-balanced applications and other transports.
> You already (wisely) decided to have delegation, so please support it in
> a symmetric manner, which allows different security models to be
> implemented.

If I understand, you are saying that it's all very well for RMI to share 
connections, but say we are using something like JMXMP which doesn't, 
how do we allow multiple identities to share the same connection then? 
I am not sure what the answer is.  JMXMP, like the RMI connector, has an 
authentication step when the connection is established, only.  Adding 
the ability to authenticate on every request still doesn't seem very 
different from just establishing a connection per request.  Indeed, it 
is likely to be substantially more costly than establishing one 
connection per Subject, as you can do today.

If we want to be able to support challenge/response authentication, then 
we would need a design something like this:  The client can contact the 
server at any time, authenticate, and receive a cookie representing the 
authenticated identity.  Then, in any subsequent request, it can supply 
the cookie, and the request will automatically be performed using the 
previously-authenticated identity.

The server must be allowed to invalidate the cookie at any time, both 
because a client that authenticated last month isn't necessarily still 
valid, and because we don't want the server to be required to maintain 
client state for an unbounded period of time.  This means that when the 
client does a request containing an authentication cookie, it must be 
prepared to get back an error, re-authenticate, and re-issue the request.

In essence, this duplicates what the RMI connector already does.  Each 
authenticated connection is represented by a separate RMI object.  The 
RMI object-id (a 64-bit securely-random integer) is the cookie.  The 
server can unexport the RMI object for a connection at any time, 
whereupon the client must make a new authenticated connection.  For the 
RMI connector, I still don't think there is anything to be gained by 
adding support for sharing different authenticated identities over the 
same RMI connection.

Adding such support for other connectors could be interesting.  But I 
don't think there is a need for this to be reflected in the generic 
client API.  I still think this would lead to the API being 
substantially more complicated than it currently is.  I could be wrong, 
though -- do you have an idea of what you would like the changed client 
API to look like?

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


-------------------------------------------------------
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