Autenticação SAML federada com SharePoint 2010 e Azure Access Control Service - Parte 1

Article
06/27/2011

Artigo original publicado em 6 de maio de 2011, sexta-feira

OBSERVAÇÃO: como de costume, a formatação deste site é muito ruim. Eu recomendo você baixar o anexo de documento do Word com esta postagem para fazer uma melhor leitura.

Eu tenho observado o Windows Azure Access Control Service (ACS) com uma visão interessante recentemente, pensando sobre algumas das diferentes opções de integração. Há sempre muita conversa sobre a autenticação de declarações com o SharePoint 2010, e como integrar o ADFS, Windows Live, Facebook, etc. O ACS (também conhecido como AppFabric ACS pelos puristas e pessoal de Marketing do Azure) é bem legal porque inclui "conectores" para estes provedores de identidade comum prontos para uso. Quando você configura um namespace do ACS (pense nisso como uma conta com conectores e configurações), simplifica a conectividade com o ADFS 2.0, Windows Live, Yahoo, Google e Facebook. O programador preguiçoso em mim pensa "Ei!", deve haver algo acontecendo lá, então eu decidi olhar para isso de alguns ângulos diferentes. Vou descrever o primeiro nesta postagem.

Para este cenário, eu realmente só queria estabelecer uma relação de confiança diretamente entre o SharePoint 2010 e o ACS. Eu queria ser capaz de usar o ADFS e contas do Windows Live, Yahoo e Google para autenticar e entrar no meu site do SharePoint. Eu não incluí o Facebook porque a computação social não é realmente minha área (este blog é o mais perto que posso chegar), portanto, eu não tenho uma conta no Facebook ou Twitter, porque realmente não estou interessado no compartilhamento frequente de informações inúteis com o mundo em geral (“Puffy acabou de ter três gatinhos adoráveis!! ”). Eu NÃO vou explicar como conseguir uma conta do Windows Azure, criar um namespace do Access Service Control, gerenciar o ACS, etc. - deve haver resmas de informações lá fora, do pessoal do Windows Azure, então eu não vou tentar e reinventar isso.

O que eu vou descrever é o processo de definição de várias relações de confiança, certificados e configurações necessários para obter tudo isso funcionando em conjunto. No final, vou incluir alguns instantâneos da minha conexão com as identidades de cada um desses provedores. Estas são as etapas para se conectar:

Abrir a página de Gerenciamento de Controle de Acesso (Access Control Management)
1. Faça logon no portal de gerenciamento do Windows Azure. Clique no menu Barramento de Serviço (Service Bus), Controle de Acesso (Access Control) e Cache (Caching) no painel esquerdo. Clique em Controle de Acesso (Access Control) na parte superior do painel esquerdo (abaixo de AppFabric), clique no namespace no painel direito, e clique no botão Serviço de Acesso de Controle (Access Control Service) na parte de gerenciamento da faixa de opções. Isso abrirá a página de Gerenciamento de Controle de Acesso (Access Control Management).
Adicionar um provedor de identidade para o ADFS
1. Clique nos provedores de identidade (Identity providers) no menu Relações de confiança (Trust relationships) no painel esquerdo.
2. Clique no link Adicionar (Add)
3. O botão de opção do provedor de identidade do WS-Federation deve estar selecionado por padrão; verifique se não está. Isso que é usado para o ADFS 2.0. Clique no botão Avançar (Next).
4. Preencha a seção Configurações do Provedor de Identidade (Identity Provider Settings)
  1. Preencha o Nome para exibição (Display name), como “Meu Servidor do ADFS”
  2. Para os metadados do WS-Federation, se o seu servidor do ADFS estiver exposto via Internet, coloque a Url no ponto de extremidade dos metadados de federação. Por padrão, é em https://SeuServidorAdfs.com/FederationMetadata/2007-06/FederationMetadata.xml. Se o seu servidor do ADFS não estiver exposto na Internet, abra a Url no ponto de extremidade no navegador local. Vá para o navegador e salve a página no sistema de arquivos local como um arquivo .XML. Em seguida, nas Configurações do Provedor de Identidade (Identity Provider Settings) do ACS, clique no botão de opção ao lado da caixa de edição Arquivo (File) e use o botão Procurar (Browse) para encontrar o arquivo xml dos metadados de federação que acabou de salvar.

Isso é tudo que você precisa fazer para criar seu Provedor de Identidade no ACS.

