Como Single Sign-On Funciona no Office 365?
O Single sign-on, também chamado de Federação de identidades, fornece aos usuários a capacidade de usar suas credenciais corporativas para obter single sign-on (SSO) para serviços de nuvem como o Microsoft Office 365. Em geral, logon único usa um modelo de confiança, com base nas packs de token assinados, onde um servidor de Federação no local é usado para gerar tokens assinados para usuários autenticados. Em caso do Office 365, a Microsoft usa o protocolo WS-Federation, conforme descrito no TechNet. Além disso, a especificação formal para o protocolo WS-Federation pode ser encontrada aqui.
Este artigo descreve como single sign-on funciona no Office 365, concentrando-se na interação dos componentes-chave envolvidos – o cliente, os serviços de Federação do Active Directory (AD FS) server 2.0 (usados para agrupar seu Active Directory para os serviços Office 365), Office 365 e o Microsoft Federation Gateway.
Em um nível de conhecimento de fácil compreensão temos:
1- O AD FS 2.0 server autentica o usuário no Active Directory, gera um token de logon de segurança Assertion Markup Language (SAML) 1.1 e criptografa-lo usando um certificado (auto-assinados) local. Esse token de logon SAML contém informações (conhecidas como créditos ou afirmações de segurança) originadas do Active Directory que permite que a Microsoft Federation Gateway coincidir com o usuário “copiado” para uma identidade de nuvem que possui:
- O nome de princípio de usuário (UPN) do usuário
- Um identificador exclusivo, identificador renomeado seguro para o usuário, que por padrão é o GUID de objeto do Active Directory
2 – A máquina cliente passa esse token de logon SAML 1.1 para Microsoft Federation Gateway. Importante: O cliente não é capaz de descriptografar o token
3 – O Microsoft Federation Gateway descriptografa o token de logon SAML 1.1 usando o certificado compartilhado anteriormente,localiza o usuário correspondente e emite um token de serviço assinado que necessita de serviços no Microsoft Office 365
É importante observar que cada usuário no local também é representado como uma identidade baseada em nuvem; as informações dentro do token de logon SAML 1.1 permitem que o Microsoft Federation Gateway ligue as duas identidades e passe o token de serviço para Office 365. Com o single sign-on, a identidade baseados em nuvem não tem uma senha associada e deve ser autenticada pelo Active Directory no local. A identidade baseada em nuvem é necessária porque Office 365 suporta apenas identidades baseadas em nuvem. O diagrama a seguir mostra como esse modelo funciona.
O diagrama a seguir mostra a interação do cliente com os diversos componentes durante uma experiência de navegador da web (também conhecido como um logon ou o perfil do passivo). Clientes ricos, como o Microsoft Office Outlook usam um mecanismo ligeiramente diferente (conhecido como o perfil ativo), mas a troca de tokens é o mesma.
A autenticação segue este fluxo:
1. O cliente tenta se conectar a um serviço no Office 365. O serviço vai questionar o cliente para fornecer um token para permitir o acesso ao serviço.
2. O cliente será redirecionado para o Microsoft Federation Gateway. O Microsoft Federation Gateway redirecionará o cliente para o servidor local de ADFS 2.0 para obter um token de logon como parte da etapa de descoberta de esfera doméstica. Nota: Esta etapa geralmente é ignorada para clientes ativos (por exemplo, o Microsoft Outlook) porque esses dados são reunidos em segundo plano e, assim, o cliente tentará conectar-se diretamente para o AD FS 2.0 servidor sem a etapa de redirecionamento.
3. O cliente se conecta ao servidor AF DS 2.0 e é questionado de sobre sua identidade. O cliente responderá automaticamente com suas credenciais do Active Directory localmente em cache. Nota: Computadores fora do domínio irão requerer essas credenciais.
4. O AD FS 2.0 valida as credenciais no Active Directory e reúne os dados exigidos pelo Microsoft Federation Gateway (tais como o UPN do usuário) para permitir que a conta local seja mapeada para a identidade de nuvem.
5. O Active Directory retorna os dados solicitados pelo AD FS 2.0 e confirma a identidade do usuário. O AD FS 2.0 gera um token de logon SAML 1.1 destes dados e assina com sua chave de assinatura.
6. O AD FS 2.0 retorna o token de logon SAML 1.1 assinado, que contém declarações sobre o usuário, como o UPN do usuário. Nota: O token de logon SAML 1.1 é assinado de forma que a Microsoft Federation Gateway seja capaz de verificar que o token SAML originou-se de uma autoridade confiável de um domínio federado.
7. O cliente envia o token de logon SAML1.1 para a Microsoft Federation Gateway que descriptografa o token, valida e transforma em um token de serviço assinado que é enviado ao cliente para uso no Office 365.
8. O cliente envia o token de serviço recebido da Microsoft Federation Gateway ao serviço das partes confiantes (como o Microsoft Exchange Online) no Office 365. A terceira parte confiável verifica que o token de serviço foi assinado pelo Microsoft Federation Gateway – assim, verifica que o token representa um usuário autenticado. O terceira parte serviço utiliza as declarações dentro do serviço de token para procurar o usuário de diretório do serviço e, em seguida, determina os direitos de acesso do usuário aos recursos solicitados. Logons posteriores ao Office 365 usaram um token de serviço cookie/armazenados em cache e não exigirá mais validação até que o token expire. Nota: Expiração é controlada por ambos o AD FS 2.0 server e Office 365.
Em nenhum momento durante este processo a senha do usuário no local foi enviada para qualquer sistema remoto que o administrador de TI não tenha controle total.
