JSR-160 connectors security

[anil.saldhana]

This is a design thread that Scott Marlow (SMarlow) and I will be using to discuss the JSR-160 integration that Scott is working on. There are some security aspects to be considered in this integration based on the JSR-160 specification.

Studying the JSR-160 specification, in the section III on JMX Remote Connector API:

• Section 13.12 Connector Security

On the server side, when the connectors are created, they are instantiated with JMXAuthenticator.  (JMXAuthenticator Javadoc)

If you look at the API for JMXAuthenticator, you will see that there is just one method namely: "Subject  authenticate( Object credential )".  As you can see, we pass in a credential and then get back an authenticated subject.

The credential can be open ended.  Ok, what about the username?  Read below:

From the JSR-160 specification, we see that there is a concrete class called as RMIConnector.

• Section 14.4 Basic Security

Now, the spec says that "A client connecting to a server that has an JMXAuthenticator must supply the authentication information that the JMXAuthenticator will examine. The environment supplied to the connect operation must include the property jmx.remote.credentials, whose associated value is the authentication information. This object must be serializable."

ANIL:  I think on the client side, we need to create an instance of org.jboss.security.SecurityContext and fill it with the username and password that we want to send it across to the server.  At the server, we take this SC instance and authenticate on the server side.

I like the passing of serialized Security Context rather than a String[] array of two (Username and Password) because we may be able to handle various permutations with the ctx (certificates, digest etc).

The spec has: "This specification does not include any predefined authentication system. The simplest example of such a system is a secret string shared between client and server. The client supplies this string as its jmx.remote.credentials, and the server’s JMXAuthenticator checks that it has the correct value.
As a slightly more complicated example, the authentication information could be a String[2] that includes a username and a password. The JMXAuthenticator verifies these, for example by consulting a password file or by logging in through some system-dependent mechanism, and if successful derives a Subject based on the given username."

[smarlow]

On the server side, we probably should be able to configure the security like our other subsystems (e.g. so we can share the same userid + password with the jmx console if desired or have a separate identity).

One reference that describes how jconsole passed the authentication is here: http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html :

"JConsole will pass the user name and password as client credentials as authentication to the RMI connector server by setting the "jmx.remote.credentials" property to these values in the environment map for establishing the connection."

Perhaps we can support passing credentials the JConsole way and the org.jboss.security.SecurityContext way.

[jason.greene]

To me the solution is simple. Just add a JMX authenticator that passes the jconsole username and password through to our Authenticator. We could support additional auth mechanisms, but we are limited to whatever RMI gives us. We need a r3 based impl for that.

[anil.saldhana]

I think the client sends credentials.  The server is what has the JMXAuthenticator working on this "object" called credentials.  So we can start off with whatever jConsole sends.

[jason.greene]

Right. JConsole currently sends a two element String array.

[smarlow]

Should we have a conf/jmx-users.properties or just use the existing jmx-console-users.properties?  Same question for jmx-roles.properties versus using the existing jmx-console-roles.properties.

Or should I be different and plug these properties directly into the jmx-jboss-beans.xml?

[anil.saldhana]

You can either create a new security domain name (and copy over the jmx-console domain modules) or reuse the security-domain for jmx-console. For now, please get it working.

[smarlow]

probably not jboss-beans.xml, need to plug into login-config.xml as well.

[dmlloyd]

Yeah you don't need a properties file, just something like this pseudocode:

class YourAuth implements JMXAuthenicator {
    String configName = ...get this from jboss-beans.xml...;
    LoginContext context = ...get this from configName...;
    YourCallbackHandler cbh = ...has writable properties for user/pass...;

    [...]
    public synchronized Subject authenticate(Object creds) {
        String user, pass;
        user = ((String[])creds)[0]; pass = ((String[])creds)[1];
        // validate user/pass (not shown)
        // now put it on cbh
        cbh.setUserName(user); cbh.setPassword(pass);
        // authenticate:
        context.login();
        Subject s = context.getSubject();
        s.setReadOnly();
        return s;
    }

}

[smarlow]

Do you know where the current code lives that performs the authentication for any of the conf/props/* ?

I can follow that example.

[smarlow]

Amazing, I keep getting answers to the question before asking it. 

[wolfc]

The only thing I want to chime in here is that JBossSecurityContext must not cross the wire. In fact it should not be serializable at all. It's more than just a security context and too heavy for remote usage.

[anil.saldhana]

The SC is a container. If you put all types of junk inside it, it will be heavyweight.  Same as if you have a custom principal and have it be the biggest object on the planet and try to serialize over the wire.