O logon único com o LDAP ainda é recomendado hoje para integrar um monte de ferramentas de código aberto?

8

Estamos conduzindo um exercício com uma instituição pública para instalar diferentes ferramentas de código aberto para que experimentem e vejam o que mais lhes convém.

Assim, estamos instalando:

  • um wiki (dokuwiki)
  • mediagoblin
  • gnu social
  • etherpad
  • ethercalc

e possivelmente mais alguns.

Pensamos em usar o LDAP para harmonizar os logins.

Mas muitas vezes parece que os plugins LDAP não são mais mantidos, e a configuração é difícil de funcionar bem, algumas ferramentas têm documentos LDAP insuficientes.

Ainda hoje é uma boa ideia fazer isso via LDAP? O OAuth é talvez uma escolha melhor?

Eu sei que isso não é uma questão de código, mas o que gostaríamos de entender é se devemos nos ater a nossa decisão de ir ao LDAP ou se devemos considerar outros caminhos. Muito obrigado

    
por Fabio 07.09.2014 / 22:12

2 respostas

13

O LDAP não pode fornecer o Logon único. Há uma grande diferença entre poder usar os mesmos usuários e ter Single Sign On, o que significa que você faz login em todos os sistemas de uma vez, com um único formulário de login. Caso contrário, o LDAP é perfeitamente viável para usar as mesmas informações de login em todos os sistemas.

OAuth é apenas um protocolo para fazer o logon e pode usar o LDAP como back-end para o gerenciamento de usuários.

    
por 07.09.2014 / 22:16
1

No mundo universitário, o sistema Apereo [anteriormente denominado Jasig] CAS é uma forma comum para fazer logon único para grandes conjuntos de aplicativos da web. Com o CAS, o usuário só insere sua senha no servidor de autenticação - aplicativos individuais validam um ticket único em vez de ver a senha do usuário. Essa é uma grande vitória de segurança ao lidar com aplicativos desenvolvidos por muitos grupos e fornecedores internos, já que nenhum dos aplicativos jamais teve acesso às senhas dos usuários.

Existem inúmeras bibliotecas cliente CAS disponíveis para a maioria dos ambientes de programação e o suporte CAS integrado está se tornando mais comum para aplicativos usados ou vendidos para universidades. Além do principal "Jasig CAS Server", há também vários servidores adicionais disponíveis, incluindo o servidor Ruby CAS e um module para Drupal que pode atuar como um servidor CAS para autenticar aplicativos adicionais no banco de dados Drupal.

O próprio Jasig CAS Server está escrito em Java e pode ser apoiado por qualquer número de manipuladores de autenticação , incluindo:

  • Banco de dados
  • JAAS
  • LDAP
  • Legado
  • OAuth 1.0 / 2.0, OpenID
  • RADIUS
  • SPNEGO (Windows)
  • Confiável (REMOTE_USER)
  • X.509 (certificado SSL do cliente)

O servidor Jasig CAS pode atuar como uma fonte de autenticação para aplicativos por meio de vários protocolos diferentes usados para o Single Sign On:

  • protocolo CAS 1/2/3
  • protocolo SAML 1.1 / 2.0
  • protocolo OAuth
  • protocolo OpenId

Ele pode até mesmo ser usado como a autenticação por trás de um provedor Shibboleth ou usar um cliente Shibboleth como um back-end de autenticação.

Observação: a organização da Jasig está se fundindo com a organização Apereo, portanto, algumas URLs podem mudar no futuro. / em>

    
por 15.09.2014 / 20:33