Share via

Finalmente, uma forma ÚTIL de federar com o Windows Live e SharePoint 2010 usando o OAuth e SAML

  • Article

Artigo original publicado na terça-feira, 01 de março de 2012

Muitas pessoas falaram comigo no passado sobre a federação do SharePoint com o Windows Live. Na superfície, parece uma ótima ideia – o Windows Live tem milhões de usuários, todos se conectam com seus endereços de email, que é algo que usamos muito como uma declaração de identidade e temos várias instruções sobre como fazê-lo – tudo diretamente ou através do ACS (Serviço de Controle de Acesso). Portanto, por que eu estou tão irritando sobre o uso com o SharePoint? Bem, aqueles que tentaram antes sabem – ao realizar a federação com seu Windows Live você nunca obtém de volta um endereço de email de usuário como uma declaração. Tudo que você obtém é um identificador do Windows Live especial chamado PUID. Até onde eu sei, o “PUID” deve significar “Praticamente GUID”, porque é muito parecido e com utilidade similar. 

Por exemplo, se você federar com o Windows Live, você você adiciona alguém a um site? Você precisa obter o PUID e adicioná-lo a um grupo do SharePoint ou nível de permissão. Você realmente conhece alguém que sabe o que é PUID (se você é tal pessoa, é hora de procurar outra coisa para fazer em seu tempo livre). Mesmo se você magicamente souber qual é seu PUID, quão útil você acha que será se estiver tentando conceder direitos de usuário para diferentes conjuntos de sites? Você realmente acha que alguém mais poderia escolher você de um lista organizada de PUID (ou people picker, como pode ser o caso)? Claro que não! E por isso minha frustração cresce.

Eu realmente pensei que poderíamos ter uma chance com uma solução mais utópica do que o ACS. O ACS é realmente ótimo em termos de oferecer suportes para vários provedores de identidade como o Windows Live, Google, Yahoo e Facebook. Com o Facebook eles ainda fazem um pouco de mágica e realmente usam o OAuth para autenticar e devolver um conjunto de declarações SAML. Muito legal! Então, por que eles não fazem isso também com o Windows Live? O Windows Live suporta OAuth agora para que pareça que tenha uma oportunidade de algo de valor finalmente acontecer. Bem, apesar de desejar isso, os amigos do ACS não vem nos resgatar aqui. E é aqui que está o ponto desta consideração – Eu finalmente decidi escrever um e esse é o objetivo desta publicação.

Por que nos preocupamos com o OAuth? Bem, ao contrário do PUID que você obtém quando federar diretamente com o Windows Live, o suporte do OAuth no Windows Live permite você obter MUITO mais informações sobre o usuário, incluindo - espere - seu endereço de email. Então, o plano de ataque aqui é basicamente esse:

  1. Escreva um Provedor de Identidade usando o Windows Identity Foundation (WIF).
  2. Quando uma pessoa é redirecionada para nosso STS, se eles ainda não foram autenticados, redirecionamentos eles novamente para o Windows Live. Você precisa criar “um aplicativo” com o Windows Live para fazer isso, mas explicaremos mais sobre isso posteriormente.
  3. Quando eles forem autenticados, eles são retornados para o STS personalizado. Quando eles são retornados, a cadeia de caracteres de consulta inclui um token de login; este token de login pode ser trocado por um token de acesso.
  4. O STS faz outra solicitação para o Windows Live com o código de login e solicita um token de acesso.
  5. Quando recebe de volta o token de acesso, faz uma solicitação final para o Windows Live com o token de acesso e solicita algumas informações básicas sobre o usuário (eu irei explicar o que obteremos de volta posteriormente).
  6. Quando você tiver a devolução da informação do usuário do Windows Live, nós usamos nosso STS personalizado para criar um conjunto de declarações SAML para o usuário e preencher com a informação do usuário. Nós redirecionamentos de volta para o aplicativo que nos solicitou a autenticação para começar para permitir que fazer o que desejamos com os tokens SAML. Neste caso particular, eu testei meu STS com um aplicativo ASP.NET padrão, assim como um aplicativo Web do SharePoint 2010.

