Mensagens enviadas por: IndyanaJones

Vamos tentar uma receita em português não estruturado:

No cliente (browser), ingredientes:
i) Uma chave privada
ii) Um certificado X509 emitido por uma CA que vc tenha posto como confiável
iii) [nem tanto opcional] A chain desta CA

modo de preparo:
misture bem os ingredientes num pkcs12, temperando a password a gosto e importe no browser. Verifique a importação: No IE é em tools->internet options->content>certificates, na aba "pessoal" está o seu certificado, o meio da chain está em "autoridades intermediárias" e a ca root está em "...raiz confiável". No Firefox 2 é em ferramentas->opções->avançado->criptografia->certificados. Aqueça em banho-maria e conecte no seu servidor. Se esquentar demais o seu hd torra, cuidado.

Qual é o problema:
1) O browser conecta e inicia o SSL
2) O servidor responde "Oi, eu sou o server e tenho este certificado. Eu mostrei o meu agora vc mostra o seu, ok ?"
3) O browser se faz de malandro diz ok e não manda nada
4) O server se sentindo abusado, aborta com o code 400.
5) O browser diz para vc que a culpa é do server que fechou a porta na cara dele.

se localizou ?

irmão, alguns conceitos (simplificados) antes:

certificado: no contexto de PKI, 90% das vezes significa um X.509v3. Este tipo de certificado é basicamente um record/struct que tem os dados pessoais do "dono" (subject) + chave pública do subject + dados de quem emitiu (issuer, uma CA normalmente) mais a assinatura digital do emissor. É esta assinatura que dá a garantia para quem recebe o mesmo (tb conhecido como ter fé

). O objetivo final é fazer um bind seguro entre os dados e a chave pública do subject.

chave privada (priv key): é o par da chave pública. É esta que vc vende o seu primogênito mas não entrega a chave. O que vc "faz" com uma vc só "desfaz" com a outra, por exemplo "assinar" é usar esta, pq qualquer uma com a pub key confere, da mesma forma se algúem quiser mandar algo p/ que só vc veja, ele usaria a pub key pq apenas vc com a priv conseguiria olhar.

PKCS12 (p12) - é uma estrutura que funciona como se fosse uma "carteira digital", nela vc tem a sua priv key, o seu certificado e o da sua CA (usualmente numa chain). Em termos java é um keystore com uma key entry e várias certificate entries. Não é um "certificado"

