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

Vou começar por comparar os dois serviços básicos, que podem ser os mais confusos, uma vez que partilham o mesmo nome: os bons e velhos Serviços de Domínio do Active Directory (ADDS, na sigla) e o Windows Azure Active Directory (AAD, na sigla).

O ADDS é utilizado há muito tempo (bem, 13 anos no mundo da informática parecem uma eternidade) para fornecer serviços de autenticação e autorização (AuthN e AuthZ) no centro de dados empresarial (o ambiente local). É bastante popular (87% das empresas da Fortune 1000 utilizam-no, segundo a Gartner) e tem-se revelado bastante fiável na prestação de todos os serviços necessários. (Aviso: eu costumava dar suporte a este produto quando trabalhava para a MSFT, por isso tenho uma certa simpatia por ele).

Mas, no panorama em constante mudança de hoje em dia, isso já não é, na verdade, suficiente, e a razão é: a nuvem!

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 surgiu a “nuvem”» (e o Facebook, que tem uma ligação muito concreta)

Ao analisar a forma como a AuthN e a AuthZ são geridas (ou não são geridas) na nuvem, é bastante compreensível que o Kerberos não seja suficientemente eficaz.

A razão para isso é que, ao utilizar o Kerberos, especifica-se 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 num ambiente na nuvem (Que chaves utilizaria se quisesse autenticar uma conta do Facebook num serviço do Google? Não existe um repositório central de identidades, nem um fornecedor central de chaves!).

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?).

No que diz respeito à camada de acesso aos dados, o mesmo se aplica. Embora o LDAP possa funcionar, há algo que faz mais sentido na gestão das ligações entre pessoas (sejam elas utilizadores da organização ou consumidores com fotos de perfil e murais), que é o Graph!

Utilizar o Graph como repositório de dados (especialmente como repositório de identidades) faz todo o sentido, uma vez que não é hierárquico como o LDAP e consegue, de facto, mostrar as «ligações» entre os utilizadores e os recursos da organização, permitindo-lhe gerir efetivamente uma identidade, em vez de toda uma hierarquia utilizada para organizar as identidades em «pastas», com base no que a organização tiver decidido que faz sentido para si.

É 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.

Eis uma breve tabela comparativa entre os dois:

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 permite a gestão de funções em serviços na nuvem deterceiros
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.

No próximo artigo, tentarei explicar como é que os dois podem estar interligados para criar uma identidade «híbrida» (que permita utilizar a mesma conta tanto para recursos locais como para serviços na nuvem).