Notas de Versão

Atualizado: 19 de junho de 2015

Aplica-se a: Azure

Este tópico descreve as novas funcionalidades em cada versão de Microsoft Azure Ative Directory Controlo de Acesso (também conhecido como Controlo de Acesso Service ou ACS), explica como cada lançamento do produto difere dos seus antecessores, e destaca quaisquer alterações de rutura que possam afetar o código escrito para um anterior libertação.

• Março de 2015 – Migrar espaços de nomes ACS para o Google OpenID Ligação

• Junho de 2014 - Google Identity Provider Support

• Notas de lançamento de atualização de julho de 2013

• Notas de lançamento de atualização de dezembro de 2012

• Setembro de 2012 Notas de lançamento de atualização

• Junho de 2012 Notas de lançamento de atualização

• Notas de lançamento de atualização de maio de 2012

• Janeiro de 2012 Notícias de Lançamento de Atualização

• Notas de lançamento de atualização de julho de 2011

Março de 2015 – Migrar espaços de nomes ACS para o Google OpenID Ligação

A ACS implementou uma funcionalidade para ajudar os proprietários de espaços de nome ACS a migrarem as suas configurações de fornecedor de identidade google de OpenID 2.0 para OpenID Ligação. Os clientes terão até 1 de junho de 2015 para migrar os seus espaços de nomes ACS para openID Ligação e até 1 de janeiro de 2017 para migrar o seu código de backend para usar identificadores de Ligação OpenID. A não realização da ação adequada antes de cada prazo causará perturbações nas suas aplicações. Para obter orientações detalhadas, consulte os espaços de nomes ACS migratórios para o Google OpenID Ligação.

Junho de 2014 - Google Identity Provider Support

A partir de 19 de maio de 2014, os novos espaços de nome ACS não podem usar o Google como fornecedor de identidade. Os espaços de nomes ACS que usaram o Google e foram registados antes de 19 de maio de 2014 não são afetados. Esta nova limitação existe porque a Google está a eliminar progressivamente o suporte ao OpenID 2.0, do qual a ACS depende, e tem registo fechado para novas aplicações. Os espaços de nomes ACS existentes que usaram o Google continuarão a funcionar até 20 de abril de 2015. Se a sua aplicação necessitar de suporte para contas do Google, recomendamos que registe a sua aplicação diretamente com elas.

Se um utilizador tentar iniciar scontabilidade num novo espaço de nome ACS utilizando a sua conta Google, será redirecionado para uma página de erro HTTP 400.

Notas de lançamento de atualização de julho de 2013

Para aumentar a disponibilidade e desempenho de ACS para todos os utilizadores, a ACS implementou um limite de 30 pedidos simbólicos por segundo para cada espaço de nome. Se um espaço de nome exceder este limite por um período prolongado, a ACS rejeita pedidos simbólicos do espaço de nomes durante a duração do intervalo e devolve um erro HTTP 429 / ACS90055 "Demasiados pedidos". Para mais informações, consulte as Limitações de Serviço ACS e códigos de erro ACS.

Notas de lançamento de atualização de dezembro de 2012

Novas Funcionalidades

A atualização de dezembro de 2012 da ACS inclui as seguintes novas funcionalidades:

Suporte para uma única sinserção federada utilizando o protocolo WS-Federation

As aplicações web que utilizam o ACS para permitir uma única s-on (SSO) com fornecedores de identidade que usam o protocolo WS-Federation podem agora tirar partido das capacidades de assinatura única. Quando um utilizador assina uma aplicação web, o ACS pode assinar automaticamente o utilizador fora do fornecedor de identidade e de outras aplicações de partes que utilizam o mesmo fornecedor de identidade.

Esta funcionalidade é ativada para fornecedores de identidade WS-Federation, incluindo Serviços de Federação do Ative Directory (AD FS) 2.0 e Windows Live ID (conta Microsoft). Para ativar a assinatura única, a ACS executa as seguintes tarefas para WS-Federation pontos finais do protocolo:

• A ACS reconhece mensagens wsignoutclean1.0 de fornecedores de identidade e responde enviando mensagens wsignoutclean1.0 para aplicações de partidos em gestão.

• A ACS reconhece wsignout1.0 e recolhe mensagens profundas de aplicações partidárias e responde enviando mensagens wsignout1.0 a fornecedores de identidade e mensagens wsignoutclean1.0 para aplicações de partidos em gestão.

Para obter mais informações, consulte a Amostra de Código: ASP.NET MVC 4 com Sign-out Federado e Autenticação Passiva para ASP.NET na WIF.

