Exportar (0) Imprimir
Expandir Tudo

Notas de versão

Publicado: abril de 2011

Atualizado: janeiro de 2015

Aplica-se a: Azure

Este tópico descreve os novos recursos de cada versão do Acess Control do Active Directory do Microsoft Azure (também conhecido como Access Control Service ou ACS), explica como cada versão do produto difere de suas predecessoras e destaca eventuais mudanças de código que possam afetar o código escrito para uma versão anterior.

A partir de 19 de maio de 2014, os novos namespaces do ACS não podem usar o Google como um provedor de identidade. Os namespaces do ACS que usavam o Google e foram registrados antes de 19 de maio de 2014 não serão afetados. Essa nova limitação existe porque o Google está encerrando o suporte para o OpenID 2.0, do qual o ACS depende, e encerrou o registro de novos aplicativos. Os namespaces do ACS existentes que usavam o Google continuarão a funcionar até 20 de abril de 2015. Se o seu aplicativo exige suporte para contas do Google, recomendamos o registro de seu aplicativo diretamente junto ao Google.

Se um usuário tentar entrar em um novo namespace do ACS usando sua conta do Google, será redirecionado a uma página de erro HTTP 400.

Novo namespace ACS e erro do Google

Para aumentar a disponibilidade e o desempenho do ACS para todos os usuários, o ACS implementou um limite de 30 solicitações de token por segundo para cada namespace. Se um namespace ultrapassar esse limite durante um período prolongado, o ACS rejeitará as solicitações de token do namespace durante o intervalo e retornará um erro HTTP 429 / ACS90055 "Número excessivo de solicitações". Para obter mais informações, consulte Limitações do serviço ACS e Códigos de erro do ACS.

Novos recursos

A atualização de dezembro de 2012 do ACS inclui os seguintes recursos novos:

Suporte para saída única federada usando o protocolo Web Services Federation

Os aplicativos Web que usam o ACS para habilitar o logon único (SSO) com provedores de identidade que usam o protocolo Web Services Federation podem agora aproveitar os recursos de saída única. Quando um usuário sai de um aplicativo Web, o ACS pode fazer automaticamente o logoff do usuário do provedor de identidade e de outros aplicativos de terceiras partes confiáveis que usam o mesmo provedor de identidade.

Esse recurso é habilitado para provedores de identidade de Web Services Federation, incluindo os Serviços de Federação do Active Directory 2.0 e Windows Live ID (conta da Microsoft).. Para habilitar o logoff único, o ACS executa as seguintes tarefas para pontos de extremidade do protocolo Web Services Federation:

  • O ACS reconhece mensagens wsignoutcleanup1.0 de provedores de identidade e responde enviando mensagens wsignoutcleanup1.0 aos aplicativos de terceiras partes confiáveis.

  • O ACS reconhece mensagens wsignout1.0 e wreply de aplicativos de terceiras partes confiáveis e responde enviando mensagens wsignout1.0 aos provedores de identidade e mensagens wsignoutcleanup1.0 aos aplicativos de terceiras partes confiáveis.

Para obter mais informações, consulte Exemplo de código: MCV 4 ASP.NET com saída federada e Autenticação passiva para ASP.NET em WIF.

Descontinuação do suporte para ACS 1.0

O suporte para o Serviço de Controle de Acesso 1.0 foi descontinuado nesta versão, incluindo o suporte para migração do Serviço de Controle de Acesso 1.0 para o Serviço de Controle de Acesso 2.0.

Navegando até os Namespace do Access Controls no novo Portal de Gerenciamento do Azure

