The right way to log out a remote desktop client?

[randahl]

In my desktop application my users log in using settings defined in my jboss-ejb-client.properties file. I have a callback handler which makes JBoss automatically ask for user credentials

remote.connection.default.callback.handler.class=com.xyz.MyCallbackHandler

This all works fine. However, since its automatic, I don't ever get my hands on the LoginContext which is used. So how do I log out the user? I would like to do something like

LoginContext currentLoginContext = [... the code I do not know how to write ...]

currentLoginContext.logout();

I tested if I could acquire the LoginContext using @Inject, but that has no effect.

Does anyone know how to do this? How to log out a user which has been logged in using the automatic approach?

Randahl

[dlofthouse]

Where are you actually trying to "log out" the user?  In the client or the server side?  And that what do you want to happen?

From an AS perspective a lot of the time there is no concept of a log in which means a log out does not have a meaning - what we do have is an authentication process that was initiated on opening the connection which lives as long as the connection so that is the closest there really is to an authenticated session.

[randahl]

Thansk Darran - let me elaborate:

My desktop app can run in two modes: User mode and Robot mode. When the app starts the user is *not* logged in. Instead the app logs in as a "robot" agent which acts on the user's behalf and carries out a number of tasks. Then, if the user wants to use the app directly, the robot should log out, and the user should be logged in, effectively *replacing* the current active user principle.

For this to work, I need two different accounts: The user's account, and a special account for the robot.

My problem is, once the robot has logged in, my CallbackHandler is never called again because someone is already authorized. So when the user clicks the login button in my app, he is not logged in as himself but rather continues to use the application as if he was the robot – this is not what I want, of course.

I need these two different modes because the robot is allowed to do some things which the user is not allowed to do, and vise versa. So ideally, I would like to get my hands on the LoginContext, so I could log out the robot and thus trigger a new call to my CallbackHandler from which I would then serve the user's credentials.

Thanks for reading this – any hints will be highly appreciated.

Randahl

[dlofthouse]

Ok thanks for the clarification, what you are actually going to need to do is re-establish the connection to the server as the authentication is linked to the established connection - I will let one of my colleagues comment on that part.  The LoginContext is not related to this issue.

[randahl]

That would be great. Thanks.

[randahl]

I still have not found a way around this. Could anyone comment on Darrans suggestion to re-establish the connection? What would that entail?

[danjee]

Try with a System.exit(0);

[randahl]

That would terminate the application client. In my use case it is supposed to keep running – I just need to log out from the JBoss backend, so I can log in as another user.

[jaikiran]

Randahl Fink Isaksen wrote:

I still have not found a way around this. Could anyone comment on Darrans suggestion to re-establish the connection? What would that entail?

I missed this thread.

Darran is right. The authentication process is triggered during connection creation. So if you want to switch to a different user, the EJB client context which drives the EJB invocations will have to disconnect the previous connect and reconnect with a new connection. To be able to do this, you will have to use JBoss specific APIs from the JBoss EJB client library. But before going into that, I would like to know see the jboss-ejb-client.properties that you have. Do you list more than one connection there with different user credentials?

[randahl]

Thanks Jaikiran Pai. Below you'll see the jboss-ejb-client.properties file I am using. Admittedly I am not certain that these are the best or even correct options, but they work for me.

Randahl

endpoint.name=client-endpoint

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false

remote.connections=default

remote.connection.default.port=4447

remote.connection.default.host=10.0.0.110

remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

remote.connection.default.callback.handler.class=com.wefend.services.authentication.DelegatingCallbackHandler

remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER

remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false

remote.cluster.ejb.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER

remote.cluster.ejb.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false

[jaikiran]

Here's what your application code will have to do using the EJB client APIs:

        final Properties propertiesForRobotUser = new Properties();
        // add the EJB client properties for the robot user
        // propertiesForRobotUser.put(....)
        final EJBClientConfiguration clientConfigurationForRobotUser = new PropertiesBasedEJBClientConfiguration(propertiesForRobotUser);
        // create a EJB client context selector for this robot user
        final ContextSelector<EJBClientContext> contextSelectorForRobotUser = new ConfigBasedEJBClientContextSelector(clientConfigurationForRobotUser);
        // use this context selector for robot user
        EJBClientContext.setSelector(contextSelectorForRobotUser);
        // invoke on beans

        // now at a later point, switch to application user
        final Properties propertiesForApplicationUser = new Properties();
        // add the EJB client properties for the application user
        // propertiesForApplicationUser.put(...)
        final EJBClientConfiguration clientConfigurationForApplicationUser = new PropertiesBasedEJBClientConfiguration(propertiesForApplicationUser);
        // create a EJB client context selector for this application user
        final ContextSelector<EJBClientContext> contextSelectorForApplicationUser = new ConfigBasedEJBClientContextSelector(clientConfigurationForApplicationUser);
        // use this context selector for application user
        EJBClientContext.setSelector(contextSelectorForApplicationUser);
        // now invoke on beans

[jaikiran]

Randahl Fink Isaksen wrote:

Below you'll see the jboss-ejb-client.properties file I am using. Admittedly I am not certain that these are the best or even correct options, but they work for me.

endpoint.name=client-endpoint

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false

remote.connections=default

remote.connection.default.port=4447

remote.connection.default.host=10.0.0.110

remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

remote.connection.default.callback.handler.class=com.wefend.services.authentication.DelegatingCallbackHandler

remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER

remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false

remote.cluster.ejb.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER

remote.cluster.ejb.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false

One thing you are missing in there is the declaration of cluster name(s). Just like the connection names, you first have to declare the cluster name(s) before using them. So you'll need a:

remote.clusters=ejb

in there, to be able to use the remote.cluster.ejb.* properties.

[danjee]

This will clear the authentication cache

The needed lib files are in jboss modules.

package com.asf.jndi.jboss7;


import org.jboss.as.controller.client.ModelControllerClient;
import org.jboss.dmr.ModelNode;



public class FlushJaasCache {
          public static void main(String[] args) {
                    try {
                              flushAuthCache("CaponeJaas");
                    } catch (Exception e) {
                              e.printStackTrace();
                    }
          }


          private static void flushAuthCache(String domain) throws Exception {
                    final ModelControllerClient client = ModelControllerClient.Factory
                                        .create("localhost", 9999);
                    try {
                              final ModelNode address = new ModelNode();
                              address.add("subsystem", "security");
                              address.add("security-domain", domain);


                              final ModelNode operation = new ModelNode();
                              operation.get("operation").set("flush-cache");
                              operation.get("address").set(address);


                              final ModelNode result = client.execute(operation);


                              if (!"success".equals(result.get("outcome").asString())) {
                                        throw new IllegalStateException("operation failed");
                              }
                    } finally {
                              if (client != null) {
                                        client.close();
                              }
                    }
          }
}

[randahl]

Awesome. Thanks. I am so looking forward to testing this out. I will be working on this again next week, so I'll post here again...

[jaikiran]

Note that the JAAS cache doesn't have anything to do with this and flushing that isn't going to be of any help.