Estratégia para logon único com aplicativos legados

Question

Estou me perguntando quais estratégias as pessoas usam para reduzir o login em aplicativos legados e qual a eficácia delas?

Temos uma intranet baseada em ASP.Net e possuímos muitos aplicativos legados, mas não todos.Também temos o BizTalk e estamos considerando o uso de seu mecanismo SSO.

Answer 1

Um bom compromisso entre esforço/retrabalho e a conveniência do logon único é continuar a manter uma lista de usuários, privilégios, funções, etc. no aplicativo legado.Faça as alterações necessárias para conectar automaticamente o usuário ao seu aplicativo com base na conta de usuário (geralmente na conta do Windows ou de rede).

Atualmente, estou executando alguns aplicativos que usam esse método de login e isso os faz parecer mais integrados, mesmo que não estejam.

Outra vantagem que descobrimos é que isso impede que as pessoas compartilhem senhas em aplicativos legados.É muito menos provável que eles forneçam uma senha de administrador que também dê a outras pessoas acesso ao seu e-mail ou detalhes da folha de pagamento!

Answer 2

Armazenamento de múltiplas identidades por aplicativo?Pode não ser uma solução de logon único, mas você já tentou procurar algo que seja uma solução mais direcionada, como o MS Identity Lifecycle Manager?Ele simplificará a sincronização de identidade entre aplicativos e também é conectável, o que significa que você pode conectar seu próprio código para fazer a sincronização entre diferentes sistemas.Portanto, se você alterar as informações de identidade (ou seja,informações de login) no portal ILM, você pode propagá-los para diferentes sistemas.A mesma coisa para provisionar e desprovisionar identidade.Ponto único de entrada.
Eu suponho que você também pode usar o biztalk para coisas semelhantes.

Quanto à solução de logon verdadeiramente único, onde você fez login apenas uma vez e não precisa fazer login novamente em aplicativos diferentes.Ainda não encontrei um.

Suponho que se seus aplicativos legados tiverem um módulo de provedor de identidade conectável, isso é viável, o que significa que você pode personalizar o sistema de login para conectar-se à sua única fonte de identidade, seja lá o que for.

Answer 3

Fizemos duas coisas com contas legadas.(aplicativos legados baseados na web)

Primeiro mapeamos as contas herdadas para suas contas de logon do sistema (em execução no Windows Active Directory).

Uma tela de logon de fachada foi então aplicada sobre os aplicativos legados (baseados na web), isso solicitaria o logon do AD, que reverteria o mapa para a conta de logon dos aplicativos legados e atribuiria os direitos apropriados ao usuário, usando o legado modelo de segurança de sistemas.O usuário recebeu um token pela sessão que manteve as portas abertas para ele.

Isso nos deu a vantagem de não precisar atualizar aplicativos legados (por exemplo, o que aconteceria se o aplicativo x tivesse apenas números para ID e o usuário usasse um logon do Windows (alfanumérico) e também obtivesse um logon único psuedo da perspectiva do cliente.

A outra opção que fazia sentido era a nova tela de logon, ela verificaria vários repositórios de segurança, portanto, mesmo que o usuário não decidisse usar o logon do Windows, ele ainda poderia fazer logon com o nome da conta herdada.Obviamente, isso tem alguns efeitos colaterais, mas também pode ajudar a aliviar a dor de transição que os usuários finais às vezes sentem ao mover-se entre sistemas.

Existem também programas como o Logon único do Citrix XenApp que adotam uma abordagem totalmente diferente da questão.

Answer 4

Além dos pontos de Jimmy sobre o uso do ILM, este sistema específico permite a integração com o serviço AD PCNS (Password Change Notification Service), que pode ser usado com o ILM (o ILM "vê" o evento de alteração de senha e pode publicá-lo em outros aplicativos consumidores / serviços) para pelo menos garantir que, à medida que a senha de um usuário muda em um sistema, ela seja refletida em outros.