Temos um aplicativo da web em execução no Windows Azure, onde vários clientes podem fazer login. Ultimamente, mais e mais deles têm solicitado algum tipo de solução de logon único ou, pelo menos, uma sincronização de seus usuários locais/domínio com aqueles presente em nossa aplicação. Eu olhei para várias opções, mas realmente não encontrei uma que parecesse viável para mim. Abaixo listei o que estou observando, mas basicamente gostaria de alguns conselhos sobre como abordar esse problema.
Existem serviços de terceiros que podem fazer isso, mas geralmente eles exigem algum ou muito trabalho para serem implementados por nós e por nossos clientes. Isso também poderia significar que teríamos que implementar várias ou muitas dessas soluções, dependendo da preferência do cliente.
A maioria, senão todos, de nossos clientes terão um Active Directory local e seria perfeito se pudéssemos usá-lo de alguma forma também com nosso aplicativo. Conectar nosso aplicativo da web a um AD local não é realmente uma opção porque os administradores de sistema (compreensivelmente) não nos darão acesso a ele.
Também podemos configurar um AD no Azure. Então pensei que talvez pudéssemos sincronizar do AD local com nosso AD no Azure e partir daí. No entanto, ao testar a ferramenta Azure Active Directory Connect da Microsoft, ela me solicitou um login de administrador para nosso ambiente Azure. Obviamente não queremos dar aos nossos clientes acesso ao nosso portal Azure, então parece que isso não vai funcionar tão bem.
Outro problema nisso tudo é que sou programador e todo o material de AD está um pouco fora da minha zona de conforto e posso estar procurando nos lugares errados.
Alguém tem alguma experiência com isso e pode me indicar a direção certa?
Responder1
ADConnect é a maneira de sincronizar o diretório local com sua nuvem. Ele pede uma senha de nome de usuário para configurar a sincronização inicial e fazer alterações na sincronização se você estiver fazendo login novamente com a ferramenta. Você também precisaria de uma conta DA para um administrador local durante a configuração. Se você não tiver nenhuma ou nenhuma das duas contas, não será possível concluir a configuração.
Seguindo o que você está sugerindo, o Azure B2C é o que você deseja configurar. Caso contrário, configure a federação ADFS entre seus domínios e os domínios do cliente para que você não precise se preocupar em solicitar nomes de usuário/senhas. Presumo que seus aplicativos estejam cientes de declarações e que você tenha seu próprio Windows AD para permitir que o ADFS seja configurado.
Se você está tentando configurar um ambiente de teste ADFS, segui o blog de 4 partes para construir meu primeiro laboratório - espero que funcione bem para você também.
http://blogs.technet.com/b/askpfeplat/archive/2013/12/09/how-to-build-your-adfs-lab-on-server-2012-part-1.aspx http://blogs.technet.com/b/askpfeplat/archive/2013/12/23/how-to-build-your-adfs-lab-on-server-2012-part2-web-sso.aspx
Responder2
Se você configurar o aplicativo para oferecer suporte à autenticação SAML, um cliente poderá configurar seu ADFS (ou outro) para funcionar com seu AD. Normalmente é assim que isso é tratado no SSO para aplicativos de terceiros.
A maneira como isso funciona é que você ainda gerencia identidades e acesso ao aplicativo, mas os clientes podem pegar isso e vinculá-lo à sua própria "reivindicação" que pode conter nomes de usuários do AD. Isso é o que o ADFS e outras plataformas de identidade federativa fazem (a parte da federação). No entanto, você precisa fornecer uma maneira de criar confiança entre os provedores de identidade (os seus e os deles).
Do seu lado, você pode criar um provedor de identidade personalizado, usar um serviço de terceiros ou implantar um servidor de federação como o ADFS. Mas também existem outros (comerciais e de código aberto), como PingFederate e Shibboleth. Existem literalmente centenas de opções lá. Se você deseja um SDK - Ping Identity (desenvolvedores PingFederate) ofereça um para vários idiomas (Java, C#, etc). Tenho certeza de que também existem SDKs de código aberto para ajudar com isso.
Identidade é um tópico complexo - quanto mais você puder transferir isso para uma empresa ou equipe dedicada, melhor será para você (o Azure B2C está em versão prévia, conforme indicado em outras respostas, mas observe terceiros se quiser avançar mais rápido)