Serviços Web e ACS

Atualizado: 19 de junho de 2015

Aplica-se a: Azure

Seguem-se os participantes do cenário básico em que um serviço web é integrado com Microsoft Azure Ative Directory Controlo de Acesso (também conhecido como serviço Controlo de Acesso ou ACS):

• Aplicação de partidos dependentes — O seu serviço web.

• Cliente — Um cliente de serviço web que está a tentar aceder ao seu serviço web.

• Fornecedor de Identidade — um site ou serviço que pode autenticar o cliente.

• ACS — A divisão do ACS que é dedicada à sua aplicação do partido em gestão.

No entanto, o cenário de serviço web pressupõe que o cliente não tem acesso a um navegador e está a agir de forma autónoma (sem que um utilizador participe diretamente no cenário).

O cliente deve obter um sinal de segurança emitido pela ACS para iniciar sessão no seu serviço. Este token é uma mensagem assinada da ACS para a sua aplicação, com um conjunto de reclamações sobre a identidade do cliente. A ACS não emite um símbolo a menos que o cliente prove primeiro a sua identidade.

Num site de serviço web e ACS, um cliente pode provar a sua identidade das seguintes formas:

• Autenticando diretamente com ACS e utilizando os tipos de credenciais de identidade de serviço ACS

  Nota

  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 a provar a sua identidade com tipos de credenciais de identidade de serviço ACS.

  

  1. O cliente autentica com ACS utilizando um dos tipos de credenciais de identidade de serviço ACS. No ACS, este pode ser um token Web Simple Token (SWT) assinado com uma chave simétrica, um certificado X.509 ou uma senha. Para mais informações, consulte as Identidades de Serviço.

  2. A ACS valida as credenciais recebidas, introduz as alegações de identidade recebidas no motor das regras acs, calcula as alegações de saída e cria um símbolo que contém essas alegações.

  3. A ACS devolve o token emitido pela ACS ao cliente.

  4. O cliente envia o token emitido pela ACS para a aplicação da parte de gestão.

  5. A aplicação da parte contando valida o token emitido pela ACS e, em seguida, devolve a representação de recursos solicitado.

• Ao apresentar um símbolo de segurança de outro emitente de confiança (Fornecedor de Identidade) que autenticou esse cliente

  A figura a seguir ilustra o cenário de serviço web com o cliente a provar a sua identidade com um símbolo de segurança de um Fornecedor de Identidade.

  

  1. O cliente entra no Fornecedor de Identidade (por exemplo, envia as credenciais).

  2. Após a autenticação do cliente, o Fornecedor de Identidade emite um token.

  3. O Fornecedor de Identidade devolve o token ao cliente.

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

  5. A ACS valida o token emitido pelo Fornecedor de Identidade, introduz os dados no token emitido pelo Fornecedor de Identidade no motor das regras acs, calcula as alegações de saída e cria um símbolo que contém essas alegações.

  6. ACS emite um sinal para o cliente.

  7. O cliente envia o token emitido pela ACS para a aplicação da parte de gestão.

  8. A aplicação da parte contando valida a assinatura no token emitido pela ACS e valida as reclamações no token emitido pela ACS.

  9. O pedido de contação do partido devolve a representação de recursos solicitado.

Consulte também

Conceitos

Serviço Controlo de Acesso 2.0
Introdução com ACS
Como: Criar o meu primeiro serviço de ASP.NET consciente de reclamações usando ACS