SOA - Boas Praticas Autenticação

Alguém ?

guilherme.dio:

Alguém ?

Caro Guilherme,

de uma olhada nesse documento:

http://www.w3.org/2001/sw/Europe/events/foaf-galway/papers/fp/token_based_authentication/

Veja uma pergunta no stack sobre autenticação usando tokens:

http://stackoverflow.com/questions/1592534/what-is-token-based-authentication

Espero ter ajudado.

JackOld:

Caro Guilherme,

de uma olhada nesse documento:

http://www.w3.org/2001/sw/Europe/events/foaf-galway/papers/fp/token_based_authentication/

Veja uma pergunta no stack sobre autenticação usando tokens:

http://stackoverflow.com/questions/1592534/what-is-token-based-authentication

Espero ter ajudado.

JackOLD, obrigado pela resposta.

Porém na realidade, minha dúvida não se trata do token em sí, mas sim da melhor arquitetura que devo escolher em meu caso.

Pois estou indeciso entre sempre criar uma autenticação em cada serviço, assim sempre que receberem um request eu valido o token.
Ou crio um webservice central somente para autenticação, ao qual gera um token, assim sempre que um usuario requisitar algo do serviço X, este serviço remotamente chama o serviço de autenticação e verifica se o token é valido ou nao antes de continuar com o processo.

Porém na realidade, minha dúvida não se trata do token em sí, mas sim da melhor arquitetura que devo escolher em meu caso.

Pois estou indeciso entre sempre criar uma autenticação em cada serviço, assim sempre que receberem um request eu valido o token.
Ou crio um webservice central somente para autenticação, ao qual gera um token, assim sempre que um usuario requisitar algo do serviço X, este serviço remotamente chama o serviço de autenticação e verifica se o token é valido ou nao antes de continuar com o processo.

Você já está autenticando no google, então você já possui o token e já enviou ao usuário, o que você precisa é só autenticar esse token em cada request. Não é necessário logar ele toda vez que fizer um request ao seu serviço. Creio que o método do google seja Oauth2, então o mesmo deveria se autenticar utilizando SSL.

Espero ter ajudado, abraços!

clunsde:

Porém na realidade, minha dúvida não se trata do token em sí, mas sim da melhor arquitetura que devo escolher em meu caso.

Pois estou indeciso entre sempre criar uma autenticação em cada serviço, assim sempre que receberem um request eu valido o token.
Ou crio um webservice central somente para autenticação, ao qual gera um token, assim sempre que um usuario requisitar algo do serviço X, este serviço remotamente chama o serviço de autenticação e verifica se o token é valido ou nao antes de continuar com o processo.

Você já está autenticando no google, então você já possui o token e já enviou ao usuário, o que você precisa é só autenticar esse token em cada request. Não é necessário logar ele toda vez que fizer um request ao seu serviço. Creio que o método do google seja Oauth2, então o mesmo deveria se autenticar utilizando SSL.

Espero ter ajudado, abraços!

Clunsde, obrigado pela dica,

Porém não estou utilizando nada do google, nem me conecto a ele, eu só dei um exemplo de como funcionam os serviços deles.
O meu prblema é que eu estou desenvolvendo diversos webservices proprios que compõem um sistema ao todo…e queria saber qual a melhor abordagem para a autenticação dos usuários:

1 - Cada serviço realizar a autenticação em sí mesmo
2 - Criar um webservice central de autenticação que todos os serviços o chamam para verificar se o usuario é valido.

Os dois modos funcionam, porém gostaria de saber qual a “boa pratica” aqui.

guilherme.dio:

Porém não estou utilizando nada do google, nem me conecto a ele, eu só dei um exemplo de como funcionam os serviços deles.
O meu prblema é que eu estou desenvolvendo diversos webservices proprios que compõem um sistema ao todo…e queria saber qual a melhor abordagem para a autenticação dos usuários:

1 - Cada serviço realizar a autenticação em sí mesmo
2 - Criar um webservice central de autenticação que todos os serviços o chamam para verificar se o usuario é valido.

Os dois modos funcionam, porém gostaria de saber qual a “boa pratica” aqui.

É requisito fazer o login a cada projeto ou manter um login único? Quando é login único, você vai ter que centralizar uma lógica onde todos os projetos acessarão. Quando o login é separado vc precisará fazer a lógica em cada projeto (até mesmo repetir código), mas a complexidade vai diminuir.

No seu caso eu vejo que isso é mais problema de requisito do que boa prática.

guilherme.dio:

Clunsde, obrigado pela dica,

Porém não estou utilizando nada do google, nem me conecto a ele, eu só dei um exemplo de como funcionam os serviços deles.
O meu prblema é que eu estou desenvolvendo diversos webservices proprios que compõem um sistema ao todo…e queria saber qual a melhor abordagem para a autenticação dos usuários:

1 - Cada serviço realizar a autenticação em sí mesmo
2 - Criar um webservice central de autenticação que todos os serviços o chamam para verificar se o usuario é valido.

Os dois modos funcionam, porém gostaria de saber qual a “boa pratica” aqui.

Quem irá se comunicar com os serviços? Outros sistemas? Ou o usuário final? Se for outro sistema, o mesmo pode ser implementado em várias formas, você pode desbloquear acesso apenas por IP, você pode utilizar certificados digitais, você pode utilizar tokens, etc. Se for para usuário final, você pode utilizar da mesma forma que o google (OAuth 2). O spring security já possui as implementações necessárias para o OAuth 2.

