Serviços Web e ACS

Atualizado: 19 de junho de 2015

Aplica-se ao Azure

Veja a seguir os participantes do cenário básico no qual um serviço Web é integrado ao Microsoft Azure Active Directory Controle de Acesso (também conhecido como Serviço Controle de Acesso ou ACS):

• Aplicativo de terceira parte confiável — Seu serviço Web.

• Cliente — Um cliente de serviço Web que está tentando ter acesso ao seu serviço Web.

• Provedor de identidade — Um site ou um serviço que pode autenticar o cliente.

• ACS — A partição do ACS dedicado ao seu aplicativo de terceira parte confiável.

Entretanto, o cenário do serviço Web pressupõe que o cliente não tenha acesso a um navegador e que esteja agindo com autonomia (sem participação direta do usuário no cenário).

O cliente deve obter um token de segurança emitido pelo ACS para fazer logon em seu serviço. Esse token é uma mensagem assinada do ACS para seu aplicativo, com um conjunto de declarações sobre a identidade do cliente. O ACS não emite um token, a menos que o cliente prove primeiro sua identidade.

Em um serviço Web e em um cenário acs, um cliente pode provar sua identidade das seguintes maneiras:

• Autenticando diretamente com ACS e usando os tipos de credencial de Identidade de Serviço acS

  Observação

  Para obter mais informações sobre identidades de serviço, consulte Identidades de Serviço.

  A figura a seguir ilustra o cenário do serviço Web com o cliente provando sua identidade com tipos de credencial de identidade de serviço ACS.

  

  1. O cliente é autenticado com ACS usando um dos tipos de credencial de Identidade de Serviço acS. No ACS, isso pode ser um token SWT (Simple Web Token) assinado com uma chave simétrica, um certificado X.509 ou uma senha. Para obter mais informações, consulte Identidades de Serviço.

  2. O ACS valida as credenciais recebidas, insere as declarações de identidade recebidas no mecanismo de regras acs, calcula as declarações de saída e cria um token que contém essas declarações.

  3. O ACS retorna o token emitido pelo ACS para o cliente.

  4. O cliente envia o token emitido pelo ACS para o aplicativo de terceira parte confiável.

  5. O aplicativo de terceira parte confiável valida o token emitido pelo ACS e retorna a representação de recurso solicitada.

• Apresentando um token de segurança de outro emissor confiável (provedor de identidade) que autenticou esse cliente

  A figura a seguir ilustra o cenário de serviço Web com o cliente comprovando sua identidade com um token de segurança de um provedor de identidade.

  

  1. O cliente se conecta ao provedor de identidade (por exemplo, envia as credenciais).

  2. Depois que o cliente é autenticado, o provedor de identidade emite um token.

  3. O provedor de identidade retorna o token ao cliente.

  4. O cliente envia o token emitido pelo Provedor de Identidade para ACS.

  5. O ACS valida o token emitido pelo Provedor de Identidade, insira os dados no token emitido pelo Provedor de Identidade para o mecanismo de regras ACS, calcula as declarações de saída e cria um token que contém essas declarações.

  6. O ACS emite um token para o cliente.

  7. O cliente envia o token emitido pelo ACS para o aplicativo de terceira parte confiável.

  8. O aplicativo de terceira parte confiável valida a assinatura no token emitido pelo ACS e valida as declarações no token emitido pelo ACS.

  9. O aplicativo de terceira parte confiável retorna a representação do recurso solicitado.

Consulte Também

Conceitos

Serviço de Controle de Acesso 2.0
Introdução com ACS
Como criar meu primeiro serviço de ASP.NET com reconhecimento de declarações usando ACS