O novo Portal de Gerenciamento do Azure (http://manage.WindowsAzure.com) inclui uma rota até o portal de Gerenciamento do ACS conhecido, no qual você cria e gerencia Namespace do Access Controls.

Para navegar até o portal de Gerenciamento do ACS:

  1. Vá para o Portal de Gerenciamento do Microsoft Azure(https://manage.WindowsAzure.com), entre e, em seguida, clique em Active Directory. (Dica de solução de problemas: o item "Active Directory" está ausente ou indisponível)

  2. Clique em um Namespace do Access Control e em seguida clique em Gerenciar.

Para criar um namespace do Access Control clique em Novo, clique em Serviços de Aplicativo, clique em Access Control, e depois em Criação Rápida. (Or, clique em Namespaces do Access Control antes de clicar em Novo.)

Para obter ajuda sobre as tarefas de gerenciamento do ACS no Portal de Gerenciamento do Microsoft Azure, clique em Active Directory, e depois em Ajuda (?). (Ou clique em Active Directory, clique em Namespaces do Access Control, e clique em Ajuda.)

Navegando até o Namespace do Access Control para um barramento de serviço

Quando você cria um namespace de Barramento de Serviço no , o portal cria automaticamente um Namespace do Access Control para o barramento de serviço.

Para configurar e gerenciar o Namespace do Access Control para um barramento de serviço:

  1. Faça logon no Portal de Gerenciamento do Azure.

  2. Clique em Barramento de Serviço e em seguida selecione um barramento de serviço.

  3. Clique em Chave de Acesso e em seguida clique em Abrir Portal de Gerenciamento do ACS.

Para verificar se o Namespace do Access Control está associado ao barramento de serviço, consulte o campo Namespace do Serviço na parte superior da página do Serviço de Controle de Acesso. O nome do namespace é formado pelo nome do barramento de serviço mais o sufixo "-sb".

Para obter mais informações, consulte Como: Gerenciar o namespace de controle de acesso de um barramento de serviço.

Aprimoramentos do portal de gerenciamento do ACS para exibição das chaves de provedores de identidade de Web Services Federation, ocultação das senhas

Esta versão contém alguns aprimoramentos relacionados à exibição e ao trabalho com certificados, chaves e senhas no portal de gerenciamento do ACS 2.0:

  • Agora, os certificados de autenticação estão visíveis na seção Editar provedor de identidade de Web Services Federation – Anteriormente, os certificados importados de metadados do Web Services Federation usados para validar a assinatura de tokens emitidos a partir desse provedor de identidade não eram visíveis no portal de Gerenciamento do ACS. A seção Editar provedor de identidade de Web Services Federation agora exibe informações sobre os certificados importados, incluindo seus status e datas de vencimento. Agora, esses certificados podem ser atualizados usando-se a nova caixa de seleção “Reimportar dados da URL de metadados da Web Services Federation ao salvar”.

  • Agora as senhas e as chaves de autenticação simétricas estão ocultas por padrão – Para impedir a divulgação não intencional de senhas e chaves simétricas, agora esses valores ficam ocultos por padrão nas telas Editar em todo o portal. Para exibir de forma intencional o valor de uma senha ou chave simétrica (por exemplo, de modo que possa ser copiado em um aplicativo), agora é necessário pressionar um botão “Mostrar Senha” ou “Mostrar Chave”.

Possibilidade de federar locatários de diretórios com Namespace do Access Controls

Agora, os locatários do Active Directory do Azure podem ser usados como provedores de identidade nos Namespace do Access Controls. Isso possibilita diversos cenários, permitindo, por exemplo, que seu aplicativo Web aceite identidades organizacionais de locatários de diretórios e identidades de consumidor de provedores sociais, como contas do Facebook, do Google, do Yahoo!, da Microsoft ou de qualquer outro provedor OpenID. Você pode obter instruções detalhadas sobre como implementar o cenário nesta publicação: Provisionando um locatário do Active Directory do Azure como provedor de identidade em um Namespace do ACS.

Suporte do protocolo SAML 2.0 para aplicativos de terceiras partes confiáveis (visualização para desenvolvedores)

Agora, o ACS oferece suporte ao protocolo SAML 2.0 para emissão de tokens para aplicativos de terceiras partes confiáveis. O suporte ao protocolo SAML 2.0 foi lançado como visualização para desenvolvedores, ou seja, os detalhes da implementação do protocolo SAML 2.0 ainda estão sujeitos a alterações. Para obter mais detalhes, consulteVisualização para desenvolvedores: Protocolo SAML.

Problemas conhecidos

Na atualização Acess Control do Active Directory do Microsoft Azure (também conhecido como Access Control Service ou ACS) de dezembro de 2012, foram identificados os seguintes problemas conhecidos:

Os coadministradores do Azure agora podem gerenciar Namespace do Access Controls. No entanto, é necessário executar uma ação para propagar os coadministradores preexistentes para Namespace do Access Controls preexistentes.

Antes da atualização de novembro de 2012, resolvemos um problema no qual, por padrão, apenas o administrador de serviço principal do Azure podia gerenciar Namespace do Access Controls criados na assinatura. Se um coadministrador do Azure tentava acessar o Portal de Gerenciamento do ACS de um Namespace do Access Control, recebia um dos seguintes códigos de erro do ACS:

  • ACS50000: Houve um erro ao emitir um token.

  • ACS60000: Ocorreu um erro ao processar regras para a terceira parte confiável usando o emissor 'uri:WindowsLiveID’

  • ACS60001: Não foram geradas declarações de saída durante o processamento das regras.

Agora, esse problema está resolvido para novos Namespace do Access Controls criados por qualquer administrador ou coadministrador de serviço do Azure. No entanto, os clientes com namespaces que existiam antes da correção precisam executar a seguinte solução alternativa para que os dados do coadministrador sejam propagados para esses namespaces:

  1. Entre no Portal do Azure (https://windows.azure.com/) usando as credenciais de administrador do serviço ou de administrador de conta.

  2. Remova e readicione o coadministrador, usando a orientação em Como adicionar e remover coadministradores de suas assinaturas do Azure (http://msdn.microsoft.com/en-us/library/windowsazure/gg456328.aspx)

  3. Saia e entre no Portal do Azure usando as credenciais de coadministrador. Assim, você poderá gerenciar os Namespace do Access Controls.

Em setembro de 2012, o Acess Control do Active Directory do Microsoft Azure (também conhecido como Access Control Service ou ACS) recebeu uma atualização contendo as seguintes alterações:

A entityID publicada nos metadados do Web Services Federation emitidos pelo ACS está agora em letras minúsculas

O atributo “entityID” nos metadados de Web Services Federation publicados pelos Namespace do Access Controls agora está sempre em letras minúsculas. Nas versões anteriores, ele era escrito com a mesma sequência de letras maiúsculas/minúsculas utilizada por ocasião da criação do namespace no Portal do Azure. O atributo “entityID” identifica o Namespace do Access Control para os aplicativos de terceiras partes confiáveis. Veja 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">

Essa alteração era necessária para resolver possíveis problemas de validação de tokens nos quais a sequência de letras maiúsculas/minúsculas do Namespace do Access Control no token emitido por ACS (que está sempre em letras minúsculas) não corresponde à sequência de letras maiúsculas/minúsculas do Namespace do Access Control importado pela terceira parte confiável. As terceiras partes confiáveis que usam o Windows Identity Foundation não são afetadas pelos problemas de diferença entre maiúsculas e minúsculas.

Agora, os Certificados X.509 carregados no ACS têm uma restrição de tamanho de chave pública de 4096 bits

Agora todos os Certificados X.509 carregados em um Namespace do Access Control por meio do portal de gerenciamento ou do serviço de gerenciamento do ACS precisam ter um tamanho de chave pública inferior ou igual a 4096. Isso inclui certificados usados para autenticação de tokens, criptografia de tokens e descriptografia de tokens.

No Windows, o tamanho da chave pública de um certificado pode ser verificado abrindo o arquivo de certificado (.CER), selecionando a guia “Detalhes” e verificando o valor do campo “Chave pública”. Os certificados que usam o algoritmo de assinatura seguro sha256RSA terão uma chave pública de 2048 bits.

Os eventuais certificados existentes que tenham um tamanho de chave superior a 4096 bits continuarão a funcionar com o ACS, mas não poderão ser salvos novamente no ACS até que sejam substituídos por um certificado compatível.

Uma pequena alteração no algoritmo de seleção de “chave primária” usado quando o ACS autentica um token usando um certificado X.509

No portal de gerenciamento e no serviço de gerenciamento do ACS, há um campo “Tornar Primário” para certificados de autenticação de tokens que, quando selecionado, faz com que o ACS autentique tokens que usam esse certificado. Com esta versão, se nenhum certificado de autenticação de tokens configurado tiver o campo “Tornar Primário” selecionado, o Namespace do Access Control usará o certificado de autenticação de tokens não primário existente com a data de início válida mais antiga para autenticar o token. O ACS continua não autenticando tokens com um certificado de autenticação de tokens não primário se um certificado primário existir, mas for inválido ou tiver vencido.

JWT Beta: alteração no comportamento de autenticação ao usar um certificado ou chave de namespace global para autenticar um token JWT

Quando o suporte beta para o formato JSON Web Token (JWT) foi lançado em junho de 2012, o ACS usava a seguinte ordem de precedência para determinar qual chave deveria ser usada para autenticar cada token JWT emitido para cada aplicativo de terceira parte confiável:

  • Chave de autenticação simétrica atribuída à terceira parte confiável, se estiver disponível

  • Certificado de autenticação X.509 atribuído à terceira parte confiável, se estiver disponível

  • Chave de autenticação simétrica atribuída ao Namespace do Access Control

  • Certificado de autenticação X.509 atribuído ao Namespace do Access Control

A partir dessa versão, as chaves simétricas para todo o namespace não têm mais suporte para autenticação de tokens JWT. Veja abaixo a nova ordem de precedência para autenticação de tokens JWT:

  • Chave de autenticação simétrica atribuída à terceira parte confiável, se estiver disponível

  • Certificado de autenticação X.509 atribuído à terceira parte confiável, se estiver disponível

  • Certificado de autenticação X.509 atribuído ao Namespace do Access Control

Em junho de 2012, o ACS recebeu uma atualização que continha o seguinte recurso novo:

O formato JWT agora está disponível para aplicativos de terceiras partes confiáveis (Beta)

Essa atualização introduz suporte para o formato BETA de JSON Web Token (JWT) no ACS. O JWT é um formato de token leve codificado por JSON que pode ser autenticado usando-se uma chave simétrica ou um certificado X.509, e pode ser emitido pelo ACS para aplicativos de terceiras partes confiáveis por meio de qualquer um dos seguintes protocolos:

  • OAuth 2.0

  • WS-Federation

  • Web Services Trust

Agora, o formato de token JWT é uma opção selecionável na seção Aplicativos de Terceiras Partes Confiáveis do Portal de Gerenciamento do ACS e também pode ser configurado por meio do Serviço de Gerenciamento ACS.

Para saber mais sobre o formato de token JWT, consulte a Especificação JSON Web Token. As amostras de código do ACS que apresentam tokens JWT estarão disponíveis em uma data futura.

ImportantImportante
O suporte a JWT é marcado como “Beta” no ACS, o que significa que todos os detalhes da implementação do JWT estão sujeitos a alterações. Os desenvolvedores são incentivados a experimentar esse formato de token. No entanto, o JWT não deve ser usado em serviços de produção, uma vez que o seu comportamento pode mudar sem aviso prévio.

No início de maio de 2012, o ACS recebeu uma atualização contendo as seguintes alterações:

Alterações nas propriedades de ID de entidade expostas por meio do serviço de gerenciamento

O Serviço de Gerenciamento do ACS expõe atualmente uma propriedade de ID para cada um dos tipos de entidade aos quais dá suporte, conforme descrito no Referência de API de Serviço de Gerenciamento ACS. Essas propriedades de ID são automaticamente definidas e gerenciadas pelo ACS.

Nesta atualização de serviço, o ACS está sendo migrado para um esquema de banco de dados diferente, e como resultado, essas IDs expostas por meio do serviço de gerenciamento sofrerão alterações para todos os tipos de entidade.

Não é comum, e geralmente não é recomendado, que os aplicativos armazenem ou assumam uma dependência de código dessas IDs a fim de consultar entidades específicas por meio do serviço de gerenciamento. Em vez disso, recomenda-se a consulta dos tipos de entidade RelyingParty, ServiceIdentity, RuleGroup e Issuer usando-se a propriedade Name, e a consulta de outros tipos de entidade usando-se uma ID de entidade pai (por exemplo, RuleGroupId no caso de regras ou IssuerId no caso de provedores de identidade).

Alterações no agrupamento de banco de dados para processamento de regras

Para expandir o suporte para idiomas internacionais e melhorar a segurança, esta versão do ACS atualiza o agrupamento de banco de dados SQL subjacente usado para comparar declarações de entrada de SQL_Latin1_General_CP1_CI_AS para Latin1_General_100_BIN2. Essa alteração permite que o ACS suporte conjuntos de caracteres adicionais e combinações de conjuntos de caracteres adicionais. Os aplicativos que dependem de declarações de entrada contendo cadeias de caracteres com vários conjuntos de caracteres, que não têm suporte do SQL_Latin1_General_CP1_CI_AS, poderão ver declarações diferentes ou adicionais como resultado desse novo agrupamento. Os clientes que desejam aproveitar esse novo recurso são incentivados a validar seus aplicativos para compatibilidade com o novo agrupamento SQL.

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

Na versão anterior, o ACS respondia com códigos de erro diferentes quando um cliente se autenticava com um emissor não existente (código de erro: ACS50026) ou credenciais incorretas (código de erro: ACS50006). Esses códigos de erro eram emitidos anteriormente quando um cliente tentava se autenticar usando um nome de identidade de serviço inválido ou usando um token SWT ou SAML emitido por um provedor de identidade inválido.

O ACS retornará os códigos de erro ACS50008, ACS50009 ou ACS50012 para uma autenticação com falha nos casos de SWT, SAML e nome de usuário/senha, respectivamente. Consulte a tabela abaixo para obter detalhes:

 

Resposta de autenticação Antes Depois

Emissor não existente

ACS50026 IssuerNotFound

ACS50008 InvalidSwt,

ACS50009 InvalidSaml, OU

ACS50012 AuthenticationFailed

Credenciais incorretas

ACS50006 InvalidSignature

Ainda na versão anterior, o ACS respondia com códigos de erro diferentes do OAuth 2.0 quando um cliente se autenticava com um emissor não existente (invalid_client) ou credenciais incorretas (invalid_grant). Esse comportamento também foi atualizado, e o ACS retornará invalid_request quando a solicitação do OAuth 2.0 for malformada, invalid_client se o cliente não passar na autenticação ou a asserção fornecida para a autenticação for malformada ou inválida, e invalid_grant se o código de autorização for malformado ou inválido. Consulte a tabela abaixo para obter detalhes:

 

Resposta de autenticação Exemplos Antes Depois

Emissor não existente

invalid_client

invalid_client

Credenciais incorretas

O SWT é autenticado com uma chave incorreta. A ID e as credenciais do cliente correspondem às configuradas no ACS.

invalid_grant

A autenticação falhou

Falha na validação da URI de audiência. Falha na validação do certificado. A asserção de uma Identidade de Serviço contém declarações autoemitidas.

invalid_grant

Asserção malformada

A assinatura não está presente no SWT. A asserção SAML não é um XML válido.

invalid_request

Código de autorização malformado

invalid_grant

invalid_grant

Código de autorização inválido

invalid_grant

Solicitação OAuth2 malformada

invalid_request

invalid_request

As notas de versão da atualização de julho de 2011 do ACS 2.0 contém os seguintes itens:

Todos os Namespace do Access Controls recebem automaticamente a atualização de julho de 2011. Essa atualização não contém alterações dos pré-requisitos do ACS para clientes novos ou existentes. Para obter mais informações sobre os pré-requisitos atuais do ACS, consulte Pré-requisitos do ACS.

A atualização de julho de 2011 do ACS contém os seguintes recursos novos:

1. As regras agora admitem até duas declarações de entrada

O mecanismo de regras do ACS agora admite um novo tipo de regra que permite a configuração de até duas declarações de entrada, em vez de apenas uma declaração de entrada. As regras com duas declarações de entrada podem ser usadas para reduzir o número geral de regras exigidas para executar funções de autorização de usuário complexas.

No Portal de Gerenciamento do ACS, uma segunda declaração de entrada pode ser especificada em uma nova regra clicando-se em Adicionar uma segunda declaração de entrada no editor de regras. No serviço de gerenciamento, podem ser configuradas regras com duas declarações de entrada usando-se o tipo de entidade ConditionalRule. As regras com uma declaração de entrada ainda são configuradas usando-se o tipo de entidade Rule para compatibilidade com versões anteriores.

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

2. Localização em onze idiomas

O Portal de Gerenciamento do ACS e a página de logon hospedada pelo ACS para aplicativos de terceiras partes confiáveis agora oferecem suporte para localização em onze idiomas escritos, incluindo inglês, francês, alemão, italiano, japonês, coreano, russo, espanhol, português (Brasil), chinês simplificado e chinês tradicional. Uma opção de “Inglês (Internacional)” também está disponível e usa um formato de data alternativo para configuração e exibição de datas de entrada em vigor/expiração de chaves. O idioma escrito exibido para essas interfaces de usuário pode ser alterado de uma das três maneiras a seguir:

  • Seletor de Idioma – No Portal de Gerenciamento do ACS, o idioma exibido pode ser instantaneamente alterado usando-se um novo menu seletor de idioma que aparece no canto superior direito do portal.

  • URL – O idioma exibido no Portal de Gerenciamento do ACS pode ser alterado adicionando-se um parâmetro “lang” ao final da URL da solicitação. Os valores legais para esse parâmetro são os códigos de idioma ISO 639-1/3166 que correspondem a um idioma com suporte. Os exemplos de valores incluem en, de, es, fr, it, ja, ko, ru, pt-br, zh-cn e zh-tw. Veja abaixo um exemplo de URL do Portal de Gerenciamento do ACS com um parâmetro que configura o idioma exibido para francês:

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

  • Preferências de Navegador da Web – Se o parâmetro de URL “lang” ou o seletor de idioma nunca tiver sido usado para definir uma preferência de idioma, o Portal de Gerenciamento do ACS e as páginas de logon hospedadas pelo ACS determinarão o idioma padrão a ser exibido com base nas preferências de idioma definidas nas configurações do navegador da Web.

Veja a seguir algumas alterações notáveis de comportamento do serviço nessa versão:

1. Agora, a codificação é UTF-8 para todas as respostas do OAuth 2.0

Na versão inicial do ACS, a codificação de caracteres definida para todas as respostas HTTP do ponto de extremidade do OAuth 2.0 era US-ASCII. Na atualização de julho de 2011, a codificação de caracteres de todas as respostas HTTP é definida como UTF-8 a fim de dar suporte a conjuntos de caracteres estendidos.

Veja a seguir um problema conhecido dessa versão:

O editor de regras não pode exibir emissores personalizados que não estejam associados a provedores de identidade

Atualmente, o editor de regras no Portal de Gerenciamento do ACS pode exibir apenas emissores de declarações associados a um provedor de identidade ou ao ACS. Se for carregada uma regra que faça referência a um emissor que não corresponde a uma dessas opções, será exibido o erro a seguir:

  • ACS80001: Esta regra é configurada para usar um tipo de Emissor de declaração que não tem suporte do portal de gerenciamento. Por favor use o serviço de gerenciamento para ver e editar esta regra.

Há dois cenários admitidos nos quais um emissor pode existir sem um provedor de identidade associado no ACS:

  • Em um cenário de delegação do OAuth 2.0, um registro emissor é criado no Namespace do Access Control usando-se o Serviço de Gerenciamento do ACS, e esse emissor não está associado a um provedor de identidade.

  • Quando um emissor é criado com a finalidade de fazer declarações em uma solicitação de token por meio do protocolo OAuth WRAP, enquanto usa uma identidade de serviço com o mesmo nome para se autenticar com o ACS.

A partir dessa versão, o ACS não impõe limites ao número de provedores de identidade, aplicativos de terceiras partes confiáveis, grupos de regras, regras, identidades de serviço, tipos de declaração, registros de delegação, emissores, chaves e endereços que podem ser criados para um determinado Namespace do Access Control.

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

Contribuições da comunidade

ADICIONAR
Mostrar:
© 2015 Microsoft