Cannot get password in custom LoginModule

[daniell]

I'm trying to write my own LoginModule named CustomLoginModule which is registered for a security-domain in the standalone.xml:

<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="com.someExample.CustomLoginModule" flag="required">
      <module-option name="password-stacking" value="useFirstPass"/>
    </login-module>
  </authentication>
</security-domain>

I have already tried several things to get the password. Via the callback (like I did on JBoss 5), via the given sharedState, ... Even if I derive from the org.jboss.security.auth.spi.UsernamePasswordLoginModule, I cannot see the password which has been set at the client. Instead, I always get something like "org.jboss.as.security.remoting.RemotingConnectionCredential@6cb45a88" (as String in the password-field).

In my remote client I'm using the following jboss-ejb-client.properties:

endpoint.name=client-endpoint
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=[...]
remote.connection.default.port=[...]
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
remote.connection.default.username=myUserName
remote.connection.default.password=abcde

Obtaining the InitialContext in the client looks like:

Properties props = new Properties();
props.put(Context.URL_PKG_PREFIXES,  "org.jboss.ejb.client.naming");
InitialContext ctx = new InitialContext(props);

But as mentioned, if I invoke some method on a bean carrying the annotation SecurityDomain, starts my login-module failing reading the password.

[daniell]

I've asked this question on Stack Overflow, too - since there was no response here: http://stackoverflow.com/questions/21475229/cannot-get-password-in-custom-loginmodule

[andreas.kozma]

Hi,

we are experiencing exactly the same problem. From the available documentation and books we have not succeeded in getting this to work. Daniel, have you made any progress since? As I see there was no solution proposed to your Stackoverflow question either.

[daniell]

No, unfortunately not.

At the moment I am using a workaround for this: implemented a plugin (see https://docs.jboss.org/author/display/WFLY8/Security+Realms#SecurityRealms-PlugIns) to load the user and roles. The EJB-Security-mechanisms are bypassed by setting the authorization-entry "PermitAll" in the used security-domain. To ensure security on class-/methodlevel I had to implement my own security-interceptor taking the user and roles from the plugin mentioned before. Of course, there are some drawbacks - e.g. when message-queues should be secured, too.

As you can see: very long-winded and unsatisfactory

[jaikiran]

Does it work if you add the following to your jboss-ejb-client.properties:

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

[timj]

Hi, I have been having this same problem with both a custom login module and the DatabaseLoginModule. Adding remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false has not made any difference, as in the original post, the password is always set to org.jboss.as.security.remoting.RemotingConnectionCredential@2e43ea2f or similar.

[jaikiran]

Tim Johnson wrote:

Hi, I have been having this same problem with both a custom login module and the DatabaseLoginModule. Adding remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false has not made any difference, as in the original post, the password is always set to org.jboss.as.security.remoting.RemotingConnectionCredential@2e43ea2f or similar.

You seem to be missing the following property too:

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

[timj]

I already have that. For my test I took the remote-ejb quickstart, to calculatorBean I added

@PermitAll

@SecurityDomain("testDomain")

To standalone-full-ha.xml I added

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

                    <authentication>

                        <login-module code="Database" flag="sufficient">

                            <module-option name="dsJndiName" value="java:jboss/datasources/myDS"/>

                            <module-option name="principalsQuery" value="select password from users where name=?"/>

                            <module-option name="rolesQuery" value="select roles, 'Roles' from users where name=?"/>

                        </login-module>

                    </authentication>

                </security-domain>

this fails and if I debug into DatabaseServerLoginModule.java I always see a password of org.jboss.as.security.remoting.RemotingConnectionCredential@53756d78.

If I switch testDomain to use the RealmDirect login module instead then it works.

[jaikiran]

Please give it a try against the latest released 8.1.0.CR1 Downloads · WildFly. If it still fails there, please file a JIRA Browse Projects - JBoss Issue Tracker with an application to reproduce it so that someone can take a look. I have seen 2-3 threads with similar issue on WildFly so it might either be a configuration issue or some real bug. Give it a try soon before the 8.1.0.Final gets released

[valsaraj007]

Hi jaikiran,

I have checked the latest stable version 8.2.0 but still facing issues. This bug still exists?

Thanks!

[lorenzf]

Found a related bug report: https://issues.jboss.org/browse/SECURITY-808 - DatabaseServerLoginModule is also broken because of this issue.

[david.a.t.green]

This can happen when the chosen security-realm hasn't been configured for JAAS. For example, if the settings for ApplicationRealm are left as defaults to use application-users.properties and the http-remoting-connector is still using ApplicationRealm, then it's possible for the client to be validated that way. If so, then the private credentials haven't been passed to the Subject and your login module doesn't have the information it needs.

You might ask how it's managing to get past the default ApplicationRealm validation, well at some point you may have added the user via the add-user script, or you haven't specified clientProperties.put("remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS", "JBOSS-LOCAL-USER");

Without it, when you're running client + server on the same machine it will just validate your user (in the realm, not the domain) !

I can't say for certain this is the same issue that you had, but it's certainly possible to reproduce the error in the way described. At worst it might give another clue as to what's going wrong.

So the key things to get this to work in my case were:

In standalone.xml:

<security-realm name="MyRealm">

  <authentication>

    <jaas name="myDomain"/>

  </authentication>

</security-realm>

<http-connector name="http-remoting-connector" connector-ref="default" security-realm="MyRealm"/>

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

  <authentication>

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

    <module-option name="dsJndiName" value="java:jboss/datasources/MyDS"/>

    <module-option name="principalsQuery" value="someQuery"/>

    <module-option name="rolesQuery" value="someQuery"/>

    </login-module>

  </authentication>

</security-domain>

<default-security-domain value="myDomain"/>

And in the client code:

Properties clientProperties = new Properties();

clientProperties.put("endpoint.name", "client-endpoint");

clientProperties.put("remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED", "false");

clientProperties.put("remote.connections", "default");

clientProperties.put("remote.connection.default.port", "8080");

clientProperties.put("remote.connection.default.host", "192.168.16.124");

clientProperties.put("remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS", "false");

clientProperties.put("remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS", "JBOSS-LOCAL-USER");

clientProperties.put("remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false");

clientProperties.put("username", username);

clientProperties.put("password", password);

EJBClientConfiguration ejbClientConfiguration = new PropertiesBasedEJBClientConfiguration(clientProperties);

ContextSelector<EJBClientContext> contextSelector = new ConfigBasedEJBClientContextSelector(ejbClientConfiguration);

EJBClientContext.setSelector(contextSelector);

Properties props = new Properties();

props.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false");

props.put(javax.naming.Context.SECURITY_PRINCIPAL, username);

props.put(javax.naming.Context.SECURITY_CREDENTIALS, password);

props.setProperty(javax.naming.Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");

props.setProperty(javax.naming.Context.PROVIDER_URL, "http-remoting://192.168.16.124:8080");

context = new InitialContext(props);

I have a worry that the username and password combination is required to be entered in two separate places, so maybe I'm doing something wrong here. You can even enter a different username/password and see both being validated. It's all bit strange... but at least it's working.