0

My web application is secured with salted, digested passwords using container managed authentication. I'd like to reduce the coupling with my current container by having a service in JNDI that handles the password mutation / verification. I was after something like this:

/**
 * A service for mutating passwords with salt.
 * Note that the same password should yield different mutations every time.
 */
public interface PasswordMutationService {
    /**
     * Mutates the given password for storage purposes.
     * The 'salt' must be coded into the result so that it can be extracted later.
     */
    String mutatePassword(String password);

    /**
     * Confirm the given password was used to create the given stored mutation.
     *
     * @param candidatePassword     The password supplied by a user that wants to be authenticated.
     * @param storedMutatedPassword A mutation of the users password retrieved from storage.
     */
    boolean verifyMutatedPassword(String candidatePassword, String storedMutatedPassword);
}

Do you know of an API that supplies this interface so I don't have to write and manage my own? I have a hard time believing it's not in Java EE somewhere.

NOTE: I'm not after a Tomcat Realm, that has already been done. Nor do I need the implementation, that is done too.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Peter L
  • 2,921
  • 1
  • 29
  • 31
  • Won't you still be tied to your container? I'm confused by how implementing your own abstraction helps you here. – Elliott Frisch Jun 04 '14 at 02:53
  • Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it. – Jim Garrison Jun 04 '14 at 03:03
  • Elliott, my application needs the 'mutatePassword()' feature to save / mod user info. The corresponding container adapter needs 'verifyMutatedPassword()' feature. If I move to another container then only a new container adapter needs to be written; I don't even have to recompile the app. – Peter L Jun 04 '14 at 04:00
  • Jim, I hear what you're saying about subjectively correct answers. My question is for anyone that has come across this type of interface before because I can't find it and it seems pretty generic. I'll try to tweak the question to be more useful and will await community verdict on whether to close it. – Peter L Jun 04 '14 at 04:11

1 Answers1

0

To decouple my application from the password digest implementation I really only need one method:

String mutatePassword(String password)

The container plugin can be coupled to the digest implementation without too much harm so it does not need 'verifyMutatedPassword()' to be on an interface.

After browsing some JDK7 API's I found something that could do the job (if you're not easily offended):

public interface Provider<T> {
  public T invoke(T request);
}

This means my application can tap into password mutation with:

InitialContext ctx = new InitialContext();
passwordMutator = (Provider<String>) ctx.lookup("java:comp/env/bean/appPasswordMutator");

The tomcat container config for password mutation and security realm is:

<Resource name="bean/appPasswordMutator" auth="Container"
          factory="org.apache.naming.factory.BeanFactory"
          type="pkg.PasswordMutator"
          seedNumBytes="8"
          keyNumBits="160"
          digestIterationCount="10000"
          singleton="true"/>

<Realm className="pkg.PasswordMutationRealm" 
       userCredCol="usercred"
       passwordMutatorName="bean/appPasswordMutator" 
       localPasswordMutator="true"
       localDataSource="true"
       dataSourceName="jdbc/appDb"
       userTable="usercred"
       userNameCol="username"
       userRoleTable="userrole"
       roleNameCol="userrole"/>

A working demo is available from my SVN repo at: https://subversion.assembla.com/svn/freshcode_public/learn/tomcat-maven-plugin (See READ_ME.txt file)

Peter L
  • 2,921
  • 1
  • 29
  • 31