OAuth e o Usuário Reidratado no SharePoint 2013 – Como eles fazem isso e o que eu preciso saber

Artigo original publicado quinta-feira, 16 de agosto de 2012

Primeiro, deixe-me dizer que uma das coisas que eu gosto sobre blogar sobre mistérios arcanos e aleatórios do SharePoint é o fato de que eu posso usar linguagem completamente coloquial, como o título do meu blog. Isso é algo quase impossível de fazer a não ser que, digamos, você esteja criando uma nova versão do SharePoint. Alguém aí viu as divertidas mensagens sociais no SharePoint 2013? “Desculpe pela demora, já estou acabando”, e coisas parecidas. Eu acho ainda mais divertido pois está intercalado com coisas como o HRESULT que meu amigo Tom recebeu outo dia. Hmm…quanto mais as coisas mudam, mais elas ficam as mesmas.

Mas vamos ao que interessa. Eu já mencionei oAuth uma ou duas vezes neste blog, ao discutir alguns dos novos recursos do SharePoint 2013. E embora eu não vá muito longe sobre "o que é oAuth", pois temos uma equipe inteira de redatores trabalhando nisso, eu quero discutir novamente ligeiramente sobre algumas das maneiras pelas quais ele é utilizado. O melhor exemplo de uma confiança oAuth é, provavelmente, para um Índice Remoto do SharePoint para pesquisa – é isso que permite que uma pessoa em um farm emita uma consulta que e direcionada a outro farm do SharePoint, e nesse farm remoto do SharePoint é capaz de reconstruir a identidade do usuário, para que os resultados da pesquisa possam passar por uma filtragem de segurança adequada. Também é usado em outros cenários como o novo modelo de aplicativo (por exemplo, este usuário possuí os direitos de acessar o conteúdo que o aplicativo está solicitando?), entre aplicativos de servidor como o SharePoint e o Exchange (este usuário possui direitos sobre o conteúdo de caixa de entrada), dentre muitos outros. O Índice Remoto do SharePoint é um bom exemplo para mim pois eu acho que, talvez, seja o melhor cenário para visualizar o porque de precisarmos fazer as coisas que fazemos em ordem para fazer com que tudo isso funcione como esperado.

Portanto, vamos começar pelo começo – como o FarmA pode “fazer um Steve” que parece um “Steve” no FarmB? Bom, tudo começa com o Aplicativo de Perfil do Usuário. Digamos que o Steve está no FarmB e emite uma consulta. Essa consulta é enviada ao FarmA, e junto à essa consulta vão alguns atributos do Steve. Por padrão, esses atributos serão o endereço SMTP, endereço SIP, nome da conta e identificador de nome do Steve. Quando o FarmA recebe essa solicitação, a primeira coisa que ele faz é fazer uma busca em seu Aplicativo de Perfil do Usuário local; ele irá procurar por um perfil que corresponda aos valores enviados para Steve. É por isso que é tão importante se assegurar que seu UPA está íntegro e populado no SharePoint 2013, e o motivo de eu ter escrito este artigo de blog sobre fazer isso: https://blogs.msdn.com/b/sharepoint_br/archive/2012/09/20/mapeando-perfis-de-usu-225-rio-para-usu-225-rios-saml-com-uma-importa-231-227-o-ad-no-sharepoint-2013.aspx.

Tudo bem, agora o FarmA encontrou o perfil de usuário Steve, o que ele pode fazer com isso? A resposta aqui é "depende", e por isso é muito importante planejar para este aspecto de sua organização. A coisa da qual isso depende é o tipo de autenticação que você está usando – aqui vai:

• Declarações do Windows – caso esteja usando declarações do Windows, então, na maioria das vezes, tudo o que você precisa está no perfil do usuário. Ele tem seu nome de conta e suas associações de grupo AD. O que eu quis dizer com "maioria das vezes” eu explicarei logo. Mas, o resumo da ópera é que, se você está usando Declarações do Windows, então está tudo bem.
• Declarações de Autorização Baseadas em Formulário – caso esteja usando FBA, então existem algumas coisas que você precisa saber. A primeira coisa é que você precisa de uma maneira de popular seu UPA e mantê-lo atualizado. Caso aconteça de você estar usando FBA com o provedor LDAP e seu diretório seja o Windows Active Directory, então você pode ficar mais despreocupado. Você pode criar uma conexão de perfil para o Active Directory e associá-la com o provedor FBA de um modo similar com o que eu descrevi na publicação cujo link eu coloquei acima. Porém, na maioria dos casos, o AD não será seu provedor, o que significa que você terá de escrever código personalizado para popular o UPA. Isso deve ser o bastante para que você obtenha o único atributo com que nós realmente devemos nos importar para usuários FBA, que é o nome da conta. Porém, como vocês todos sabem, “na maioria das vezes” (novamente, explicarei logo), o resto de seus dados vem do provedor de função. Bem, a coisa bem legal que fazemos aqui é que, ao reidratar um usuário FBA, nós também invocamos o provedor de função associado, então é como se o usuário FBA tivesse feito logon localmente. Isso nos permite obter todas as declarações de função para um usuário FBA.
• Declarações SAML – essa história se parece com a do FBA, pois a primeira coisa que você precisa fazer é popular seu UPA. Se tiver sorte, seus usuários estão no AD e você pode só importá-los diretamente seguindo as orientações contidas no link para a publicação no blog acima. Caso você não tenha sorte, então você precisará achar uma maneira de conectar a um diretório fonte e importar a partir daí. Isso é provavelmente mais complicado com declarações SAML, pois você pode ter de um a muitos diretórios e pode até mesmo não ser proprietário de todos eles (por exemplo, talvez você tenha parceiros, esteja em federação com ACS e usando Facebook ou outro provedor, etc.). Seja como for, caso queira que todo esse "negócio" funcione, então você precisa descobrir uma maneira de popular seu UPA. Porém, existe um segundo ponto mais importante aqui: ao logar como um usuário SAML, você obtém um conjunto de declarações de seu Provedor de Identidade (IdP). Esse processo de reidratação de usuário não tem como simular este logon. Isso é só a natureza do SAML, não é: você pode ser redirecionado de uma a várias vezes e fornecer um número qualquer de solicitações de autenticação e tipos de autenticação (como autenticação de dois fatores), os quais nunca poderíamos considerar. Então o que isso significa para você? Você realmente precisa adicionar suas declarações através do aumento de declarações caso queira usá-las para tornar seu conteúdo seguro e autorizar o acesso a esse conteúdo através deste processo de reidratação de usuário. Você não obterá declarações do IdP durante a reidratação, portanto, caso as queira, conceda-as localmente. Essa é a "maioria das vezes" que eu estava mencionando antes, que eu vou explicar agora.
• “Na maioria das vezes” – o que isso significa? Bem, tomara que até aqui já tenha se tornado claro - seja você um usuário Windows, FBA ou SAML, além das declarações que você obtém de seu provedor de autenticação, você também pode ter declarações adicionais adicionadas através de aumento: https://blogs.technet.com/b/speschka/archive/2010/03/13/writing-a-custom-claims-provider-for-sharepoint-2010-part-1.aspx. A outra coisa que fazemos durante o processo de reidratação é invocar todos os provedores de declarações personalizadas registrados, para que nós possamos obter quaisquer declarações adicionais para o usuário reidratado que eles teriam recebido, caso tivessem feito logon localmente e estes provedores invocados.

É por isso que eu gosto tanto do cenário do Índice Remoto do SharePoint para explicar o planejamento necessário aqui. Como você pode imaginar, dentro de um farm você pode conceder direitos a conteúdo baseado em grupos do Windows, uma função FBA, uma declaração SAML, ou qualquer declaração adicionada através de aumento. Caso você não possua estas declarações ao consultar conteúdo, então ele será filtrado por segurança e você não o verá. Para que você veja quão importante é que toda declaração que seja concedida a você seja concedidada localmente, você também obtém quando nós reidratamos uma versão de você.

Há muito planejamento em potencial para fazer isso tudo funcionar, portanto esperamos que isso tenha ajudado você a identificar as engrenagens principais para que você saiba no que focar.

Esta é uma publicação localizada. Encontre o artigo original em OAuth and the Rehydrated User in SharePoint 2013 – How’d They do That and What do I Need to Know