Para criar, exitem várias ferramentas que geram ou convertem de <-> para keystore. Tem uma app. maneirinha da IBM chamada Key Manager (Keyman) que é molezinha de usar (http://www.alphaworks.ibm.com/tech/keyman)
Mas claro, sempre tem a openssl e o keytool.... mas provavelmente a a sua fé na humanidade seria abalada (http://mark.foster.cc/kb/openssl-keytool.html)
Se eu não me engano na distribuição do jetty (em extra ou contrib) tinha um utilitário que convertia, mas não lembro se ele gera um p12.

Então para responder a sua pergunta, o seu cliente, para fazer ssl, tem que ter uma chave privada, e um certificado emitido por uma CA que o seu web server / trust manager engula. Um p12 é a maneira usual de agrupar isso, já que todos eles conseguem importar/exportar um p12.

Ps1- Se vc ver alguma referencia à pfx ignore...

Ps2- Se vc gostou do pkcs12, vc vai adorar o pkcs15

qq coisa grita...

Se vc configurou o tomcat para, no ssl, exigir o certificado do cliente (concordo que autenticar via client-cert sans client cert é interessante) - o cliente (browser, por exemplo) deve enviar um certificado de uma CA confiável (ou seja, que o trust manager goste) ou uma chain que contenha ao menos uma CA confiável.
Olhe:
http://emo.sourceforge.net/cert-login-howto.html
http://www.vorburger.ch/blog1/2006/08/setting-up-two-way-mutual-ssl-with.html
http://www.oreilly.com/catalog/tomcat/chapter/ch06.pdf

Em especial as partes sobre a configuração do cliente.
Ps- client-cert funciona, mas lembre-se a maioria das implementações (que eu conheça) NÃO olha crl, ocsp, etc...

Eu já vi marketing enrolado, mas esse da certisign supera... http://www.certisign.com.br/produtos/certificados/

Pelo que eu vi o que eles vendem é o X509 + servidor + hardware acelerando ssl. Algo como Combo Site SSL (ou não... sei lá).
Já o outro, o que não tem o "300 trilhões de computação" deve ser sem o acelerador SSL.

Thingol, acho que é pouca a chance da chave ser de 2048 - assim demora muito para o cliente renovar... os de 1024 é um só aninho

O cash flow deles agradece

e se vc ligar e comprar agora ainda ganha um par de meias vivarina ?

Tem a url ?

Um certificado (X.509) são meia dúzia de bytes, não computam nada. Por outro lado um .Xml tem um poder computacional 300 trilhões de vezes maior que do que um .Ini

Por acaso vc não está falando de um acelerador de SSL ou um Hsm ?
tipo nCipher, Luna, etc... ?

Ps#1 - O máximo que eu consigo imaginar (long shot, but) seria por conta da ECC usar um tamanho de chave menor do que uma RSA para o mesmo nível teórico de segurança, e com o tamanho menor de chave menos CPU é usada para assinar/verificar...

Ps#2- Pode trocar o par de vivarinas por uma faca ghinsu ?

VOCÊ ME SUGERE UMA OUTRA FORMA DE REALIZAR TODO ESSE PROCESSO!

Se está funcionando e vc está satisfeito, deixa rolar...

Certamente deve mais um milhão de coisas adicionais no teu projeto para fazer e a ampulheta não vai parar.
Caso vc tenha tempo (e interesse) depois tente colocar tudo dentro do jaas, embora não exista nenhum grande motivo para isso (se muito, é pq ele é que deveria gerir essa parte e deixar a sua aplicação isolada do "como")

CASO POSSA ME AJUDAR, FICAREI MUITO AGRADECIDO.

Qualquer coisa grita...

Sabe pq até hoje não implementaram o Registro Único?Pq seria fácil de identificar laranjas, profissão essa muito querida no nosso país...

Existem outras razões, nenhuma técnica - claro. Já tendo trabalhado num banco estatal (2 opções, escolha a pior) eu vi isso de perto: normalmente é um grande esquema de feudos, cada código destes, cpf, pis, ifp, etc tem um cacique que não quer largar o osso pq o emprego e poder dele e todos embaixo (inclusive na informática) derivam do controle sobre o código. Por exemplo, a receita ignora o pis (só cpf) e caixa na medida do possível, ignora o cpf (só pis)...

Por isso e outras, concordo com vcs: a melhor vista do brasil é pela janela do avião - indo embora.

me explica de novo pq eu sou surfista

O seu filtro invoca o jaas nos 2 momentos ou o container invoca a 1a e o filtro a 2a. ?
Qual container web vc está usando tomcat ?

Pelo que eu entendi do seu problema, vc teria 2 CallbackHandler, um para o tradicional conta&senha e outro para a contra-senha.

imagine algo assim (nada como zero get's e set's

):

class ContaSenhaCallback implements Callback {
 public String conta;
 public String senha;
}

class ContrasenhaCallback implements Callback {
 public String desafio
 public String respostaDesafio
}

class CbHandler implements CallbackHandler{
 public String userName, password, contraSenha, respContraSenha;
 public void handle(Callback[] callbacks){
  for(int i=0; i<callbacks.length; i++){
   Callback cb = callbacks[i];
   if(cb instanceof ContaSenhaCallback ){
     /* set conta e senha */
   }
   if(cb instanceof ContrasenhaCallback ){
     if(contraSenha == null) { //1a. fase
       contraSenha = ((ContrasenhaCallback)cb).desafio;
       throw new AlgumaRuntimeXceptMinha();
     } else {
       ((ContrasenhaCallback)cb).desafio = contraSenha;
       ((ContrasenhaCallback)cb).respostaDesafio = respContraSenha;
     }
   }
  }
 }
}

class JaasLoginModule {
 public boolean login() ... {
  loginPassword =  new ContaSenhaCallback();
  Callback[] callbacks = new Callback[]{loginPassword};
  callbackHandler.handle(callbacks);
  /* autoriza conta&senha */

contraSenha = new ContrasenhaCallback();
  contraSenha.desafio = /*cria desafio*/
  callbacks = new Callback[]{contraSenha};
  callbackHandler.handle(callbacks);
  /* autoriza contra senha*/
 }
}
}

class MeuFilter {
 public void doFilter(request, response, chain) {
  public HttpSession session = request.getSession(true);
  Principal user = session.getAttr('user');
  if( user == null )
    /* forward to loginConta&Senha.jsp que faz post para LoginServlet */
 }
 else{
  /* crie um HttpServletRequestWrapper e coloque o seu principal nele */
  meurequest.setPrincipal(user);
 chain.doFilter(....)
 }
}

class LoginServlet { /*que não é interceptada pelo filter*/
  private getValue(String value, request, session){
   /*se value não está na sessão, veja se está no request*/
  }

public doPost(request, response){
   public HttpSession session = request.getSession(true);
   try{
    CbHandler cbh = new CbHandler();
    cbh.userName = getValue('username', request, session);
    cbh.password = getValue('pwd', request, session);
    cbh.contraSenha = getValue('Desafio, request, session);
    cbh.respContraSenha = getValue('respDesafio', request, session);
    LoginContext lc = new LoginContext( "<jaas ctx>", cbh );
    lc.login();
    Subject subj = lc.getSubject();
    Principal user = /* extraia do subj o principal que representa o seu usuário (os meus principals são quase um outro subject, por exemplo)*/
    session.setAttr('user', user);
   /*limpa da sessão os outros valores (conta, password, desafio, rep. desafio)*/
   }catch(AlgumaRuntimeXceptMinha arxm){
     session.setAttr('username', ...);
     session.setAttr('pwd', ...);
     session.setAttr('desafio', ...);
     /* forward para  loginComContraSenha.jsp que posta para LoginServlet */
   }
   }catch(...){
   }
   
  }
}

1) O usuário acessa um bookmark, seu filtro entra e pela sessão sabe que ele não está autenticado, e faz um forward para 1a. tela de login (conta e senha)
2) Quando o user fizer o post, a servlet entra extrai os valores do requet/session cria o callbackHandler, coloca as informações nele e submete ao jaas, se ocorrer uma exception sua que sinaliza o fim da 1a. fase vc exibe outro jsp que mostra o desafio (que está na sessão) e captura a resposta do mesmo.
3) No 2o. post, todos os dados estão presentes e o jaas pode autenticar

