Três sistemas de autorização para Suplementos do SharePoint

  • Artigo

No SharePoint, um Suplemento do SharePoint é uma entidade de identidade como um usuário e deve ser autenticada e autorizada a usar recursos do SharePoint. Há três sistemas de autorização que um suplemento pode usar. Eles não são mutuamente exclusivos.

Noções sobre os três sistemas de autorização e quando usá-los

Baixa confiança

Um Suplemento do SharePoint hospedado pelo provedor pode se registrar com o Serviço de Controle de Acesso do Microsoft Azure (ACS), que emite um token de acesso para o suplemento que permite que o suplemento acesse os recursos no locatário ou farm do SharePoint no qual o suplemento está instalado. O Azure ACS é o emissor de token confiável em um "fluxo" da Estrutura OAuth 2.0 que inclui o SharePoint e os componentes remotos do suplemento. Os suplementos que usam esse sistema podem ser vendidos na Office Store. O sistema de baixa confiança destina-se principalmente a suplementos cujos componentes remotos estão hospedados na nuvem.

Importante

O Controle de Acesso do Azure (ACS), um serviço do Azure Active Directory (Azure AD) será desativado em 7 de novembro de 2018. Essa desativação não afeta o modele do Suplemento do SharePoint que usa o nome de host https://accounts.accesscontrol.windows.net (que não é afetado por ela). Para saber mais, confira Impacto da desativação do Controle de Acesso do Azure para Suplementos do SharePoint.

Para obter mais informações sobre como criar um Suplemento do SharePoint que usa o sistema de baixa confiança, consulte Criando suplementos do SharePoint que usam autorização de baixa confiança.

Observação

O cliente que instala o suplemento deve ter uma conta do Office 365. Isso é necessário para dar ao suplemento acesso ao Azure ACS. No entanto, o cliente não precisa usar a conta para nenhuma outra finalidade, e o suplemento pode ser instalado em um farm do SharePoint local após algumas tarefas de configuração simples no farm.

Alta confiança

Um suplemento hospedado pelo provedor, utilizando certificados digitais, pode estabelecer a confiança entre os componentes remotos locais que acessam o SharePoint. O sistema de alta confiança destina-se principalmente a suplementos cujos componentes remotos são hospedados localmente. O suplemento pode ser instalado em um farm do SharePoint que não está conectado à Internet. O suplemento não pode ser instalado no SharePoint Online ou vendido na Office Store.

Para saber mais sobre a criação de um Suplemento do SharePoint que use o sistema de alta confiança, veja o nó Criar suplementos do SharePoint que usem autorização de alta confiança.

Biblioteca entre domínios

Quando a lógica de negócios do suplemento está em JavaScript, você tem a opção de usar a biblioteca entre domínios do SharePoint no lugar ou como um suplemento para os sistemas de baixa confiança e alta confiança. A biblioteca também se destina a cenários em que o suplemento tem componentes hospedado na nuvem, mas o firewall corporativo do cliente dificulta o uso de sistema de baixa confiabilidade. O navegador do usuário bloqueia scripts de outros domínios, mas a biblioteca encapsula um sistema seguro para contornar essa restrição. Os suplementos que usam a biblioteca podem ser vendidos na Office Store e podem ser instalados no SharePoint Online ou no SharePoint local.

Para obter mais informações sobre como criar um Suplemento do SharePoint que usa a biblioteca entre domínios, consulte:

Informações gerais sobre a estrutura do OAuth 2.0 e sua implementação pelo SharePoint

Dois dos três sistemas de autorização usam a Estrutura OAuth 2.0. OAuth 2.0 é uma estrutura aberta para autorização. O OAuth habilita a autorização segura de aplicativos web, de desktop e de dispositivo de maneira padrão. O OAuth permite que um usuário aprove um aplicativo para agir em seu nome sem compartilhar seu nome de usuário e senha.