Portanto…todo o código fonte é anexado nesta publicação, mas ainda há alguma configuração para ser realizada e você terá que recompilar o aplicativo com a ID do aplicativo e senha obtidos pelo Windows Live, mas ao invés de fazer uma cópia e colar, não há nada que você precise escrever para continuar. Agora, vamos falar sobre tudo que você precisa para usá-lo.

Criar um Certificado de Autenticação de Tokens

Você precisará criar um certificado que será usado para conectar seus tokens SAML. Não há nada especial sobre o certificado que você usa para autenticar certificados, além de que você precisa garantir que possui uma chave privada para ele. No meu caso, eu tenho o Serviço de Certificado instalado no meu domínio, portanto, eu apenas abri o Gerenciador IIS e selecionei a opção para criar um Certificado de Domínio. Eu segui o assistente e antes de perceber tinha um novo certificado completo com chave privada. Para este projeto, eu criei um certificado chamado livevbtoys. 

Como eu explicarei na próxima seção, quando as solicitações começam a chegar no STS, o usuário é um usuário anônimo. Para usar este certificado para autenticar tokens SAML, precisamos conceder acesso a chave privada aos processos IIS para aquele certificado. Quando uma solicitação anônima chega no processo IIS, a identidade é Serviço de Rede. Para fornecer direitos para a chave, você precisa:

  1. Iniciar o MMC
  2. Adicionar os Certificados snap-in. Selecione o repositório do computador para o computador local.
  3. Abra o repositório de certificados Pessoal…e encontre o certificado que você criou para assinar tokens SAML. Se você criou como explicado acima, o certificado estará neste local por padrão. Se você criar de outra forma, você precisa adicioná-lo neste repositório.
  4. Clique com o botão direito no certificado e escolha a opção Gerenciar chaves privadas.
  5. Na lista de usuários que possuem direitos das chaves, adicione um Serviço de Rede e oferece direitos de leitura a ele.

Observe que se você não fizer isso corretamente, ao tentar executar o aplicativo, você pode obter um erro que diz “keyset não existe”. Isso apenas significa que o processo IIS não teve direitos suficientes para a chave privada, portanto, ele não pode usá-la para autenticar o token SAML.

Instale o aplicativo e assemblies exigidos

Instalar o aplicativo neste sentido apenas significa criar um aplicativo ASP.NET no IIS, copiando os bits e garantindo que a versão mais atuais do WIF seja instalada. Quando ele for configurado e estiver funcionando no servidor do curso, você pode desejar adicionar um ou mais servidores adicionais para garantir que você possui uma solução tolerante a falhas. Mas, irei apenas verificar a configuração necessária no servidor único.

Eu não falarei sobre como criar um aplicativo ASP.NET no IIS. É possível fazer com o Visual Studio, no Gerenciador IIS, etc. 

NOTA: Se você usa o código oferecido e apenas abre o projeto no Visual Studio, irá avisar sobre o host ou site não existente. Isto ocorre porque está usando o nome do meu servidor. A forma mais fácil de corrigir isso é apenas editar manualmente o arquivo WindowsLiveOauthSts.sln e alterar os valores https para aqueles que realmente existem em seu ambiente.

Quando for realmente criado, existem algumas coisas que você deve ter certeza que vai realizar.

  1. Adicionar o PassiveSTS.aspx como o documento padrão no Gerenciador IIS para o website do STS.
  2. Alterar as configurações de autenticação para o aplicativo no IIS, para que todos os tipos de autenticação seja desabilitados, exceto para a Autenticação Anônima.
  3. O STS precisa passar pelo SSL, para que você precise obter um certificado adequado para ele e garantir que você atualize as ligações no servidor virtual IIS onde o aplicativo STS personalizado é usado.
  4. Certifique-se de colocar a impressão digital para seu certificado de autenticação de token no atributo de impressão digital do elemento adicionar na seção trustedIssuers do web.config da sua parte confiável (se você NÃO está usando o SharePoint para testar). Se você usar o assistente Adicionar Referência STS no Visual Studio, ele fará isso para você.

Essa deverá ser toda a configuração necessária no IIS.