Descontinuar o suporte para ACS 1.0

O suporte para Controlo de Acesso o Serviço 1.0 é interrompido nesta versão, incluindo o suporte para migrar do Serviço Controlo de Acesso 1.0 para Controlo de Acesso Serviço 2.0.

Navegar para Controlo de Acesso espaços de nome no novo Portal de Gestão do Azure

O novo Portal de Gestão Azure (https://manage.WindowsAzure.com) inclui uma rota para o conhecido portal de Gestão ACS onde cria e gere Controlo de Acesso espaços de nome.

Para navegar até ao portal de Gestão ACS:

1. Vá ao Portal de Gestão Microsoft Azure (https://manage.WindowsAzure.com), inscreva-se e, em seguida, clique em Ative Directory. (Dica de resolução de problemas: o item "Ative Directory" está em falta ou não está disponível)

2. Clique num Controlo de Acesso espaço de nome e, em seguida, clique em Gerir.

Para criar um Controlo de Acesso espaço de nome, clique em Novos, clique em Serviços de Aplicações, clique Controlo de Acesso e, em seguida, clique em "Criar" Quick. (Ou, clique Controlo de Acesso Espaços de Nome antes de clicar em New.)

Para obter ajuda com as tarefas de gestão da ACS no Portal de Gestão de Microsoft Azure, clique em Ative Directory e, em seguida, clique em Ajuda (?). (Ou, clique em Ative Directory, clique em Controlo de Acesso Espaços de Nome e, em seguida, clique em Ajuda.)

Navegar para o Controlo de Acesso espaço de nome para um ônibus de serviço

Ao criar um espaço de nome Service Bus no , o portal cria automaticamente um espaço de nome Controlo de Acesso para o autocarro de serviço.

Para configurar e gerir o Controlo de Acesso espaço de nome para um autocarro de serviço:

1. Inicie sessão no Portal de Gestão do Azure.

2. Clique Service Bus e, em seguida, selecione um ônibus de serviço.

3. Clique em Tecla de acesso e, em seguida, clique em Abrir o Portal de Gestão ACS.

Para verificar se o Controlo de Acesso espaço de nome está associado ao autocarro de serviço, consulte o campo Service Namespace no topo da página de Serviço Controlo de Acesso. O nome do espaço de nome é constituído pelo nome do ônibus de serviço com um sufixo "-sb".

Para mais informações, consulte Como: Gerir o Controlo de Acesso Namespace para uma Service Bus.

Melhorias do portal de gestão ACS para visualização de chaves de fornecedor de identidade WS-Federation, ocultando senhas

Esta versão contém um par de melhorias relacionadas com visualização e trabalho com certificados, chaves e senhas no portal de gestão ACS 2.0:

• Os certificados de assinatura passam a estar visíveis na secção Edit WS-Federation Fornecedor de Identidade – Anteriormente, os certificados importados de metadados WS-Federation utilizados para validar a assinatura de fichas emitidas por esse fornecedor de identidade não eram visíveis no portal de Gestão acs. A secção Edit WS-Federation Identity Provider apresenta agora informações sobre certificados importados, incluindo as datas de validade e o estado. Estes certificados podem agora ser atualizados utilizando uma nova caixa de verificação "Reimport dados de WS-Federation sobre a poupança".

• As palavras-passe e as teclas de assinatura simétrica estão agora escondidas por padrão – Para evitar a divulgação não intencional de palavras-passe e teclas simétricas, estes valores estão agora escondidos por padrão nos ecrãs editar em todo o portal. Para mostrar intencionalmente o valor de uma palavra-passe ou tecla simétrica (por exemplo, para que possa ser copiada para uma aplicação), um botão "Mostrar Palavra-Passe" ou "Mostrar Chave" tem agora de ser premido.

Capacidade de Federate Directory Inquilinos com Controlo de Acesso espaços de nome

Azure Ative Directory inquilinos podem agora ser usados como fornecedores de identidade em espaços Controlo de Acesso nome. Isto permite que muitos cenários, como permitir que a sua aplicação web aceite identidades organizacionais de inquilinos de diretórios e identidades de consumidores de fornecedores sociais como Facebook, Google, Yahoo!, contas da Microsoft ou qualquer outro fornecedor OpenID. Você pode encontrar instruções detalhadas sobre como implementar o cenário neste post, Provisionando um inquilino Azure Ative Directory como Um Fornecedor de Identidade em um espaço de nome ACS.

Suporte ao protocolo SAML 2.0 para aplicações do partido de suporte (pré-visualização do desenvolvedor)

A ACS apoia agora o protocolo SAML 2.0 para a emissão de fichas para aplicações partidárias. O suporte ao protocolo SAML 2.0 foi lançado como pré-visualização do desenvolvedor, o que significa que os detalhes da implementação do protocolo SAML 2.0 ainda estão sujeitos a alterações. Para mais detalhes, consultea Pré-visualização do Desenvolvedor: SAMLProtocol.

Problemas Conhecidos

Em dezembro de 2012, Microsoft Azure Ative Directory Controlo de Acesso (também conhecido como serviço Controlo de Acesso ou ACS), foram identificados os seguintes problemas conhecidos:

Azure Co-Administrators agora pode gerir Controlo de Acesso espaços de nome. No entanto, é necessária uma ação para propagar os coadministradores pré-existentes a um espaço de nome Controlo de Acesso pré-existente.

Antes da atualização de novembro de 2012, resolvemos um problema em que, por padrão, apenas o administrador de serviços Azure primário poderia gerir Controlo de Acesso espaços de nome criados na subscrição. Se um coadministrador da Azure tentasse aceder ao Portal de Gestão ACS para um espaço de nome Controlo de Acesso, receberiam um dos seguintes códigos de erro ACS:

• ACS50000: Houve um erro emitindo um símbolo.

• ACS60000: Ocorreu um erro durante o processamento de regras de processamento para a parte de recurso usando o emitente 'uri:WindowsLiveID'

• ACS60001: Não foram gerados pedidos de produção durante o processamento de regras.

Esta questão está agora resolvida para novos espaços de nome Controlo de Acesso criados por qualquer administrador ou coadministrador de serviços da Azure. No entanto, os clientes com espaços de nome que existiam antes da correção precisam de realizar a seguinte solução para que os dados de coadministrador se propaguem para esses espaços de nome:

1. Inscreva-se no portal do Azure (https://windows.azure.com/) utilizando credenciais de administrador de serviço ou de administrador de conta.

2. Remova e reensite o coadministrador, utilizando a orientação em Como Adicionar e Remover Co-Administrators para as Suas Subscrições Azure (https://msdn.microsoft.com/library/windowsazure/gg456328.aspx)

3. Inscreva-se e inscreva-se no portal do Azure utilizando as credenciais de coadministrador. Poderá então gerir os Controlo de Acesso espaços de nome.

Setembro de 2012 Notas de lançamento de atualização

Em setembro de 2012, Microsoft Azure Ative Directory Controlo de Acesso (também conhecido como serviço Controlo de Acesso ou ACS) recebeu uma atualização que continha as seguintes alterações:

A entidadeID publicada no WS-Federation metadados emitidos pela ACS é agora consistentemente minúscula

O atributo "entidadeID" nos metadados WS-Federation publicados pela Controlo de Acesso namespaces é agora sempre minúsculo. Em lançamentos anteriores, usou a caixa de cartas que foi inserida quando o espaço de nome foi criado no portal do Azure. O atributo "entidadeID" identifica o Controlo de Acesso espaço de nome às aplicações partidárias, e abaixo é um exemplo do atributo:

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://lowercase-namespace.accesscontrol.windows.net/" ID="_e4a0006c-c23c-41c0-8f87-baa110afaf1d">

Esta alteração foi necessária para resolver potenciais questões de validação de símbolos em que o caso de letra do Controlo de Acesso espaço de nome no token emitido pela ACS (que é sempre mais baixo) não corresponde ao caso da letra do Controlo de Acesso espaço de nome importado pela parte conta-a-bomba. As partes que utilizam Windows Fundação de Identidade não são afetadas pelas questões de sensibilidade ao caso.

Os certificados X.509 enviados para ACS têm agora uma restrição de tamanho de chave pública de 4096 bits

Todos os certificados X.509 enviados para um espaço de nome Controlo de Acesso através do portal de gestão ACS ou do serviço de gestão passam a ter uma dimensão de chave pública que não seja superior a 4096 bits. Isto inclui certificados usados para a assinatura simbólica, encriptação simbólica e desencriptação simbólica.

Em Windows, o tamanho da chave pública de um certificado pode ser verificado através da abertura do certificado (. ARQUIVO CER), selecionando o separador "Detalhes" e verificando o valor do campo "chave pública". Os certificados que usam o algoritmo de assinatura sha256RSA seguro terão uma chave pública de 2048.

Os certificados existentes com uma dimensão-chave superior a 4096 bits continuarão a funcionar com ACS, mas estes certificados não podem ser ressaltados em ACS até que sejam substituídos por um certificado em conformidade.

Pequena alteração para algoritmo de seleção de "chave primária" que é usado quando o ACS assina um símbolo usando um certificado X.509

No portal de gestão e serviço de gestão da ACS, existe um campo "Make Primary" para certificados de assinatura simbólica que, quando selecionados, faz com que a ACS assine fichas utilizando esse certificado. Com esta versão, se nenhum certificado de assinatura de token configurado tiver verificado o campo "Fazer Primário", o espaço de nome Controlo de Acesso utilizará o certificado de assinatura não primário existente que tem a data de início mais cedo válida para assinar o token. A ACS ainda não assina fichas com um certificado de assinatura de ficha não primária se existir um certificado primário, mas for inválido ou expirar.

JWT Beta: Alterar o comportamento de assinatura ao usar um certificado de espaço de nome global ou chave para assinar um token JWT

Quando o suporte beta para o formato JSON Web Token (JWT) foi lançado em junho de 2012, a ACS utilizou a seguinte ordem de precedência para determinar que chave deve ser usada para assinar cada token JWT emitido para cada aplicação do partido que conta:

• Chave de assinatura simétrica atribuída à parte dependente, se disponível

• Certificado de assinatura X.509 atribuído à parte de cedida, se disponível

• Chave de assinatura simétrica atribuída ao espaço de nome Controlo de Acesso

• Certificado de assinatura X.509 atribuído ao espaço de nome Controlo de Acesso

A partir desta versão, as teclas simétricas em todo o nome já não são suportadas para a assinatura de fichas JWT. Abaixo está a nova ordem de precedência para a assinatura de fichas JWT:

• Chave de assinatura simétrica atribuída à parte dependente, se disponível

• Certificado de assinatura X.509 atribuído à parte de cedida, se disponível

• Certificado de assinatura X.509 atribuído ao espaço de nome Controlo de Acesso

Junho de 2012 Notas de lançamento de atualização

Em junho de 2012, a ACS recebeu uma atualização que continha a seguinte nova funcionalidade:

Formato JWT agora disponível para aplicações de partes em gestão (Beta)

Esta atualização introduz suporte para o formato BETA JSON Web Token (JWT) em ACS. JWT é um formato de token leve, codificado por JSON, que pode ser assinado usando um certificado X.509 ou chave simétrica, e pode ser emitido pela ACS para confiar aplicações de partes sobre qualquer um dos seguintes protocolos:

• OAuth 2.0

• WS-Federation

• WS-Trust

O formato JWT token é agora uma opção selecionável na secção de Aplicações de Partidos Dependentes do Portal de Gestão ACS, e também é configurável através do Serviço de Gestão ACS.

Para saber mais sobre o formato JWT token, consulte a especificação JSON Web Token. As amostras de código ACS que apresentam tokens JWT serão apresentadas numa data futura.

Importante

O suporte jWT é marcado como "Beta" em ACS, o que significa que todos os detalhes da implementação do JWT estão sujeitos a alterações. Os desenvolvedores são encorajados a experimentar com este formato simbólico. No entanto, o JWT não deve ser utilizado nos serviços de produção, uma vez que o comportamento pode mudar sem aviso prévio.

Notas de lançamento de atualização de maio de 2012

No início de maio de 2012, a ACS recebeu uma atualização que continha a seguinte alteração:

Alterações nas propriedades de ID da entidade expostas através do serviço de gestão

O Serviço de Gestão ACS expõe atualmente uma propriedade de ID para cada um dos tipos de entidade que suporta, conforme descrito na Referência API do Serviço de Gestão acs. Estas propriedades de ID são automaticamente definidas e geridas pela ACS.

Nesta atualização de serviço, o ACS está a ser migrado para um esquema de base de dados diferente, e como resultado estes IDs expostos através do serviço de gestão mudarão para todos os tipos de entidades.

É incomum e geralmente não é recomendado que as aplicações armazenem ou tomem uma dependência codificada destes IDs de forma a consultar entidades específicas através do serviço de gestão. Em vez disso, recomenda-se que os tipos de entidades de Gestão de Funções, ServiceId, RuleGroup e Emiter sejam consultados utilizando a propriedade Name, e outros tipos de entidades sejam questionados através de um ID de entidade-mãe (por exemplo, RuleGroupId no caso de regras, ou EmiterId no caso de fornecedores de identidade).

Alterações à colagem de bases de dados para processamento de regras

A fim de expandir o apoio às línguas internacionais e melhorar a segurança, esta versão do ACS atualiza a colagem subjacente SQL base de dados utilizada para comparar os pedidos de entrada de SQL_Latin1_General_CP1_CI_AS a Latin1_General_100_BIN2. Esta alteração permite que o ACS suporte conjuntos de caracteres adicionais e combinações de conjuntos de caracteres. As aplicações que se baseiam em alegações de entrada que contenham cordas com múltiplos conjuntos de caracteres, não suportadas por SQL_Latin1_General_CP1_CI_AS podem ver reivindicações diferentes ou adicionais como resultado desta nova colagem. Os clientes que desejem tirar partido desta nova capacidade são encorajados a validar as suas aplicações de compatibilidade com a nova SQL colagem.

Janeiro de 2012 Notícias de Lançamento de Atualização

Em 25 de janeiro de 2012, ACS 2.0 recebeu uma atualização que continha as seguintes alterações:

• Alteração nas respostas de erro da ACS para pedidos de autenticação falhada

• Alteração nos códigos de erro OAuth 2.0 para pedidos de autenticação falhados

Alteração nas respostas de erro da ACS para pedidos de autenticação falhada

Na versão anterior, a ACS respondeu com diferentes códigos de erro quando um cliente autenticado com um emitente inexistente (código de erro: ACS50026) ou credenciais incorretas (código de erro: ACS50006). Estes códigos de erro foram previamente emitidos quando um cliente tentou autenticar usando um nome de identidade de serviço inválido, ou usando um token SWT ou SAML emitido a partir de um fornecedor de identidade inválido.

A ACS devolverá os códigos de erro ACS50008, ACS50009 ou ACS50012 para uma autenticação falhada nos casos de SWT, SAML e username/password, respectivamente. Consulte a tabela abaixo para mais detalhes:

Resposta à autenticação	Antes	Depois
Emitente inexistente	Emitente ACS50026NotFound	ACS50008 invalida, ACS50009 InvalidSaml, OR Autenticação ACS50012Failed
Credenciais incorretas	Assinatura inválida acS50006

Alteração nos códigos de erro OAuth 2.0 para pedidos de autenticação falhados

Também no lançamento anterior, a ACS respondeu com diferentes códigos de erro OAuth 2.0 quando um cliente autenticado com um emitente inexistente (invalid_client) ou credenciais incorretas (invalid_grant). Este comportamento também foi atualizado, e a ACS regressará invalid_request quando o pedido de 2.0 da OAuth for mal formado, invalid_client se o cliente falhar a autenticação ou se a afirmação fornecida para a autenticação for mal formada ou inválida, e invalid_grant se o código de autorização for mal formado ou inválido. Consulte a tabela abaixo para mais detalhes:

Resposta à autenticação	Exemplos	Antes	Depois
Emitente inexistente		invalid_client	invalid_client
Credenciais incorretas	A SWT é assinada com uma chave incorreta. Identificação de clientes e credenciais correspondem às configuradas em ACS.	invalid_grant
Autenticação falhada	A validação do URI do público falhou. A validação do certificado falhou. A afirmação de uma Identidade de Serviço contém reclamações auto-emitidas.	invalid_grant
Afirmação mal formada	Falta a assinatura da SWT. A afirmação da SAML não é válida XML.	invalid_request
Código de Autorização Mal formado		invalid_grant	invalid_grant
Código de Autorização Inválido		invalid_grant
Pedido mal formado de OAuth2		invalid_request	invalid_request

Notas de lançamento de atualização de julho de 2011

As notas de lançamento para a atualização de julho de 2011 do ACS 2.0 contém os seguintes itens:

• Pré-requisitos

• Novas Funcionalidades

• Alterações

• Problemas Conhecidos

• Problemas Conhecidos

Pré-requisitos

Todos os Controlo de Acesso espaços de nomes recebem automaticamente a atualização de julho de 2011. Esta atualização não contém alterações nos pré-requisitos acs para clientes novos ou existentes. Para obter mais informações sobre os pré-requisitos acs atuais, consulte os pré-requisitos acs.

Novas Funcionalidades

A atualização de julho de 2011 para ACS contém as seguintes novas funcionalidades:

1. As regras agora suportam até dois pedidos de entrada

O motor de regras ACS suporta agora um novo tipo de regra que permite configurar até duas alegações de entrada, em vez de apenas uma reivindicação de entrada. As regras com duas reclamações de entrada podem ser utilizadas para reduzir o número total de regras necessárias para executar funções complexas de autorização do utilizador.

No Portal de Gestão acs, uma segunda reclamação de entrada pode ser especificada numa nova regra clicando Em Adicionar uma segunda reivindicação de entrada no editor de regras. No serviço de gestão, as regras com duas reclamações de entrada podem ser configuradas utilizando o tipo de entidade ConditionalRule . As regras com uma reclamação de entrada ainda estão configuradas utilizando o tipo de entidade de regra para retrocompatibilidade.

Para obter mais informações sobre regras com duas reclamações de entrada, consulte Grupos de Regras e Regras.

2. Localização em onze línguas

O Portal de Gestão acs e a página de login da ACS para as aplicações do partido em apoio agora apoiam a localização em onze línguas escritas, incluindo inglês, francês, alemão, italiano, japonês, coreano, russo, espanhol, português (Brasil), chinês simplificado e chinês tradicional. Está também disponível uma opção "Inglês (Internacional)" que utiliza um formato de data alternativa para configurar e exibir datas de efetivo/validade para as teclas. O idioma escrito apresentado para estas interfaces de utilizador pode ser alterado de uma das três seguintes formas:

• Seletor de Idiomas – No Portal de Gestão ACS, o idioma visualizado pode ser alterado instantaneamente usando um novo menu seletor de idiomas que aparece no canto superior direito do portal.

• URL – O idioma apresentado no Portal de Gestão ACS pode ser alterado adicionando um parâmetro "lang" ao fim do URL de pedido. Os valores legais para este parâmetro são códigos linguísticos ISO 639-1/3166 que correspondem a uma língua suportada. Os valores exemplos incluem en, de, es, fr, it, ja, ko, ru, pt-br, zh-cn, e zh-tw. Abaixo está um exemplo DO PORTAL de Gestão ACS com um parâmetro que define a língua exibida para francês:

  https://your-namespace.accesscontrol.windows.net/?lang=fr

• Preferências do navegador web – Se o parâmetro URL "lang" ou o seletor de idiomas nunca tiver sido utilizado para definir uma preferência de idioma, então o Portal de Gestão acs e as páginas de login hospedadas em ACS determinarão o idioma predefinido a exibir com base nas preferências de idioma definidas nas definições do navegador web.

Alterações

Seguem-se alterações notáveis de comportamento de serviço nesta versão:

1. A codificação é agora UTF-8 para todas as respostas OAuth 2.0

No lançamento inicial do ACS, o conjunto de codificação de caracteres para todas as respostas HTTP do ponto final OAuth 2.0 foi US-ASCII. Na atualização de julho de 2011, a codificação de caracteres de todas as respostas HTTP está agora definida para UTF-8 para suportar conjuntos de caracteres estendidos.

Problemas Conhecidos

Segue-se uma questão conhecida nesta versão:

O editor de regras não pode exibir emitentes personalizados que não estão associados a fornecedores de identidade

Atualmente, o editor de regras do Portal de Gestão acs apenas pode exibir emitentes de reclamação que estejam associados a um fornecedor de identidade ou ACS. Se for carregada uma regra que faça referência a um emitente que não corresponda a nenhuma destas coisas, o seguinte erro será apresentado:

• ACS80001: Esta regra está configurada para utilizar um tipo de Emitente de Reclamação que não é suportado pelo portal de gestão. Por favor, utilize o serviço de gestão para visualizar e editar esta regra.

Existem dois cenários apoiados em que um emitente pode existir sem um fornecedor de identidade associado em ACS:

• Num cenário de delegação OAuth 2.0, é criado um registo emitente no espaço de nome Controlo de Acesso utilizando o Serviço de Gestão ACS, e este emitente não tem um fornecedor de identidade associado.

• Quando um emitente é criado com o propósito de afirmar reclamações num pedido simbólico sobre o protocolo OAuth WRAP, enquanto utiliza uma identidade de serviço com o mesmo nome para autenticar com ACS.

Quotas

A partir desta publicação, a ACS não impõe limites ao número de fornecedores de identidade, invocando aplicações de partes, grupos de regras, regras, identidades de serviço, tipos de reclamações, registos de delegações, emitentes, chaves e endereços que podem ser criados para um dado espaço de nome Controlo de Acesso.

Limitações de serviço

Para obter mais informações sobre as limitações de serviço, consulte as Limitações de Serviço ACS.