Por exemplo, ele permite que um usuário compartilhe seus recursos particulares ou dados (lista de contatos, documentos, fotos, vídeos e assim por diante) em um site com outro site, sem exigir que o usuário forneça suas credenciais (normalmente nome de usuário e senha) para o outro site.

O OAuth permite que os usuários forneçam tokens de acesso aos dados hospedados por um determinado provedor de serviços (como o SharePoint). Cada token concede acesso a um provedor de recursos específico (como um site do SharePoint), para recursos específicos (por exemplo, documentos em uma biblioteca de documentos do SharePoint) e por uma duração definida (por exemplo, 12 horas). Isso permite que um usuário conceda a um aplicativo web ou da área de trabalho de terceiros acesso a informações armazenadas com outro recurso ou provedor de serviços (como o SharePoint) e faça isso sem compartilhar seu nome de usuário e senha e sem compartilhar todos os dados que ele tem com o provedor.

O SharePoint usa a estrutura dotokenOAuth 2.0 passando "fluxos" para:

  • Autorizar solicitações de um Suplemento do SharePoint para acessar recursos do SharePoint.

  • Autenticar suplementos na Office Store, um catálogo de suplementos, ou um locatário do desenvolvedor.

Para obter mais informações e saber mais sobre OAuth e a terminologia OAuth, consulte OAuth.net e Protocolo de Autorização da Web (oauth).

Em resumo, há um servidor de recursos que hospeda um recurso protegido, um proprietário do recurso, um aplicativo cliente que busca acesso ao recurso e um servidor de autorização que emite tokens de acesso ao recurso quando instruído pelo proprietário do recurso.

A documentação oficial do OAuth tende a assumir um cenário no qual há um único proprietário de recurso que concede acesso ao recurso do aplicativo cliente sempre que o aplicativo cliente é executado. Ele também pressupõe que a pessoa que usa o aplicativo cliente é o proprietário do recurso.

A implementação do SharePoint leva em conta o fato de que um recurso do SharePoint, como uma lista, é compartilhado entre vários usuários. Além disso, na implementação do SharePoint, o Suplemento do SharePoint recebe acesso quando ele é instalado, não toda vez que é executado e pode ser executado por usuários diferentes da pessoa que o instalou e concedeu acesso a ele. (No caso de suplementos que não estão instalados no SharePoint, mas acessam recursos do SharePoint (portanto, eles são "Suplementos do SharePoint" apenas em um sentido estendido), o usuário que executa o suplemento precisa conceder permissões sempre que o suplemento é executado.)

Portanto, na implementação do SharePoint, o papel do OAuth é desempenhado pelos seguintes componentes:

  • O componente remoto de um Suplemento do SharePoint desempenha a função do aplicativo cliente.

  • Os usuários do SharePoint desempenham a função de proprietários de recursos.

  • O SharePoint desempenha a função de servidor de recurso.

  • O Azure ACS desempenha a função do servidor de autorização quando o sistema de autorização de baixa confiança é usado. Quando o sistema de alta confiança é usado, o suplemento em si (juntamente com um certificado digital) se torna o servidor de autorização.

Tokens de acesso não são tokens de entrada

Conforme descrito anteriormente, para acessar recursos, um suplemento precisa solicitar um token de acesso de um servidor de autorização OAuth que foi designado anteriormente como um STS (emissor de token de segurança) confiável pelo proprietário do recurso. Por outro lado, o STS do WS-Federation e o STS de entrada passiva do Linguagem da Marcação da Asserção de Segurança (SAML) destinam-se principalmente a emitir tokens de entrada.

No SharePoint, um STS OAuth não é usado para emitir tokens de entrada; ou seja, eles não são usados como provedores de identidade. Por isso você não verá o STS listado na página de entrada do usuário, na seção Provedor de Autenticação da Administração Central, ou no Seletor de Pessoas no SharePoint.

Os administradores do SharePoint podem usar comandos do Windows PowerShell para ativar ou desativar um STS OAuth, de modo similar a como podem habilitar ou desabilitar provedores de entrada confiável no SharePoint.

Confira também