Atualizar e compilar o Projeto STS personalizado

O arquivo zip anexado inclui um projeto do Visual Studio 2010 chamado WindowsLiveOauthSts. Quando o IIS é configurado e você tiver atualizado o arquivo WindowsLiveOauthSts.sln como descrito acima, você deverá poder abrir o projeto com sucesso no Visual Studio. Uma das primeiras coisas que você precisará fazer é atualizar as constantes CLIENT_ID e CLIENT_SECRET na classe PassiveSTS.aspx.cs. Você pode obter eles ao criar um novo aplicativo do Windows Live. Embora eu não irei cobrir este passo a passo (porque existem amigos no Windows Live que podem ajudar você com isso), deixe-me apenas apontar o local onde você pode ir para criar seu aplicativo do Windows Live:  https://manage.dev.live.com/Applications/Index?wa=wsignin1.0. Além disso, quando você cria seu aplicativo, você deve garantir a configuração de Redirecionar Domínio para o local onde seu STS personalizado é hospedado, isto é, https://myserver.foo.com.

Agora que você possui seu ID e a senha, aqui está o que precisa ser atualizado no aplicativo:

  1. Atualize as constantes CLIENT_ID e CLIENT_SECRET na classe PassiveSTS.aspx.cs.
  2. No arquivo web.config, atualize o SigningCertificateName na seção appSettings. Observe que você não precisa mudar a configuração do IssuerName, mas obviamente você pode se desejar.
  3. Atualize o certificado de autenticação de token para o documento FederationMetadata.xml no projeto STS. Quando você tiver selecionado o certificado que irá usar, é possível utilizar o aplicativo test.exe incluído nesta publicação para obter o valor da cadeia de caracteres para o certificado. Precisa ser copiado para substituir os dois valores de elemento X509Certificate no federationmetadata.xml.

Há outra coisa que vale a pena falar aqui – no arquivo CustomSecurityTokenService.cs você terá a opção de configurar uma variável chamada enableAppliesToValidation para verdadeiro e oferecer uma lista de Urls que pode usar este STS personalizado. No meu caso, eu escolhi não restringir de qualquer forma, portanto a variável é falsa. Se você deseja bloquear seu STS personalizado, você deve mudar agora. Quando todas estas mudanças forem realizadas, é possível recompilar o aplicativo e está pronto.

Outra observação aqui – eu também inclui um aplicativo ASP.NET de amostra que é usado para teste enquanto estava compilando isso. Está em um projeto chamado LiveRP. Eu não irei falar sobre ele aqui; é suficiente dizer que está lá se você deseja testar as coisas. Apenas lembre-se de mudar a impressão digital para o certificado de autenticação de token STS, como descrito acima.

Configuração do SharePoint

Neste ponto, tudo está configurado e deve estar funcionando para o STS personalizado. A única coisa que falta fazer é criar um novo emissor SPTrustedIdentityToken no SharePoint e configurar um aplicativo Web novo ou existente para usá-lo. Existem algumas coisas que você deve saber sobre a configuração do SPTrustedIdentityTokenIssuer; Eu irei fornecer o PowerShell que usei para criar o meu e explicarei:

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

New-SPTrustedRootAuthority -Name "SPS Live Token Signing Certificate" -Certificate $cert

 

$map = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

$map2 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/id" -IncomingClaimTypeDisplayName "WindowsLiveID" -SameAsIncoming

$map3 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/full_name" -IncomingClaimTypeDisplayName "FullName" -SameAsIncoming

$map4 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/first_name" -IncomingClaimTypeDisplayName "FirstName" -SameAsIncoming

$map5 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/last_name" -IncomingClaimTypeDisplayName "LastName" -SameAsIncoming

$map6 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/link" -IncomingClaimTypeDisplayName "Link" -SameAsIncoming

$map7 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/gender" -IncomingClaimTypeDisplayName "Gender" -SameAsIncoming

$map8 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/locale" -IncomingClaimTypeDisplayName "Locale" -SameAsIncoming

$map9 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/updated_time" -IncomingClaimTypeDisplayName "WindowsLiveLastUpdatedTime" -SameAsIncoming

