JOSSO o Single Sign On que funciona!
Construir uma tela de login é um operação relativamente simples que os desenvolvedores passam pelo menos uma vez na vida. Já vi empresas gastarem muito dinheiro em consultorias e soluções de autenticação que não funcionavam.
Autenticar não é o suficiente. Autenticar é só a ponta do iceberg, o bixo pega mesmo quando falamos de autorização. Mas antes de que eu avance muito no assunto, vou definir o que é e o que um SSO deve fazer:
Problemas. Falando de Java agora. As ferramentas Open Source Java de SSO tem diversos problemas começando pela documentação os exemplos são deveras simples e muito incompletos. Depois vem as dependências. Uma solução de SSO é por natureza complicada. Por que envolve diversos protocolos, componentes e plataformas.
Nenhuma ferramenta de SSO hoje no mercado open source oferece uma boa solução quanto autorização. Muitas vezes isso tem de ser desenvolvimento em casa, mas próprias empresas. Nesse caso pense bem em chamar uma consultoria antes por que seria uma consultoria de autenticação e isso é muito simples não se paga.
Uma boa solução Open Source em Java?
JOSSO. É um SSO open source escrito em Java. Apesar de estar na lista das ferramentas com documentação fraca a solução deles é boa. O mais importante é que funciona! Além do mais é de fácil customização, logo você pode integrar sistemas feitos em outras linguagens com ele sem maiores esforços.
SSOs em geral são de natureza WEB, Se você tem aplicações desktop ai já são outros problemas. Vai ter que desenvolver uma integração. Eu já fiz isso! Fiz uma integração com o Spring Security. Teve uma amigo meu que integrou o JOSSO com Delphi, usando os WEB-Services que o JOSSO disponibiliza.
O que é o Futuro do SSO?
é o canal! Esse é um sistema de identificação que já está sendo muito utilizado pela internet, o Google por exemplo usa OpenID em tudo. Com um único ID e com uma única senha o usuário pode se logar em diversos sites na internet sem ter que se recadastrar. Você já deve ter um OpenID, se você é usuário da AOL, ou da Yahoo ou do Blogger então você já tem um OpenID.
Sim, já existem implementações open source em Java. Mas ainda não são estáveis o suficiente para serem consideradas com solução corporativa. E nesse caso também não existe uma API ou formas mais avançadas de controle de autorização.
O OpenID ainda é considerado inseguro por alguns. Isso se da pelo fato de que a segurança fica a cargo do site que você está autenticando, nada impede que eles apliquem um homem do meio e roubem o seu ID.
Para solucionar esse tipo de problema poderíamos utilizar os cartões. Também conhecidos como I-Cards ou Info-Cards. Sim, existem soluções open source para I-Cards em Java, porem não são estáveis também.
No inicio do post disse que um SSO é por natureza complexo, mas a soluções com Cartões e OpenID juntos são mais complexas ainda do que um SSO tradicional. Existem, algumas soluções open source em Java, mas todas são muito instáveis e algumas apresentam diversos erros de e problemas para instalação e configuração.
Na minha opinião usa solução com OpenID + Cartões é uma solução muito boa de autenticação, mas hoje ainda se mostra inviável e novamente provavelmente isso não vai resolver seus problemas de autorização.
Mas que raios de problemas de autorização?
falei tanto nisso que se eu não explicasse acho que estaria com problemas :). Mas o que ocorre é o seguinte se você está utilizando SOA por exemplo e tem 3 sistemas corporativos, você vai querer colocar SSO nos 3 e vai querer que todos autentiquem e usem a mesma base de dados de usuários.
Porem e se um sistema foi feito em Swing com Spring o outro em Struts e o outro em SWT com EJB, eu lhes pergunto como fica a autorização? Como vocês fazem para controlar quem pode fazer o que? Bom ai entramos no mundo da autorização, é complicado. Muitas vezes precisamos de permissões customizadas do tipo tais usuários podem ver tal tela e outros não podem. Até ai é fácil a solução default de roles dos SSOs tradicionais do mercado resolvem mas e coisas do tipo:
Então você integra o JOSSO ao Spring Security e tudo pronto. Basta escrever um provider de acesso ao JOSSO no Spring Security, você só tem que acessar o WEB-Service do JOSSO nesse provider e converter os objetos do JOSSO para os objetos do Spring Security.
Autenticar não é o suficiente. Autenticar é só a ponta do iceberg, o bixo pega mesmo quando falamos de autorização. Mas antes de que eu avance muito no assunto, vou definir o que é e o que um SSO deve fazer:
- Centralizar o acesso aos dados
- Método padronizado de se autenticar em um sistema
- Login em 1, acesso em todos os sistemas
- Auditoria
- Autorização de acesso a recursos
Problemas. Falando de Java agora. As ferramentas Open Source Java de SSO tem diversos problemas começando pela documentação os exemplos são deveras simples e muito incompletos. Depois vem as dependências. Uma solução de SSO é por natureza complicada. Por que envolve diversos protocolos, componentes e plataformas.
Nenhuma ferramenta de SSO hoje no mercado open source oferece uma boa solução quanto autorização. Muitas vezes isso tem de ser desenvolvimento em casa, mas próprias empresas. Nesse caso pense bem em chamar uma consultoria antes por que seria uma consultoria de autenticação e isso é muito simples não se paga.
Uma boa solução Open Source em Java?
JOSSO. É um SSO open source escrito em Java. Apesar de estar na lista das ferramentas com documentação fraca a solução deles é boa. O mais importante é que funciona! Além do mais é de fácil customização, logo você pode integrar sistemas feitos em outras linguagens com ele sem maiores esforços.
SSOs em geral são de natureza WEB, Se você tem aplicações desktop ai já são outros problemas. Vai ter que desenvolver uma integração. Eu já fiz isso! Fiz uma integração com o Spring Security. Teve uma amigo meu que integrou o JOSSO com Delphi, usando os WEB-Services que o JOSSO disponibiliza.
O que é o Futuro do SSO?
é o canal! Esse é um sistema de identificação que já está sendo muito utilizado pela internet, o Google por exemplo usa OpenID em tudo. Com um único ID e com uma única senha o usuário pode se logar em diversos sites na internet sem ter que se recadastrar. Você já deve ter um OpenID, se você é usuário da AOL, ou da Yahoo ou do Blogger então você já tem um OpenID.Sim, já existem implementações open source em Java. Mas ainda não são estáveis o suficiente para serem consideradas com solução corporativa. E nesse caso também não existe uma API ou formas mais avançadas de controle de autorização.
O OpenID ainda é considerado inseguro por alguns. Isso se da pelo fato de que a segurança fica a cargo do site que você está autenticando, nada impede que eles apliquem um homem do meio e roubem o seu ID.
Para solucionar esse tipo de problema poderíamos utilizar os cartões. Também conhecidos como I-Cards ou Info-Cards. Sim, existem soluções open source para I-Cards em Java, porem não são estáveis também.
No inicio do post disse que um SSO é por natureza complexo, mas a soluções com Cartões e OpenID juntos são mais complexas ainda do que um SSO tradicional. Existem, algumas soluções open source em Java, mas todas são muito instáveis e algumas apresentam diversos erros de e problemas para instalação e configuração.
Na minha opinião usa solução com OpenID + Cartões é uma solução muito boa de autenticação, mas hoje ainda se mostra inviável e novamente provavelmente isso não vai resolver seus problemas de autorização.
Mas que raios de problemas de autorização?
falei tanto nisso que se eu não explicasse acho que estaria com problemas :). Mas o que ocorre é o seguinte se você está utilizando SOA por exemplo e tem 3 sistemas corporativos, você vai querer colocar SSO nos 3 e vai querer que todos autentiquem e usem a mesma base de dados de usuários.
Porem e se um sistema foi feito em Swing com Spring o outro em Struts e o outro em SWT com EJB, eu lhes pergunto como fica a autorização? Como vocês fazem para controlar quem pode fazer o que? Bom ai entramos no mundo da autorização, é complicado. Muitas vezes precisamos de permissões customizadas do tipo tais usuários podem ver tal tela e outros não podem. Até ai é fácil a solução default de roles dos SSOs tradicionais do mercado resolvem mas e coisas do tipo:
- Determinados usuários não podem clicar em um botão de salvar
- Determinados usuário não podem ver algumas colunas em consultas
- Um usuário de poderes maiores de pode executar operações sem deslogar o usuário corrente.
- Determinados usuário podem não ver alguns itens de menu
Então você integra o JOSSO ao Spring Security e tudo pronto. Basta escrever um provider de acesso ao JOSSO no Spring Security, você só tem que acessar o WEB-Service do JOSSO nesse provider e converter os objetos do JOSSO para os objetos do Spring Security.
