Começo por dizer que as tecnologias de identidade actuais podem ser muito confusas. Existem muitos serviços (na era da nuvem, tudo é um serviço), protocolos, soluções, SDK, tecnologias e produtos destinados a resolver o problema da identidade.

Começarei por comparar os dois básicos, que poderão ser os mais confusos, uma vez que partilham o mesmo nome: os bons e velhos Serviços de Domínio do Active Directory (ADDS) e o Active Directory do Windows Azure (AAD).

O ADDS é utilizado há muito tempo (bem, 13 anos em computadores parecem muito tempo) para fornecer serviços de autenticação e autorização (AuthN e AuthZ) no centro de dados da empresa (o ambiente local). É bastante popular (87% das empresas da Fortune 1000 utilizam-no, com base na Gartner) e tem sido bastante sólido no fornecimento de todos os serviços necessários. (Declaração de exoneração de responsabilidade: eu costumava trabalhar para a MSFT, por isso até gosto do produto).

Mas no actual panorama de mudança já não é suficiente, e a razão é: Ze Cloud!

Quando olhamos para o centro de dados local e para o ambiente de nuvem, existem muitas diferenças nos protocolos e soluções que estão a ser utilizados devido a várias razões, mas as três principais são: Segurança, Privacidade e Interoperabilidade.

Olhando para os protocolos utilizados no centro de dados local para autenticação e autorização, podemos dizer com segurança que o Kerberos é o protocolo mais comum actualmente, e olhando para o acesso aos dados utilizado actualmente nos centros de dados para aceder ao armazenamento de identidades, diria que o LDAP é o protocolo mais comum, sendo suportado por quase todos os fornecedores de directórios existentes.

Portanto, é exactamente isto que o ADDS faz: Autentica utilizadores e autoriza o acesso a recursos utilizando o Kerberos e fornece acesso ao armazenamento de dados utilizando o protocolo LDAP.

Mas depois veio a nuvem" (e o Facebook, que tem uma ligação muito tangível)

Olhando para a forma como o AuthN e o AuthZ são geridos (ou não geridos) na nuvem, é bastante compreensível que o Kerberos não seja suficientemente bom.

A razão é que, ao utilizar o Kerberos, o utilizador especifica as chaves que são utilizadas para encriptar os bilhetes Kerberos e que são fornecidas por uma única fonte autorizada. Isso não é possível no ambiente de nuvem (que chaves usaria se quisesse autenticar uma conta do Facebook num serviço do Google? Não existe um armazenamento de identidade central e não existe um fornecedor de chaves central!).

Foi então que surgiram o SAML, o OAuth, o OpenID e vários outros. Todas elas são tecnologias que permitem o início de sessão federado. (Basicamente, como é que posso fazer um início de sessão único do Facebook para o Google sem ter de introduzir as minhas credenciais duas vezes). Cada uma tem a sua própria especificação, mas o objectivo principal é permitir a autenticação em diferentes serviços de diferentes fornecedores de serviços/nuvem (já mencionei a interoperabilidade?).

Olhando para a camada de acesso aos dados, a mesma coisa se aplica. Embora o LDAP possa funcionar, há algo que faz mais sentido quando se trata de gerir a ligação entre pessoas (quer sejam utilizadores organizacionais, quer sejam consumidores com imagens de perfil e paredes), que é o Graph!

A utilização do Graph para o armazenamento de dados (especialmente um armazenamento de identidades) faz todo o sentido, uma vez que não é hierárquico como o LDAP e pode realmente mostrar "ligações" entre os utilizadores e os recursos na organização, permitindo-lhe realmente gerir uma identidade, em vez de toda uma hierarquia utilizada para organizar as identidades em "Pastas" com base no que a organização decidiu que faz sentido para eles.

É aqui que o Azure Active Directory entra em jogo. O AAD é um IDaaS (Identity as a Service) baseado na nuvem fornecido pela Microsoft que utiliza normas abertas (SAML, por exemplo) para autenticar utilizadores e permitir a federação de identidades entre serviços na nuvem, bem como o modelo de dados Graph para consultar e gerir objectos.

Indicamos em seguida uma breve tabela de comparação entre ambos:

Directório Activo do Azure Serviços de domínio do Active Directory
Fornece SSO e repositório de utilizadores para serviços em nuvem. Fornece SSO e gestão de identidades para serviços no local.
Fornecer uma plataforma extensível para a gestão de funções deterceiros Não fornece a capacidade de gestão de funções de serviços de nuvem de terceiros
Fornece uma plataforma de identidade na nuvem multi-tenant Baseia-se numa plataforma de um único inquilino no local
Utilizar as normas da indústria para a autenticação na nuvem Utilizar as normas da indústria para a autenticação no local
Utiliza a API Graph para aceder aos dados Utiliza o protocolo LDAP para acesso aos dados

Em conclusão, o ADDS dá-nos a possibilidade de iniciar sessão na nossa rede empresarial, aceder aos recursos localizados na rede empresarial e permite que os serviços consultem informações sobre objectos como utilizadores, grupos e recursos.

O AAD permite a capacidade de iniciar sessão nos nossos serviços de nuvem, aceder a recursos localizados na nuvem e permite que os serviços de nuvem consultem informações sobre objectos.

Espero que tenha ajudado na compreensão de ambos.

Na próxima publicação, tentarei abordar a forma como as duas podem ser interligadas para obter uma identidade "híbrida" (uma que permita utilizar a mesma conta tanto para recursos no local como para serviços na nuvem).