$map10 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/account" -IncomingClaimTypeDisplayName "AccountName" -SameAsIncoming

$map11 = New-SPClaimTypeMapping -IncomingClaimType "https://blogs.technet.com/b/speschka/claims/accesstoken" -IncomingClaimTypeDisplayName "WindowsLiveAccessToken" -SameAsIncoming

$realm = "https://spslive.vbtoys.com/_trust/"

$ap = New-SPTrustedIdentityTokenIssuer -Name "SpsLive" -Description "Window Live oAuth Identity Provider for SAML" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2,$map3,$map4,$map5,$map6,$map7,$map8,$map9,$map10,$map11 -SignInUrl "https://spr200.vbtoys.com/WindowsLiveOauthSts/PassiveSTS.aspx" -IdentifierClaim "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

Há algumas coisas que devem ser observadas:

  1. Como eu declarei acima, criei um certificado chamado livevbtoys.cer para assinar meus tokens, portanto, eu adicionei eles à minha lista SPTrustedRootAuthority e associei com meu emissor de token.
  2. Eu criei mapeamentos de declarações para todas as declarações que meu STS personalizado está retornando. Como você pode ver, é SIGNIFICANTEMENTE MELHOR do que você iria obter se apenas fosse federado diretamente para o Windows Live. Uma coisa a ser observada aqui – eu inclui o token de acesso obtido do Windows Live como uma declaração. Embora isso funcione com o Facebook, eu não testei para que possa ser dito que o Windows Live permitirá você reutilizá-lo ou não. Mas, talvez esse será o tópico de uma publicação futura.
  3. O valor $realm é extremamente importante. Deve apontar para o site raiz do seu aplicativo Web e incluir o diretório /_trust/. Se você fizer isso errado, obterá apenas 500 erros do SharePoint quando você ser redirecionado de volta após a autenticação.
  4. O parâmetro –SignInUrl ao criar o emissor de token é a Url absoluta para a página PassiveSTS.aspx do meu STS personalizado.

É basicamente isso – quando estiver configurado, você ainda estará usando o people picker externo e os provedores de declaração para que não tenha qualquer capacidade de pesquisa, conforme esperado. Você concede direitos à pessoas com endereços de email que usam para conectar-se no Windows Live. Você pode realmente aumentar este exemplo e usar o provedor de declarações Azure que informei aqui:  https://blogs.msdn.com/b/sharepoint_br/archive/2012/03/07/the-azure-custom-claim-provider-for-sharepoint-project-part-1.aspx. isto significa que você estaria usando este STS para habilitar sua autenticação com o Windows Live e obter algumas declarações SAML reais de volta e usar o projeto do provedor de declarações personalizadas Azure para adicionar aqueles usuários autenticados no seu repositório de diretório Azure e o people picker para escolher.

As imagens irão dizer tudo, portanto, aqui está o visual quando você clica pela primeira vez no site do SharePoint e autentica com o Windows Live:

Ao conectar-se pela primeira vez, irá solicitar se é possível compartilhar informações com o aplicativo STS personalizado. Não há nada para se preocupar aqui – estas são as permissões OAuth padrões ocorrendo. Aqui está o visual; observe que mostra os dados que estou solicitando no STS – você poderia solicitar por um conjunto de dados totalmente diferentes, se desejar. É necessário apenas procurar no SDK OAuth do Window Live para descobrir o que você precisa para mudar e como:

Quando você aceitar, será redirecionado de volta ao site do SharePoint. Neste exemplo, eu estou tentando usar o web part Declarações do SharePoint que falei aqui:  https://blogs.technet.com/b/speschka/archive/2010/02/13/figuring-out-what-claims-you-have-in-sharepoint-2010.aspx. Você pode ver todas as declarações obtidas do Windows Live através do OAuth que possui agora como declarações SAML graças ao meu STS personalizado, assim como o fato que eu autentiquei meu endereço de email do Windows Live criado para este projeto (pelo controle de autenticação, canto superior direito):

 

Esta é uma publicação localizada. Encontre o artigo original em Finally A USEFUL Way to Federate With Windows Live and SharePoint 2010 Using OAuth and SAML