3. Adicionar uma terceira parte confiável para o SharePoint

1. Agora você precisa adicionar o SharePoint como uma terceira parte confiável do ACS, assim como faz quando configura o SharePoint e o ADFS juntos. Comece clicando no link dos aplicativos da terceira parte confiável no menu Relações de confiança (Trust relationships) no painel esquerdo
2. Clique no link Adicionar (Add)
3. Preencha a seção Configurações de Aplicativo de Terceira Parte Confiável (Relying Party Application Settings)
  1. Digite um nome para exibição, como “SharePoint 2010”
  2. Use o modo de inserir configurações padrão manualmente
  3. Na caixa de edição Realm, insira um realm e salve-o porque você vai usá-lo novamente quando criar o SPTrustedIdentityTokenIssuer no SharePoint. Para os fins deste exemplo, vamos dizer que o realm é "urn:sharepoint:acs".
  4. Para a Url de retorno, use o mesmo formato que usa quando configura o SharePoint como uma terceira parte confiável no ADFS: https://NomeDoSite/_trust/.
  5. O menu suspenso de formato do Token deve ser SAML 1.1
  6. Você pode definir o tempo de vida do Token (segundos) para quanto desejar. Ele é 10 minutos por padrão; eu defini o meu como 3600 que significa 1 hora.
4. Preencha a seção Configurações de Autenticação (Authentication Settings)
  1. Marque todas as caixas nos provedores de identidade, que devem mostrar o provedor de identidade do ADFS que você criou na etapa anterior
  2. Nos grupos Regra (Rule), deixe o padrão marcado, que é Criar novo grupo de regras (Create new rule group).
5. Nas Configurações de Autenticação de Tokens (Token Signing Settings), você pode deixar a opção padrão selecionada, que é Usar certificado de namespace de serviço (padrão) [Use service namespace certificate (standard)].
6. Clique no botão Salvar (Save) para salvar suas alterações e criar a terceira parte confiável

4. Criar as regras para a terceira parte confiável

1. Eu estou supondo aqui que você ainda não criou um conjunto de regras no ACS, então estamos criando um novo grupo deles. Se você tivesse um grupo que desejasse reutilizar, na etapa anterior, você teria que colocar uma marca ao lado dos grupos que desejasse usar com a terceira parte confiável em vez de usar o padrão de Criar novo grupo de regras (Create new rule group). Mas já que estamos criando um novo grupo, clique no link Grupos de regras (Rule groups) no menu Relações de confiança (Trust relationships) no painel esquerdo
2. Você deverá ver um grupo de regras que tem um nome como "Grupo de regras padrão para qualquer que fosse o nome da terceira parte confiável" (Default Rule Group for whatever your relying party name was). Clique no link desse nome de grupo de regras
3. Realmente a melhor coisa a fazer neste momento é clicar no link Gerar (Generate). Ele irá criar automaticamente um conjunto de regras que, basicamente, enumera todas as declarações que você receberá de cada provedor de identidade, e cria uma regra para cada um que passa por esse valor de declaração com o mesmo tipo de declaração na terceira parte confiável
4. Na página Gerar Regras (Generate Rules), marque a caixa ao lado de cada provedor de identidade e clique no botão Gerar (Generate). Isso cria as regras como eu descrevi anteriormente. Quando terminar, você será redirecionado para a página Editar Grupo de Regras (Edit Rule Group), onde verá todas as regras listadas. Em muitos casos isso seria o suficiente, mas temos aqui uma anomalia que precisamos dar conta. No SharePoint, vamos utilizar o endereço de email como a declaração de identidade. Ironicamente, todos os provedores de identidade enviam o endereço de email junto (e têm regras criadas para eles fazerem isso) exceto para o Windows Live. Então, por enquanto, para este exemplo, eu estou simulando uma parte do Windows Live. O que eu quero dizer com isso é que eu vou pegar uma declaração que ele fornece – nomedoidentificador – e vou criar uma regra que passe isso de volta, mas como uma declaração de email. Este não é o momento de odiar o Steve, é apenas uma maneira de obter esse ambiente de demonstração em execução com o menor número de partes móveis (e já existem várias). Agora vamos adicionar esta regra final
5. Clique no link Adicionar (Add)
6. No menu suspenso Provedor de Identificação (Identity Provider), selecione Windows Live I
7. Na seção Tipo de declaração de entrada (Input claim type), clique no botão de opção ao lado de Selecionar tipo (Select type:). Há somente um tipo de declaração para o qual o Windows Live ID oferece suporte, portanto, ele já está selecionado (nomedoidentificador)
8. Role a seção Tipo de declaração de saída (Output claim type) para baixo e clique no botão de opção ao lado de Selecionar tipo (Select type:)
9. Na lista suspensa, localize https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress e selecione-o
10. Digite uma descrição se desejar e clique no botão Salvar (Save) para salvar suas alterações e criar a regra
11. Você será redirecionado para a página Editar Grupo de Regras (Edit Rule Group). Clique no botão Salvar (Save) para salvar todas as suas alterações. Agora você terminou a configuração do ACS, mas não feche o navegador ainda porque você precisará obter algumas informações adicionais de lá quando criar e configurar outros componentes.