Hebert Coelho:

guilherme.dio:

Porém não estou utilizando nada do google, nem me conecto a ele, eu só dei um exemplo de como funcionam os serviços deles.
O meu prblema é que eu estou desenvolvendo diversos webservices proprios que compõem um sistema ao todo…e queria saber qual a melhor abordagem para a autenticação dos usuários:

1 - Cada serviço realizar a autenticação em sí mesmo
2 - Criar um webservice central de autenticação que todos os serviços o chamam para verificar se o usuario é valido.

Os dois modos funcionam, porém gostaria de saber qual a “boa pratica” aqui.

Parceiro, não creio que exista uma boa prática mas sim requisito.

É requisito fazer o login a cada projeto ou manter um login único? Quando é login único, você vai ter que centralizar uma lógica onde todos os projetos acessarão. Quando o login é separado vc precisará fazer a lógica em cada projeto (até mesmo repetir código), mas a complexidade vai diminuir.

No seu caso eu vejo que isso é mais problema de requisito do que boa prática.

Ola Hebert, obrigado pelo conselho.

No meu caso, a especificação é justamente login unico para todos os serviços, bem parecido com o esquema do google(onde você acessa todos os services deles com seu email).

Portanto o melhor seria criar um webservice central de autenticação, e todos os outros serviços ao receberem o request, fazem uma chamada primeiro a este serviço de autenticação e verifica se o usuario é valido e se esta na sessão.

Se puderem me dar outras sugestões da arquitetura, fico feliz, pois no momento estou definindo a melhor abordagem mesmo.

OAuth parece ser uma solução pra você, mas tome cuidado, pois ele é um protocolo um tanto quanto polêmico.

O próprio autor do protocolo abandonou a versão 2.0 dizendo que é um protocolo ruim: http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/

Sem falar em relatos de pessoas que invadiram sistemas que usam o protocolo: http://homakov.blogspot.com.br/2013/02/hacking-facebook-with-oauth2-and-chrome.html

Rodrigo Sasaki:

OAuth parece ser uma solução pra você, mas tome cuidado, pois ele é um protocolo um tanto quanto polêmico.

O próprio autor do protocolo abandonou a versão 2.0 dizendo que é um protocolo ruim: http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/

Sem falar em relatos de pessoas que invadiram sistemas que usam o protocolo: http://homakov.blogspot.com.br/2013/02/hacking-facebook-with-oauth2-and-chrome.html

Muito bom, já tinha ouvido falar porém nunca usei. Vou ler a documentação.

Entretanto tenho uma outra muralha que pode me atrapalhar, já que o login/senha dos usuarios que utilizaram o sistema não fica em tabelas como em um sistema comum, mas as credenciais são diretas do Oracle.
Ou seja, o login do usuario é um login do Oracle, pois foi todo estruturado utilizando regras de roles entre outras politicas de acesso do Oracle, assim um usuario realizando um mesmo select que outro não recebe as mesmas informações já que os dois possuem acessos diferentes.

Então nesse caso, para autenticar e gerar o token será algo meio “estranho” se comparado a um sistema comum onde você acessa a base com um login unico da aplicação e vê se o usuario existe na tabela de usuarios.
No meu caso vou ter que tentar conectar, se der o usuario é valido, senão não. A partir disso vou ter que gerar o token e gravar um sessão para este usuario no banco de serviços.

Porém parando para pensar, não vejo uma vantagem do uso do token aqui, por conta deste acesso do Oracle…será que é mesmo vantagem ?

guilherme.dio:

Entretanto tenho uma outra muralha que pode me atrapalhar, já que o login/senha dos usuarios que utilizaram o sistema não fica em tabelas como em um sistema comum, mas as credenciais são diretas do Oracle.
Ou seja, o login do usuario é um login do Oracle, pois foi todo estruturado utilizando regras de roles entre outras politicas de acesso do Oracle, assim um usuario realizando um mesmo select que outro não recebe as mesmas informações já que os dois possuem acessos diferentes.

Então nesse caso, para autenticar e gerar o token será algo meio “estranho” se comparado a um sistema comum onde você acessa a base com um login unico da aplicação e vê se o usuario existe na tabela de usuarios.
No meu caso vou ter que tentar conectar, se der o usuario é valido, senão não. A partir disso vou ter que gerar o token e gravar um sessão para este usuario no banco de serviços.

Porém parando para pensar, não vejo uma vantagem do uso do token aqui, por conta deste acesso do Oracle…será que é mesmo vantagem ?

Existem sistemas que tem apenas um servidor e um front end que se comunicam por token e nada mais.

Token no banco? O que você entende por token? Pq esse token ñ é uma informação criptografada que só seu projeto terá a chave? Assim você consegue validar as informações… Vc não vai ter um serviço único de login? basta que esse cara também tenha o papel de proxy, ele quem chamará seu servidor e não o usuário. Ou seja, se o usuário chamar seuProjeto/aaa você validará a chamada, se foi tudo com sucesso, aí você pode fazer o request (ao servidor escolhido) e depois retornar a resposta…

Dica, se quiser conhecer um pouco mais, pesquise ou poste no fórum: www.soacloud.com.br, especializado no assunto.