Criptografia de Senha em Descritores de Contexto do Tomcat

Recentemente um cliente reclamou, com razão, que as senhas de acesso aos bancos apareciam em texto não criptografado nos arquivos de contexto do Tomcat. Uma vez que essa senha vai direto para o driver jdbc, não encontrei outra forma de criptografar essa senha que não fosse criando meus próprios drivers jdbc, extendendo os drivers existentes.
No caso do Oracle, por exemplo, criei a classe abaixo:

public class OracleDriver extends oracle.jdbc.driver.OracleDriver {
static {
  try {
    java.sql.DriverManager.registerDriver(new OracleDriver());
  } catch (SQLException e) {
    e.printStackTrace();
  }
}
public static void main(String[] args) {
  System.out.println("Arcadian Oracle wrapper jdbc driver");
}
private static final String URL_PREFIX="jdbc:arcadian:oracle";
@Override
public Connection connect(String url, Properties info) throws SQLException {
  if(url.startsWith(URL_PREFIX)){//senha cryptografada
    Util.decryptPassword(info);
    return super.connect(url.replace(URL_PREFIX, "jdbc:oracle"), info);
  } else {//senha não criptografada
    return super.connect(url, info);
  }
}
@Override
public boolean acceptsURL(String url) {
  if(url == null)
    return false;
  else
    return url.startsWith(URL_PREFIX);
}
}

Dessa forma, o caso o url de acesso jdbc comece com o prefixo "jdbc:arcadian" eu sei que a senha está criptografada e o método Util.decryptPassword é chamado pelo método connect antes do método ancestral ser chamado.

Um datasource que use esse mecanismo deve ficar mais ou menos com o seguinte aspecto:

<resource name="jdbc/previne/datasource" auth="Container"
type="javax.sql.DataSource"
driverClassName="com.arcadian.commons.jdbc.OracleDriver"
url="jdbc:arcadian:oracle:thin:@120.120.126.209:5623:DBACC84C"
username="USER987"
password="ui#ghkuyt%--)(*CFR"
maxActive="10"
maxIdle="30"
maxWait="10000"/>
</resource>

Observe que para obter o mesmo efeito para outros bancos basta substituir a classe ancestral...

Autenticação X.509 (e-cpf) e FORM no Tomcat, simultâneamente

Nessa semana tive um desafio interessante: como fazer uma aplicação que está rodando no Tomcat suportar tanto a autenticação comum (FORM ou BASIC) quanto via e-cpf (certificado cliente X.509), simultâneamente.

O Previne é uma aplicação voltada para empresas que fazem uso de regimes especiais da receita federal e tipicamente é acessada tanto pela empresa que a contrata quanto por fiscais da receita federal. A demanda era fazer com que o Previne suportasse a autenticação atual (FORM) no uso interno da empresa e via e-cpf para uso externo pelos fiscais da receita.

Fiz o trabalho de pesquisa tradicional e achei o excelente material Controle de Acesso com Certificação Digital usando JCE e JSSE desenvolvido por Ricardo Koji Ushizaki. Depois de construir o servlet de teste conforme indica a apresentação, me deparei com o fato de um mesmo web.xml não suportar duas marcações auth-method. A princípio pensei em usar uma válvula (Tomcat Valve) customizada, conforme o exemplo do wiki do tomcat, mas não fiquei muito seguro do funcionamento.

Finalmente optei pela seguinte solução: criei uma segunda aplicação autenticada via e-cpf que consiste somente de um servlet que redireciona para a aplicação destino e usei o recurso de single sign on do Tomcat. Dessa forma o usuário é autenticado na primeira aplicação e redirecionado para a segunda sem ter que passar por uma nova autenticação.

A grande vantagem que vi nessa solução foi que a aplicação original não sofreu nenhum tipo de manutenção e a aplicação que faz a autenticação ficou genérica, recebendo como parâmetro de contexto o caminho destino do redirecionamento de modo que pode ser usada com outras aplicações sem nenhuma alteração.