5. Criar uma terceira parte confiável para o ACS no ADFS

1. Como o ADFS é um provedor de identidade no ACS, o ACS é uma terceira parte confiável no ADFS. Isso significa que precisamos configurar uma terceira parte confiável no ADFS para que, quando o ACS redireciona uma solicitação de autenticação para o ADFS, seja estabelecida uma relação de confiança que permite que o ADFS responda. Comece indo para o servidor do ADFS e abrindo o Console de Gerenciamento do AD FS 2.0 (AD FS 2.0 Management console)
2. Vá para o nó AD FS 2.0…Relações de Confiança (Trust Relationships)…Terceira Parte Confiável (Relying Party Trusts) e clique no link Adicionar Terceira Parte Confiável (Add Relying Party Trust…) no painel direito
3. Clique no botão Iniciar (Start) para iniciar o assistente
4. Use a opção padrão para importar dados sobre a terceira parte confiável publicados online. A Url que você precisa usar está no portal de gerenciamento do ACS. Volte ao seu navegador que tem o portal aberto, e clique no link Integração de Aplicativos (Application Integration) no menu Relações de confiança (Trust relationships) no painel esquerdo
5. Copie a Url que ele mostra para os metadados do WS-Federation, e cole-a no endereço dos metadados de federação (nome do host ou URL): a caixa de edição no assistente do ADFS e, em seguida, clique no botão Avançar (Next)
6. Digite um nome para exibição e, opcionalmente, algumas observações, e clique no botão Avançar (Next)
7. Deixe a opção padrão de permitir que todos os usuários acessem a terceira parte confiável (permitting all users to access the relying party) e clique no botão Avançar (Next)
8. Clique no botão Avançar (Next) para criar a terceira parte confiável
9. Após a criação da terceira parte confiável, abra o Editor de Regras (Rules Editor) no ADFS para criar novas regras a fim de transmitir valores de declarações para o ACS
10. Com a guia Regras de Transmissão de Emissão (Issuance Transform Rules) selecionada, clique no botão Adicionar Regra... (Add Rule…)
11. Deixe o modelo padrão de Enviar Atributos LDAP como Declarações (Send LDAP Attributes as Claims) selecionado e clique no Avançar (Next).
12. Preencha o restante dos detalhes da regra:
  1. Digite um nome de regra de declaração
  2. No menu suspenso Repositório de atributos: (Attribute store:), selecione Active Directory
  3. Na seção Mapeamento de atributos LDAP (Mapping of LDAP attributes), mapeie
    1. Endereços de email do atributo LDAP a Endereço de email de Tipo de Declaração de Saída
    2. Grupo de tokens do atributo LDAP – Nomes não qualificados para função de Tipo de Declaração de Saída
  4. Clique no botão Concluir (Finish) para salvar sua regra. A configuração do ADFS está concluída.

6. Configurar a relação de confiança do SharePoint com o ACS

1. Este é um processo de várias etapas que começa com a obtenção do certificado de autenticação de tokens do ACS. Felizmente, o certificado está incluído no arquivo FederationMetadata.xml, por isso vamos recuperá-lo de lá e salvá-lo localmente no servidor do SharePoint. No SharePoint Server, abra o navegador e abra a página Gerenciamento de Controle de Acesso (Access Control Management), como descrito acima
2. Clique no link Integração de Aplicativos (Application Integration) no menu Relações de confiança (Trust relationships) no painel esquerdo, copie a URL mostrada para os metadados do WS-Federation e cole-a no navegador. O arquivo FederationMetadata.xml do ACS será exibido no navegador.
3. Encontre a seção parecida com esta (ela é sobre a segunda seção principal abaixo da parte superior da página):

