Accessing remote client IP on AS 7.x

[ecimon]

I'm implementing a custom AuthorizationModule on EAP-6.1.0.Alpha, and I need to access the IP address of the remoting connection that's being authorized. This article provides a solution for 5.1.0.GA (parsing Thread.currentThread().getName()):

https://community.jboss.org/wiki/HowtogettheClientipaddressinanEJB3Interceptor

How can I achieve this on AS7?

Any pointers/suggestions/debugging tips would be greatly appreciated.

[pref]

It seems there is no reliable way of getting such information. If there is a web-client's authentication, you may use JACC to access HttpServletRequest:

HttpServletRequest request = (HttpServletRequest) PolicyContext.getContext(HttpServletRequest.class.getName());
if (request != null) {
    System.out.println("Authenticating " + request.getRemoteAddr());
}

[ecimon]

This application serwer is completely isolated from the web, so - unfortunately - your solution isn't of much use to me. Thanks for the tip anyway.

Also, isn't it possible through reflection and/or some internal API? It seems like a common use-case.

[pref]

I'm not sure how reliable it is (maybe someone from Remoting team comment on this). The classes and methods are marked public however I'm not sure they are the part of public API, so you can come across troubles in future releases.

import org.jboss.as.security.remoting.RemotingContext;

import org.jboss.remoting3.Connection;
import org.jboss.remoting3.security.InetAddressPrincipal;

...

public boolean login() throws LoginException {
    InetAddress remoteAddr = null;
    Connection connection = RemotingContext.getConnection();
    for (Principal p : connection.getPrincipals()) {
        if (p instanceof InetAddressPrincipal) {
            remoteAddr = ((InetAddressPrincipal) p).getInetAddress();
            break;
        }
    }

    System.out.println("Authenticating " + remoteAddr);

    ...
}

Don't forget to add dependencies of your login module to org.jboss.remoting3 and org.jboss.as.security.

[ecimon]

Thanks for the input. I just tried your second suggestion - unfortunately, getConnection() returns a null reference in this case (is this expected?).

import org.jboss.as.security.remoting.RemotingContext;

import org.jboss.remoting3.Connection;

import org.jboss.remoting3.security.InetAddressPrincipal;

import org.jboss.security.authorization.modules.AbstractAuthorizationModule;

public class IPAddressAuthorizationModule extends AbstractAuthorizationModule {

    @Override

    public int authorize(Resource resource) {

     Connection connection = RemotingContext.getConnection(); //Returns null

           ...

     }

}

I also tried java.rmi.server.RemoteServer.getClientHost(), but this results in ServerNotActiveException.

Any further ideas?

[pref]

Which version of JBoss are you using? What is your remoting authentication configuration in standalone.xml? I have no problems obtaining remoting connection in authorization/authentication modules on EAP 6.1.Alpha (7.2.0.Final). However if you use JAAS for remoting authentication you are bad luck. There is a bug in JBoss 7.x I described here https://community.jboss.org/thread/223087 that is fixed in JBoss 8.0.0 (as I see in sources).

[ecimon]

I'm still on EAP 6.1.0.Alpha. My JAAS configuration looks like this:

<security-realm name="ApplicationRealm">

  <authentication>

    <jaas name="MyDomain" />

  </authentication>

</security-realm>

...

<subsystem xmlns="urn:jboss:domain:remoting:1.1">

   <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>

</subsystem>

...

<subsystem xmlns="urn:jboss:domain:security:1.2">

            <security-domains>

                <security-domain name="MyDomain" cache-type="default">

                    <authentication>

                        <login-module code="Remoting" flag="optional">

                            <module-option name="password-stacking" value="useFirstPass"/>

                        </login-module>

                        <!-- MyLoginModule is an implementation of org.jboss.security.auth.spi.AbstractServerLoginModule-->

                        <login-module code="com.example.MyLoginModule" flag="required">

                              ... <!-- data source config -->

                        </login-module>

                    </authentication>

                    <!--

                    <authorization>

                        <policy-module code="com.example.IPAddressAuthorizationModule" flag="required"/>

                    </authorization>

                    -->

                </security-domain>

                <security-domain name="other" cache-type="default">

                    <authentication>

                        <login-module code="Remoting" flag="optional">

                            <module-option name="password-stacking" value="useFirstPass"/>

                        </login-module>

                        <login-module code="RealmDirect" flag="required">

                            <module-option name="password-stacking" value="useFirstPass"/>

                        </login-module>

                    </authentication>

                </security-domain>

                <security-domain name="jboss-web-policy" cache-type="default">

                    <authorization>

                        <policy-module code="Delegating" flag="required"/>

                    </authorization>

                </security-domain>

                <security-domain name="jboss-ejb-policy" cache-type="default">

                    <authorization>

                        <policy-module code="Delegating" flag="required"/>

                    </authorization>

                </security-domain>

            </security-domains>

        </subsystem>

This setup works as long as IPAddressAuthorizationModule is turned off.

I tried to replicate the bug, that you're relating too, but I failed so far (SimpleSecurityManager's code below):

    //This method never gets called

    public void push(final String securityDomain, final String runAs, final String runAsPrincipal, final Set<String> extraRoles) {

                   ...

                  SecurityActions.remotingContextClear(); // Now that it has been used clear it.

                   ...

    }

    //This one does

    public void push(final String securityDomain, String userName, char[] password, final Subject subject) {

                 ...

    }

I'll dig into it some more, but I was wondering about 2 things first:

1) Is there a related JIRA issue? (is this confirmed in some way?)

2) Have you tried patching org.jboss.as.security yourself? Did it actually solve the issue that you were describing?

[pref]

In your case you have no chance of getting remoting Connection and IP address at all without patching JBoss Remoting library. There are two phases of remote invocation: first remoting subsystem must authenticate and authorize remoting user using security realm referred from <connector name="remoting-connector"... in order to find if this user is allowed to connect to the AS remotely, then (if your invocation passed this check) EJB security interceptor must check if the current user can invoke this method using a security domain referred from your application (for example in jboss-app.xml or in @SecurityDomain annotation) or 'other' domain if the application does not set it explicitly. In the first phase you have absolutely no chances of getting remoting connection object without patching JBoss, in the second phase you can use dirty hack and get it from RemotingContext.getConnection() method (in JBoss 7.2.0 at least, in JBoss 8.0.0 it's a bit trickier because you must use reflection hacks in order to get it).

If you look at the definition of 'other' security domain you can find there optional Remoting login module. It should be used to allow EJB security does not double-check the already authenticated in the first phase user and automatically pass second phase's security checks. However because of the bug I described in the topic referred above, it does not work properly if you use JAAS-based security domain in the remoting subsystem. So even if you handle the problems of getting IP address of remoting client, you are still to find the solution of how to make EJB security interceptor properly authorize the user.

[ecimon]

Sorry for replying so late - I took a short vacation last week and wasn't really available. I ended up patching org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler in a fairly non-intrusive way (ChannelAssociation is stored in a static ThreadLocal variable just before method invocation and cleared just after it's done).

Thanks a lot for your time! I really appreciate your help.