Gerenciamento de grandes bases de dados do usuário para single-signon

votos
6

Como você implementar um sistema com os seguintes objectivos:

  • Gerenciar a autenticação, autorização para centenas de milhares de usuários existentes atualmente fortemente integrados com a aplicação de um 3o partido do fornecedor (Queremos prender esses usuários para fora em algo que gerenciar e tornar nossos aplicativos funcionam contra ele, além de nossos vendedores 3rd party trabalhar contra ele).
  • Gerenciar informações de perfil associados a esses usuários
  • Deve ser capaz de ser acessado a partir de qualquer número de aplicações web em praticamente qualquer plataforma (Windows, * nix, PHP, ASP / C #, Python / Django, et cetera).

Aqui algumas implementações de amostra:

  • LDAP / AD Server para gerenciar tudo. Use esquema personalizado para todos os dados do perfil. Tudo pode autenticar contra o LDAP / AD e podemos armazenar todos os tipos de ACLs e dados do perfil em um esquema personalizado.
  • Use LDAP / AD para autenticação única, amarrar os usuários LDAP para um servidor de perfil / autorização mais robusto usando algum tipo de banco de dados tradicional (MSSQL / PostgreSQL / MySQL) ou documento com base DB (CouchDB, SimpleDB, et cetera). Use LDAP para autorização, em seguida, bateu o DB para o material mais avançado.
  • Use um banco de dados tradicional (relacional ou documento) para tudo.

Algum destes três o melhor? Existem outras soluções que se encaixam os objetivos acima e são mais fáceis de implementar?

** Devo acrescentar que quase todas as aplicações que serão autenticação no banco de dados de usuário estará sob nosso controle. As poucas pessoas de fora solitários serão as aplicações estamos removendo o banco de dados do usuário atual e talvez 1 ou 2 outros. Nada tão amplas que precisa de um servidor openID.

Também é importante saber que muitos desses usuários tiveram essas contas por 5-8 anos e conhecer os seus logins e senhas, et cetera.

Publicado 17/09/2008 em 00:08
fonte usuário
Em outras línguas...                            


5 respostas

votos
3

Há uma diferença entre autenticação e autorização / profiling por isso não forçar tanto necessariamente em uma única ferramenta. Sua segunda solução de usar LDAP para autenticação e um DB de autorização parece mais robusto como os dados LDAP é controlado pelo utilizador ea DB seria controlada por um administrador. Este último provavelmente se transformar em estrutura e complexidade ao longo do tempo, mas a autenticação é apenas que a autenticação. Separação dessas funções irá revelar mais manejável.

Respondeu 17/09/2008 em 00:26
fonte usuário

votos
2

Se você tem uma infra-estrutura ActiveDirectory existente, que será o caminho a percorrer. Isto será particularmente vantajoso para empresas que já tiveram servidores Windows criados para autenticação. Se este for o caso, eu estou inclinado para o seu primeiro ponto em "implementações de amostra".

Caso contrário, será um lance-se entre as opções AD e LDAP opensource.

Ele pode não ser viável para rolar o seu próprio esquema de autenticação para single-sign-on (especialmente considerando a grande quantidade de documentação e trabalho de integração que você pode ter que fazer), e, obviamente, não agrupar o servidor de autenticação com qualquer um dos aplicativos em execução no seu sistema (desde que você quer que ele seja capaz de ser independente da carga de tais aplicações).

Boa sorte!

Respondeu 17/09/2008 em 00:19
fonte usuário

votos
0

Temos locais diferentes, com cerca de 100 mil usuários e todos eles trabalham com bancos de dados normais. Se a maioria das aplicações pode acessar o db você pode usar esta solução.

Respondeu 17/09/2008 em 00:31
fonte usuário

votos
0

Use LDAP / AD para autenticação única, amarrar os usuários LDAP para um servidor de perfil / autorização mais robusto usando algum tipo de banco de dados tradicional (MSSQL / PostgreSQL / MySQL) ou documento com base DB (CouchDB, SimpleDB, et cetera). Use LDAP para autorização, em seguida, bateu o DB para o material mais avançado.

Respondeu 17/09/2008 em 00:29
fonte usuário

votos
-1

Você sempre pode implementar sua própria OpenID servidor. Já existe uma biblioteca Python para OpenID assim que deve ser bastante fácil.

Claro que você não precisa aceitar logins autorizados por outros servidores em suas aplicações. Aceitar credenciais autorizadas apenas por seu próprio servidor.

Edit: Eu encontrei uma implementação do protocolo de servidor OpenID em Django .

Edit2: Há uma vantagem óbvia na implementação OpenID para seus usuários. Eles serão capazes de fazer o login para StackOverflow com seus logins :-)

Respondeu 17/09/2008 em 00:14
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more