<X509Certificate>MIIDEDCCAfiblahblahblah</X509Certificate>

</X509Data>

Copie os dados do elemento X509Certificate e cole-os no bloco de notas. Salve-o com uma extensão de arquivo .CER (a codificação deve ser ANSI); para os fins desta postagem, vamos supor que você chama o arquivo C:\AcsTokenSigning.cer. Este é o certificado de autenticação de tokens do ACS.

1. Adicione o certificado de autenticação de tokens do ACS à lista de autoridades confiáveis no SharePoint. Você pode fazer isso, como descrito em https://blogs.technet.com/b/speschka/archive/2010/07/07/managing-trusted-root-authorities-for-claims-authentication-in-sharepoint-2010-central-admin.aspx ou pode adicioná-lo com o PowerShell assim:

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\AcsTokenSigning.cer")

New-SPTrustedRootAuthority -Name "ACS Token Signing" -Certificate $cert

1. A próxima etapa é criar o novo SPTrustedIdentityTokenIssuer. Eu tenho descrito isso em vários locais; você pode usar https://blogs.technet.com/b/speschka/archive/2010/07/30/configuring-sharepoint-2010-and-adfs-v2-end-to-end.aspx como um ponto inicial (basta rolar para baixo para as informações que vêm APÓS a configuração do ADFS). Lembre-se do seguinte:
  1. Tanto nome quanto nomedoidentificador são tipos de declaração reservados no SharePoint, por isso, mesmo que nomedoidentificador seja a única declaração comum nos provedores de identidade padrão do ACS, não é uma opção para a sua declaração de identidade. Em vez disso, eu recomendo, por enquanto, apenas reduzir os endereços de email e adicionar as regras apropriadas no ACS conforme descrito acima
  2. O parâmetro SignInUrl de New-SPTrustedIdentityTokenIssuer deve apontar para a sua instância do ACS. Por exemplo, https://myAcsNamespace.accesscontrol.windows.net:443/v2/wsfederation. Você pode encontrar isso olhando para a terceira parte confiável que configurou no ADFS para o ACS. Abra a caixa de diálogo de propriedades Terceira Parte Confiável (Relying Party), clique na guia Pontos de Extremidade (Endpoints) e use a Url exibida para o Ponto de Extremidade Passivo do WS-Federation para a associação POST (deve haver somente um lá).
2. A última etapa é apenas criar seu aplicativo Web, configure-o para usar autenticação de declarações e o SPTrustedIdentityTokenIssuer que você criou para o ACS. Finalmente, crie um conjunto de sites no aplicativo Web e comece a testar.

Neste momento, você deve estar pronto para acessar o site e experimentá-lo. Lembre-se de que será necessário configurar o administrador do conjunto de sites para ser um dos endereços de email que um dos provedores de identidade retornará para que você possa fazer logon no site. Uma vez lá dentro, você poderá adicionar endereços de email ou declarações de função de provedores em grupos do SharePoint, assim como faria normalmente.

A única ressalva para lembrar mais uma vez, por enquanto, é o Windows Live ID. Como afirmado anteriormente nesta postagem, você realmente não terá um endereço de email válido para o Windows Live, portanto, será necessário adicionar o que chamam de PUID ao seu grupo do SharePoint. Para fins de teste, a maneira mais fácil de conseguir isso é fazer logon usando o Windows Live ID, e então você acessará a página no SharePoint que diz que você está conectado como "foo" e o acesso será negado. A partir daí, você poderá copiar o PUID, fazer logon como um usuário administrador, adicionar o PUID a um grupo do SharePoint e deve estar no caminho certo. Eu nem sequer olhei para o tipo de opções de diretório, se houver, que estão disponíveis para o Windows Live ID (estou supondo que provavelmente não há nenhuma). Mas isso é um começo para que possamos passar por esta prova de conceito juntos. Agora que fizemos isso, aqui está a provável aparência de logon no meu site usando cada um desses provedores de identidade:

Página de Logon

ADFS

Google

Yahoo

Windows Live ID

Esta é uma postagem de blog traduzida. Consulte o artigo original em Federated SAML Authentication with SharePoint 2010 and Azure Access Control Service Part 1

Share via

Autenticação SAML federada com SharePoint 2010 e Azure Access Control Service - Parte 1

Additional resources