通过

Como usar declarações SAML no SharePoint 2010 com os sites de cabeçalho de host

  • 项目

Artigo original publicado em 19 de junho de 2011, domingo

Alguém fez uma pergunta interessante para mim outro dia, sobre se é possível usar as declarações SAML com sites de cabeçalho de host no SharePoint 2010. Meu pensamento inicial foi sim, mas queria pesquisar um pouco mais para investigar. A resposta curta para tudo isso é sim, mas não é tão simples como eu estava esperando. Para meu pequeno exemplo, criei um aplicativo Web em https://hh.vbtoys.com e dois sites de cabeçalho:  https://ash.vbtoys.com e https://josh.vbtoys.com. Embora isso não se encaixe inteiramente no modelo clássico de sites de cabeçalho de host (o que significa Urls intuitivas), lembre-se de que uma das restrições com as declarações SAML e o SharePoint é que os sites devem usar SSL. Então, em vez de ter que mexer com a criação de um certificado SSL com SAN (Nomes Alternativos de Entidade), decidi simplificar a vida para poder usar um certificado curinga. É suficiente provar se ele funciona e qual configuração é necessária, mas espero que também seja um bom lembrete sobre algo a ser considerado quando você deseja usar sites de cabeçalho de host e autenticação SAML.

Fiz um teste simples primeiro apenas para experimentar o cenário de utopia, onde você poderia fazer apenas uma alteração de configuração e fazer todos os sites de cabeçalho de host funcionarem. Nesse caso, fiz duas coisas:

  1. Criei uma nova terceira parte confiável no ADFS que usou https://hh.vbtoys.com/_trust/ como o ponto de extremidade WS Fed e um URN de urn:sharepoint:hh.
  2. Adicionei um realm de provedor ao SPTrustedIdentityTokenIssuer existente, como este:

$ap = Get-SPTrustedIdentityTokenIssuer -identity "ADFS IdP"
$uri = new-object System.Uri("https://hh.vbtoys.com")
$ap.ProviderRealms.Add($uri, "urn:sharepoint:hh")
$ap.Update()

Então, tentei acessar https://hh.vbtoys.com primeiro e estava tudo funcionando; o site abriu sem problemas. Em seguida, no teste real do cenário utópico, acessei https://ash.vbtoys.com. Infelizmente, esse não era utópico. Fui redirecionado para um SPTrustedIdentityTokenIssuer totalmente diferente; portanto, meu palpite é que o SharePoint fez uma pesquisa na lista de Realms de Provedor, não encontrou nada para https://ash.vbtoys.com e, por isso, pegou o primeiro SPTrustedIdentityTokenIssuer da minha lista.

Entretanto, nem tudo estava perdido... como você provavelmente pode imaginar neste momento, eu era capaz de fazer os meus dois sites de cabeçalho de host funcionarem, mas tive que criar:

  1. Uma nova terceira parte confiável no ADFS para cada conjunto de sites de cabeçalho de host
  2. Um novo realm de provedor para cada conjunto de sites de cabeçalho de host, e adicioná-lo ao meu SPTrustedIdentityTokenIssuer. Usei exatamente o mesmo PowerShell mostrado acima, só modifiquei a Url e o Urn de cada um. Por exemplo, foi assim que adicionei o suporte para https://ash.vbtoys.com:

$ap = Get-SPTrustedIdentityTokenIssuer -identity "ADFS IdP"
$uri = new-object System.Uri("https://ash.vbtoys.com")
$ap.ProviderRealms.Add($uri, "urn:sharepoint:ash")
$ap.Update()

A conclusão disso é que ao adicionar uma nova terceira parte confiável e um novo realm de provedor (Uri e Urn) para cada conjunto de sites de cabeçalho de host, eu fui capaz de entrar em cada site usando a autenticação SAML.

Esta é uma postagem de blog traduzida. Consulte o artigo original em Using SAML Claims in SharePoint 2010 with Host Header Sites