Mesclando bancos de dados de autenticação de formulários juntos

1

Eu tenho um sistema baseado em ASP.Net; cópias idênticas do site são executadas em três servidores diferentes, todos os Windows 2008R2 executando o IIS7.5. Cada site tem seu próprio banco de dados de autenticação, com seus próprios usuários, funções, perfis, etc.

Gostaria de mesclar esses bancos de dados juntos, para que haja um único banco de dados de autenticação compartilhado pelos três servidores e, em seguida, os usuários possam efetuar login em qualquer um dos três servidores.

O site principal tem, de longe, o maior conjunto de usuários; os outros dois sites têm apenas um punhado de usuários / perfis, portanto, recriá-los manualmente é possível, se necessário. No entanto, o que preciso fazer para garantir que a hashing / salt da senha seja válida e utilizável em cada servidor?

É apenas um caso de definir MachineKey s idênticas em web.config ? Eu também preciso definir ApplicationId s idênticos na tabela aspnet_Applications ?

    
por KenD 29.06.2015 / 22:34

1 resposta

1

Se você mesclar as duas tabelas de associação menores no maior, quando você migrar as tabelas de associação para as tabelas maiores, você pode alterar o ApplicationID das novas linhas para ter o mesmo ApplicationID como o primeiro. Depois de fazer isso, você efetivamente terá 1 grande (ger) Aplicativo de usuários que é compartilhado pelos 3 aplicativos. Como você está usando hashing, (eu suponho que seu web.config tenha validação = SHA1), você não precisa se preocupar com a chave do computador, pois não é usado para validar logins - é para isso que serve o sal. A tecla Machine é usada para criptografar coisas como Session, Form Data e ViewState. Tudo bem se as chaves da máquina permanecerem diferentes para cada uma das aplicações. (Se você estivesse balanceando a carga de um único aplicativo em vários servidores, precisaria que eles fossem iguais.)

Agora, para algumas advertências.

  • Os nomes de usuário devem ser exclusivos em um banco de dados de associação, portanto, se houver duplicatas nos três aplicativos, você deverá determinar como proceder caso a caso. Espero que, se houver duplicatas, eles sejam a mesma pessoa repetindo o nome de usuário em ambos os aplicativos, mas isso não é necessariamente o caso. (Dois usuários diferentes poderiam ter o nome de usuário "Ken" em aplicativos diferentes, caso em que um deles terá que escolher um novo nome de usuário.) No caso em que é o mesmo usuário, eles podem ter senhas diferentes ou e-mails também um terá que vencer.
  • O mesmo usuário pode ter duas contas diferentes em aplicativos diferentes. Você provavelmente vai querer usar apenas um deles.
  • Os e-mails também podem ser configurados para serem exclusivos e, nesse caso, você terá um problema semelhante com nomes de usuários diferentes com o mesmo e-mail. Embora isso possa realmente ajudar você, pois será mais fácil isolar se o mesmo usuário tiver duas contas diferentes.
  • As funções terão diferentes RoleIDs e precisarão ser mescladas, e também as entradas UsersInRoles precisam ser atualizadas de acordo.
  • Se você estiver usando a tabela aspnet_Profile, e se alguns usuários tiverem contas em mais de um aplicativo, você terá que descobrir como mesclar os dados. Isso é verdade para todas as tabelas, mas com a maioria das outras tabelas você provavelmente escolherá apenas um campo do aplicativo mais popular (data do último login, IsUserLockedOut etc.). No entanto, para os dados do Perfil, ele deve ser mesclado contém vários pares nome / valor.
  • Isso não deveria ser dito, mas você vai querer fazer alguns testes bastante extensos. Minha lista de advertências não é exaustiva; Além disso, obviamente, isso pode ser uma alteração importante para o código de aplicativo personalizado.
por 07.07.2015 / 18:20