Wildfly 8 custom login module accessing HttpServletRequest params

I am investigating the feasibility of using a wildfly custom login module.

The client will pass the mobile device id to the server as part of the login. I will check that the username and password are correct in the usual way then I need to check that the mobile device is approved to use the service.

The idea is that I will have a restful webservice method login that calls HttpServletRequest.login(u, p).

How do I get hold of the mobile device id inside the login module in the HttpServletRequest?

I could login and if that succeeds then test the device id in the webservice and if that is not approved, log the user out. But that seems rather messy.

What is the correct way of doing this?

EDIT

FEED BACK: I did it the way chris suggested. I implemented my own version of the CallBackHandler and an implementation of the Callback interface, inside the login method of my login module I do the following:

public boolean login() throws LoginException {

        boolean login = super.login();

        if (login) {

            UuidCallback uuidCallback = new UuidCallback();

            try {

                super.callbackHandler.handle(new Callback[]{uuidCallback});

            } catch (Exception e) {

                LoginException le = new LoginException("Failed to get uuid");
                le.initCause(e);

                throw le;
            }

            System.out.print("Device UUID: "+uuidCallback.getUuid());
    }

    return login;
}

Inside the web service login method :

@Path("/login")
@Produces({ "application/json" })
public class LoginWebService {

    @POST
    public Response login(@Context HttpServletRequest request) throws LoginException {

        CallbackHandler callbackHandler = new MyCallbackHandler(request.getParameter("username"), request.getParameter("password"), request.getParameter("uuid"));

        Subject subject = new Subject();
        LoginContext loginContext = new LoginContext("securityDomain", new subject, callbackHandler);

        loginContext.login();

        MyPrincipal principal = subject.getPrincipals(MyPrincipal.class).iterator().next();
    }
}

You could also just set the uuid on the callback handler and then call getUUID() on the callback handler inside the LoginModule.login method. But I opted to go with the design even though it does not quite make sense to me.

I was still getting 403 when logged in and trying to access protected resources it turns out that if auth-constraint/role-name is *, you must supply at least one security-role.

<login-config>
    <auth-method>FORM</auth-method>
    <realm-name>mydomain</realm-name>
</login-config>
<security-constraint>
    <web-resource-collection>
        <web-resource-name>rest</web-resource-name>
        <url-pattern>/rest/app/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>*</role-name>
    </auth-constraint>
</security-constraint>
<!-- after login there is a 403 on protected resources if no role and role-name * -->
<security-role>
    <role-name>user</role-name>
</security-role>

All my users have a role user, which gives them access. I was able to get it working by excluding the security-role but then auth-constraint/role-name must be set to a literal role, in my case: "user"

Solution

I would suggesting creating a LoginContext and pass thru an implementation of a CallbackHandler. In the callbackhandler cater for the extra UUID property.

While this code works for me, you will need to update it to cater for the extra UUID property

public class NamePasswordCallbackHandler implements CallbackHandler {
    private final String username;
    private final String password;

    private NamePasswordCallbackHandler(String username, String password) {
        this.username = username;
        this.password = password;
    }

    public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
        for (Callback current : callbacks) {
            if (current instanceof NameCallback) {
                ((NameCallback) current).setName(username);
            } else if (current instanceof PasswordCallback) {
                ((PasswordCallback) current).setPassword(password.toCharArray());
            } else {
                throw new UnsupportedCallbackException(current);
            }
        }
    }
}

I created my own implementation of the Configuration object (shown below as JBossJaasConfiguration).

Then pass thru this callbackhandler to your LoginContext:

CallbackHandler cbh = new NamePasswordCallbackHandler(username, password);
Configuration config = new JBossJaasConfiguration("mysqldomain");

LoginContext loginContext = new LoginContext("mycontext", new Subject(), cbh, config);
loginContext.login();

The property "mysqldomain" relates to the security-domain name in your standalone.xml

<subsystem xmlns="urn:jboss:domain:security:1.2">
    <security-domains>
        <security-domain name="mysqldomain" cache-type="default">
             <authentication>
                  <login-module code="com.soccerx.security.DatabaseServerLoginRealm" flag="required">
                     <module-option name="dsJndiName" value="java:jboss/datasources/SoccerSoftwareDS"/>
                     <module-option name="principalsQuery" value="select userId, tenantId, password, salt from User where username=? and StatusId != 2"/>

            <module-option name="rolesQuery" value="select Role, 'Roles' from User where Username=?"/>
                    <module-option name="password-stacking" value="useFirstPass"/>
                    <module-option name="principalClass" value="com.soccerx.security.DatabasePrincipal"/>
                </login-module>
            </authentication>
        </security-domain>
    <security-domains>
</subsystem>

While this is not a complete solution for your needs, I expect you can modify it to ensure that login fails should the UUID not match.

Note: You will need to cater for this in your CustomDatabaseLoginRealm, as defined in your standalone.xml. Meaning access the username/password/uuid and compare it to the values in the database.