dez 18, 2011
Comentários desativados em Como Single Sign-On Funciona no Office 365?

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.

image

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.

image

 

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.

Fonte: http://community.office365.com/en-us/w/sso/727.aspx

Comments are closed.

Consultoria sem custos para Office 365

ReportExperts

Relatórios avançados para Office 365
Conheça mais sobre o Office 365
Office 365 e Windpws Phone
Avalie o Project Online para Office 365
Avalie o Project Lite
Avalie o Project Lite
Avalie o OneDrive for Business

Avalie

Avalie o Office 365
DNS Office 365
Cloud SMTP Relay para Office 365

o365 Advisor

Diversos links para o Office 365
Blog administrado e mantido pela CloudExperts

Google+