Ps- não garanto muito (leia-se: nada) esse pseudo-código-bacalhau

qualquer coisa grite

1) Cada tentativa de login é uma nova tentativa para o jaas (ele não guarda estado), se o seu módulo guarda e como ele guarda, é problema do seu módulo (Threadlocal, http session, cookie, hidden field, etc).
2) Recomendo vc usar 2 módulos, pq os requisitos para eles são diferentes.
3) Veja a documentação do Configuration p/ se familiarizar c/ os conceitos de required, requisite, etc: (http://java.sun.com/j2se/1.4.2/docs/api/javax/security/auth/login/Configuration.html)
e reveja tb o lance do callback/callback handler (http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/JAASRefGuide.html#CallbackHandler)
4) O grande truque (já reparou que todo kludge sujo é chamado de truque ?) do que te falei é reter estado (seja no cliente, seja no servidor) de forma que na 2a. invocação o jaas tenha toda a informação necessária para fazer a autenticação.

Só de curiosidade, quando o usuário vai fazer o login ele já possui toda as informações (conta, senha, contra senha) ou 1o. ele informa conta&senha e depois ele informa a contra senha, tipo challenge/response ?

para o 1a. caso o jaas funciona suave, para o 2o., forçando o jaas, é possível, mas é *meio* bacalhau (pode ser um handler só mas eu mostrar com 2 pq fica um pouco menos feio): um handler cuida da conta&senha tradicional e o outro da contra senha:

1 ) 1o. acesso, o usuário é redirecionado para o jsp (jsf, velocity, *) do logon
2 ) ele entra conta e senha e submit
3 ) o jaas invoca o 1o. handler que testa a conta&senha, coloca os dados ou o resultado na sessão e vota ok.
4 ) o jaas invoca o 2o. handler que cria o desafio, taca na sessão e vota contra.
5 ) como o jaas negou, a view de login é mostrada novamente
6 ) esta view é smart e sabe (pela sessão) que está na 2a. fase, pega o desafio e mostra
7 ) o usuário informa a contra senha e submit
8 ) o jaas faz a dança de novo, mas agora o 1o. handler recupera os dados da sessão e vota ok.
9 ) o 2o. handler pega a contra-senha, o desafio, testa e vota ok
10 ) o logon é aprovado e o cara entra na aplicação

Porém, contudo, todavia:
Para o trampo da sessão funcionar, o seu callback precisa expor a mesma, mas normalmente ele é hardcoded pelo app server (a classe é dele, e ele só cria as que ele sabe). Isso é um fatores que limitam o "uso criativo" do jaas num container.
Para vc fazer o "uso criativo" do jaas, com os seus callbacks, vc teria que invocar o jaas "manualmente", e talvez o security manager do container não fique empolgado com isso...

Dado isso, talvez a parada do servlet filter seja um *saco de gatos* menor.

vc precisa colocar este certificado num keystore e quando for fazer o ssl informar que este keystore é o seu truststore. As suas chaves+certificados se for o caso de um ssl mutuamente identificado vão ficar em outro keystore.

http://www-128.ibm.com/developerworks/java/library/j-customssl/

O seu problema é configurar o JSSE, depois vai ser o webservice

acarreta em ganhar um papelzinho e um pin que te espeta

Para o estilo de empresa em que o RH funciona na base do grep, ajuda sim - mas lembre-se de que numa estrevista técnica isso não conta tanto assim -- just my $.2

o que vc quer el gringos chamam de "breadcrumb trail" (lit: trilha de migalhas/pedaços de pão, suponho que vc lembre daquela estória de 2 crianças na floresta que quiseram marcar a trilha de volta com migalhas de pão, mas os passarinhos fizeram a festa com o pão e o 2 se perderam...)

olhe na implementação jsf que vc usa, ou outra que vc possa usar os componentes; Olhe o appfuse/jsf (http://demo.appfuse.org/appfuse-jsf/), se eu não me engano ele tem breadcrumb via filter

ajuda ?

http://blogs.sun.com/roller/page/alanbur?entry=building_win32_jni_code_using

resolve ?

Notícias, artigos e o maior fórum brasileiro sobre Java