Notas de versão

Atualizado em: 19 de junho de 2015

Aplica-se ao Azure

Este tópico descreve os novos recursos em cada versão do Microsoft Azure Active Directory Controle de Acesso (também conhecido como serviço de Controle de Acesso ou ACS), explica como cada versão do produto difere de seus antecessores e realça as alterações significativas que podem afetar o código gravado anteriormente Lançamento.

• Março de 2015 – migrar Namespaces do ACS para OpenID Connect do Google

• Junho de 2014 – Suporte do provedor de identidade do Google

• Notas de versão de atualização de julho de 2013

• Notas de versão de atualização de dezembro de 2012

• Notas de versão de atualização de setembro de 2012

• Notas de versão de atualização de junho de 2012

• Notas de versão de atualização de maio de 2012

• Notas de versão de atualização de janeiro de 2012

• Notas sobre a versão da atualização de julho de 2011

Março de 2015 – migrar Namespaces do ACS para OpenID Connect do Google

ACS implementou um recurso para ajudar os proprietários do namespace ACS a migrar suas configurações de provedor de identidade do Google do OpenID 2.0 para OpenID Connect. Os clientes terão até 1º de junho de 2015 para migrar os namespaces do ACS para OpenID Connect e até 1 de janeiro de 2017 para migrar seu código de back-end para usar identificadores OpenID Connect. Falha ao executar a ação apropriada antes de cada prazo fará com que os aplicativos sejam interrompidos. Para obter diretrizes detalhadas, consulte Migrar namespaces acs para o Google OpenID Conexão.

Junho de 2014 – Suporte do provedor de identidade do Google

Desde 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á desativando o suporte para o OpenID 2.0, do qual o ACS depende, e já não aceita o registro de novos aplicativos. Os namespaces acs existentes que usaram o Google continuarão funcionando até 20 de abril de 2015. Se o aplicativo exigir suporte para contas do Google, recomendamos que você registre seu aplicativo diretamente com elas.

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

Notas de versão de atualização de julho de 2013

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 algum namespace exceder esse limite por um período prolongado, o ACS rejeitará as solicitações de token do namespace durante o período e retornará um erro HTTP 429 / ACS90055 "Excesso de solicitações". Para obter mais informações, consulte limitações de serviço acs e códigos de erro ACS.

Notas de versão de atualização de dezembro de 2012

Novos recursos

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

Suporte a logout único federado usando o protocolo WS-Federation

Aplicativos Web que usam o ACS para habilitar o SSO (logon único) com provedores de identidade usando o protocolo WS-Federation agora podem aproveitar os recursos de logon único. Quando um usuário sai de um aplicativo Web, o ACS pode desconectar automaticamente o usuário do provedor de identidade e de outros aplicativos de terceira parte confiável que usam o mesmo provedor de identidade.

Esse recurso é habilitado para provedores de identidade WS-Federation, incluindo Serviços de Federação do Active Directory (AD FS) 2.0 e Windows Live ID (conta microsoft). Para habilitar a saída única, o ACS executa as seguintes tarefas para WS-Federation pontos de extremidade de protocolo:

• O ACS reconhece mensagens wsignoutcleanup1.0 de provedores de identidade e responde enviando mensagens wsignoutcleanup1.0 para aplicativos de terceira parte confiável.

• O ACS reconhece o wsignout1.0 e as mensagens profundas de aplicativos de terceira parte confiável e responde enviando mensagens wsignout1.0 para provedores de identidade e mensagens wsignoutcleanup1.0 para aplicativos de terceira parte confiável.

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

Suporte descontinuado do ACS 1.0

O suporte do Access Control Service 1.0 foi descontinuado nesta versão, incluindo o suporte à migração do Access Control Service 1.0 para o Access Control Service 2.0.

Navegar até Controle de Acesso namespaces no novo Portal de Gerenciamento do Azure

O novo Portal de Gerenciamento do Azure (https://manage.WindowsAzure.com) inclui uma rota para o portal familiar de Gerenciamento do ACS, no qual você cria e gerencia Controle de Acesso namespaces.

Para navegar até o Portal de Gerenciamento ACS:

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

2. Clique em um namespace Controle de Acesso e 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 Controle de Acesso para um barramento de serviço

Quando você cria um namespace Barramento de Serviço no, o portal cria automaticamente um namespace Controle de Acesso para o barramento de serviço.

Para configurar e gerenciar o namespace Controle de Acesso para um barramento de serviço:

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

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

3. Clique em Tecla de Acesso e em Abrir Portal de Gerenciamento ACS.

Para verificar se o namespace Controle de Acesso está associado ao barramento de serviço, consulte o campo Namespace de Serviço na parte superior da página serviço Controle de Acesso. O nome do namespace consiste no nome do barramento de serviço com um sufixo "-sb".

Para obter mais informações, consulte Como gerenciar o namespace Controle de Acesso para um Barramento de Serviço.

Aprimoramentos do Portal de Gerenciamento ACS para exibição de chaves do provedor de identidade de WS-Federation, ocultando senhas

Esta versão contém um par de aprimoramentos relacionado à exibição e ao trabalho com certificados, chaves e senhas no Portal de Gerenciamento ACS 2.0:

• Os certificados de autenticação agora ficam visíveis na seção Editar Provedor de Identidade do WS-Federation – anteriormente, os certificados importados de metadados de WS-Federation usados para validar a assinatura de tokens emitidos por esse provedor de identidade não ficavam visíveis no Portal de Gerenciamento ACS. Agora a seção Editar Provedor de Identidade do WS-Federation exibe informações sobre certificados importados, inclusive as datas de vencimento e o status. Esses certificados agora podem ser atualizados através de uma nova caixa de seleção “Reimportar dados da URL de metadados do WS-Federation ao salvar”.

• Senhas e chaves de autenticação simétricas agora ficam ocultas por padrão – para evitar a divulgação acidental de senhas e chaves simétricas, esses valores agora ficam ocultos por padrão nas telas Editar de todo o portal. Para exibir o valor de uma senha ou chave simétrica intencionalmente (por exemplo, para copiá-las para um aplicativo), pressione o botão “Mostrar Senha” ou “Mostrar Código”.

Capacidade de federar locatários de diretório com namespaces de Controle de Acesso

Azure Active Directory locatários agora podem ser usados como provedores de identidade em namespaces Controle de Acesso. Isso permite que muitos cenários, como permitir que seu aplicativo Web aceite identidades organizacionais de locatários de diretório e identidades de consumidor de provedores sociais como Facebook, Google, Yahoo!, contas da Microsoft ou qualquer outro provedor OpenID. Você pode encontrar instruções detalhadas sobre como implementar o cenário nesta postagem, provisionando um locatário Azure Active Directory como um provedor de identidade em um namespace acs.

Suporte ao protocolo SAML 2.0 para aplicativos de terceira parte confiável (visualização do desenvolvedor)

Agora o ACS aceita o protocolo SAML 2.0 para a emissão de tokens para aplicativos de terceira parte confiável. O suporte ao protocolo SAML 2.0 foi lançado como uma visualização do desenvolvedor. Isso significa que os detalhes da implementação do protocolo SAML 2.0 ainda estão sujeitos a alteração. Para obter mais detalhes, consultea Versão Prévia do Desenvolvedor: SAMLProtocol.

Problemas Conhecidos

Em dezembro de 2012, Microsoft Azure Active Directory Controle de Acesso (também conhecido como Controle de Acesso Service ou ACS), os seguintes problemas conhecidos foram identificados:

O Co-Administrators do Azure agora pode gerenciar namespaces Controle de Acesso. No entanto, uma ação é necessária para propagar coadministradores pré-existentes para um namespace de Controle 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 primário do Azure poderia gerenciar Controle de Acesso namespaces criados na assinatura. Se um coadministrador do Azure tentasse acessar o Portal de Gerenciamento do ACS para um namespace Controle de Acesso, eles receberiam um dos seguintes códigos de erro do ACS:

• ACS50000: erro ao emitir um token.

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

• ACS60001: nenhuma declaração de saída foi gerada durante o processamento de regras.

Esse problema agora é resolvido para novos namespaces de Controle de Acesso criados por qualquer administrador ou coadministrador de serviços do Azure. Entretanto, os clientes com namespaces que existiam antes da correção precisam realizar os seguintes procedimentos para que os dados do coadministrador possam ser propagados para esses namespaces:

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

2. Remova e adicione novamente o coadministrador usando as diretrizes em Como adicionar e remover Co-Administrators para suas assinaturas do Azure (https://msdn.microsoft.com/library/windowsazure/gg456328.aspx)

3. Saia e entre no Portal do Azure usando as credenciais de coadministrador. Em seguida, você poderá gerenciar os namespaces Controle de Acesso.

Notas de versão de atualização de setembro de 2012

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

O atributo entityID publicado nos metadados do WS-Federation emitidos pelo ACS agora usam letras minúsculas constantemente

O atributo "entityID" no WS-Federation metadados publicados por namespaces Controle de Acesso agora é sempre minúsculo. Em versões anteriores, a letra podia ser minúscula ou maiúscula, de acordo com o que era inserido na criação do namespace no portal do Azure. O atributo "entityID" identifica o namespace Controle de Acesso para aplicativos de terceira parte confiável e abaixo está 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 foi necessária para resolver possíveis problemas de validação de token em que o caso de letra do namespace Controle de Acesso no token emitido pelo ACS (que sempre é minúscula) não corresponde ao caso de letra do namespace Controle de Acesso importado pela terceira parte confiável. As terceiras partes confiáveis que utilizam o Windows Identity Foundation não são afetadas pelos problemas de diferenciação de maiúscula/minúscula.

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

Todos os certificados X.509 carregados em um namespace Controle de Acesso por meio do portal de gerenciamento do ACS ou do serviço de gerenciamento agora são necessários para ter um tamanho de chave pública que não seja maior que 4096 bits. Isso inclui os certificados usados para autenticação, criptografia e descriptografia de token.

No Windows, para verificar o tamanho da chave pública de um certificado, você abre o arquivo do certificado (.CER), seleciona a guia “Detalhes” e verifica o valor no campo “Chave pública”. Os certificados que usam o algoritmo de assinatura seguro sha256RSA terão uma chave pública de 2048 bits.

Todo certificado que tenha uma chave com mais de 4096 bits continuará funcionando com o ACS, porém, não poderão ser salvos novamente no ACS até serem substituídos por um certificado compatível.

Pequena alteração no algoritmo de seleção da “chave primária” usado quando o ACS assina um token com um certificado X.509

No portal e no serviço de gerenciamento ACS, existe um campo “Tornar Principal” para os certificados de autenticação de tokens que, quando selecionado, faz com que o ACS assine tokens usando esse certificado. Com essa versão, se nenhum certificado de assinatura de token configurado tiver o campo "Tornar Primário" marcado, o namespace Controle de Acesso usará o certificado de assinatura de token não primário existente que tem a data de início válida mais antiga para assinar o token. O ACS continua não assinando tokens com um certificado de autenticação de tokens não principal se houver um certificado principal, porém inválido ou vencido.

JWT Beta: alterar o comportamento de assinatura ao usar um certificado ou chave de namespace global para assinar um token JWT

Quando o suporte à versão beta para o formato do token Web JSON (JWT) foi lançado em junho de 2012, o ACS adotou a seguinte ordem de precedência para determinar qual chave seria usada para assinar cada token JWT emitido para cada aplicativo de terceira parte confiável:

• Chave de assinatura simétrica atribuída à terceira parte confiável (se disponível)

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

• Chave de assinatura simétrica atribuída ao namespace Controle de Acesso

• Certificado de autenticação X.509 atribuído ao namespace Controle de Acesso

Nesta versão, as chaves simétricas para namespaces já não são aceitas para tokens de autenticação JWT. Veja abaixo a nova ordem de precedência dos tokens de autenticação JWT:

• Chave de assinatura simétrica atribuída à terceira parte confiável (se disponível)

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

• Certificado de autenticação X.509 atribuído ao namespace Controle de Acesso

Notas de versão de atualização de junho de 2012

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

O formato JWT agora está disponível para aplicativos de terceira parte confiável (beta)

Essa atualização apresenta suporte para o formato BETA do JWT (Token Web JSON) no ACS. O JWT é um formato de token leve codificado em JSON que pode ser assinado usando um certificado X.509 ou uma chave simétrica e pode ser emitido pelo ACS para aplicativos de terceira parte confiável em qualquer um dos seguintes protocolos:

• OAuth 2.0

• O certificado do provedor de identidade do Web Services Federation

• WS-Trust

O formato de token JWT agora é uma opção selecionável na seção Aplicativos de Terceira Parte Confiável do Portal de Gerenciamento do ACS e também é configurável por meio do Serviço de Gerenciamento do ACS.

Para saber mais sobre o formato de token JWT, consulte a especificação do Token Web JSON. Exemplos de código do ACS que têm tokens JWT serão lançados no futuro.

Notas de versão de atualização de maio de 2012

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

Alterações nas propriedades ID da entidade expostas via serviço de gerenciamento

Atualmente, o Serviço de Gerenciamento do ACS expõe uma propriedade de ID para cada um dos tipos de entidade compatíveis, conforme descrito na Referência da API do Serviço de Gerenciamento do 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 serão alteradas para todos os tipos de entidade.

Não é comum, e em geral não é recomendável, que os aplicativos armazenem ou dependam excessivamente dessas IDs para consultar determinadas entidades por meio do serviço de gerenciamento. Em vez disso, é recomendável que os tipos de entidade RelyingParty, ServiceIdentity, RuleGroup e Issuer sejam consultados usando a propriedade Name, e que outros tipos de entidade seja consultados com uma ID de entidade pai (por exemplo, RuleGroupId no caso de regras ou IssuerId no caso de provedores de identidade).

Alterações na ordenação de bancos de dados para o processamento de regras

Para expandir o suporte para idiomas internacionais e melhorar a segurança, essa versão do ACS atualiza a ordenação de banco de dados SQL subjacente usada para comparar declarações de entrada de SQL_Latin1_General_CP1_CI_AS com Latin1_General_100_BIN2. Essa alteração permite que o ACS dê suporte a conjuntos de caracteres adicionais e combinações de conjuntos de caracteres. Os aplicativos que utilizam declarações de entrada que contêm cadeias de caracteres com vários conjuntos de caracteres, sem o suporte de SQL_Latin1_General_CP1_CI_AS, podem ver solicitações diferentes ou adicionais como resultado dessa nova ordenação. Os clientes que quiserem utilizar esse novo recurso devem validar seus aplicativos para garantir compatibilidade com a nova ordenação SQL.

Notas de versão de atualização de janeiro de 2012

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

• Alteração nas respostas de erro do ACS para solicitações de autenticação com falha

• Alteração nos códigos de erro do OAuth 2.0 para solicitações de autenticação com falha

Alteração nas respostas de erro do ACS para solicitações de autenticação com falha

Na versão anterior, o ACS respondia com códigos de erro diferentes quando um cliente era autenticado com um emissor inexistente (código de erro: ACS50026) ou credenciais incorretas (código de erro: ACS50006). Esses códigos de erro eram anteriormente emitidos quando um cliente tentava autenticar usando um nome inválido de identidade de serviço ou 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 ver detalhes:

Alteração nos códigos de erro do OAuth 2.0 para solicitações de autenticação com falha

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

Notas sobre a versão da atualização de julho de 2011

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

• Pré-requisitos

• Novos recursos

• Alterações

• Problemas conhecidos

• Problemas conhecidos

Pré-requisitos

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

Novos recursos

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

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

O mecanismo de regras acs agora dá suporte a um novo tipo de regra que permite que até duas declarações de entrada sejam configuradas, 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 necessárias 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 em Adicionar uma segunda declaração de entrada no editor de regras. No serviço de gerenciamento, as regras com duas declarações de entrada podem ser configuradas com o tipo de entidade ConditionalRule. As regras com uma declaração de entrada ainda são configuradas com o tipo de entidade Rule para manter a compatibilidade com versões anteriores.

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

2. Tradução em onze idiomas

O Portal de Gerenciamento do ACS e a página de logon hospedado pelo ACS para aplicativos de terceira parte confiável agora dão suporte à 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. Há uma opção “Inglês (internacional)” disponível que usa um formato de data alternativo para configurar e exibir datas de efetivação/expiração de chaves. O idioma escrito exibido nessas interfaces de usuário pode ser alterado de uma destas três formas:

• Seletor de Idiomas – No Portal de Gerenciamento do ACS, o idioma exibido pode ser alterado instantaneamente usando 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 um parâmetro "lang" ao final da URL de solicitação. Os valores permitidos para esse parâmetro são os códigos de idioma ISO 639-1/3166 que correspondem a um idioma compatível. Os exemplos desses 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 definindo o idioma exibido como francês:

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

• Preferências do 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.

Alterações

Estas são alterações notáveis no comportamento do serviço nesta versão:

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

Na versão inicial do ACS, o conjunto de codificação de caracteres para todas as respostas HTTP do ponto de extremidade OAuth 2.0 foi US-ASCII. Na atualização de julho de 2011, a codificação de caracteres de todas as respostas HTTP ficou configurada como UTF-8 para suporte a conjuntos de caracteres estendidos.

Problemas conhecidos

Este é um problema conhecido nesta versão:

o editor de regras não exibe os emissores personalizados que não estão associados aos provedores de identidade

Atualmente, o editor de regras no Portal de Gerenciamento do ACS só pode exibir emissores de declaração associados a um provedor de identidade ou ACS. Se uma regra carregada fizer referência a um emissor que não corresponde a qualquer um desses itens, o seguinte erro será exibido:

• ACS80001: essa regra é configurada para usar um tipo emissor de declaração que não tem suporte no portal de gerenciamento. Use o serviço de gerenciamento para exibir e editar esta regra.

Há dois cenários com suporte em que 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 do emissor é criado no namespace Controle de Acesso usando o Serviço de Gerenciamento do ACS e esse emissor não tem um provedor de identidade associado.

• Quando um emissor é criado com a finalidade de declarar declarações em uma solicitação de token pelo protocolo OAuth WRAP, ao mesmo tempo em que usa uma identidade de serviço nomeada de forma idêntica para autenticar com ACS.

Cotas

A partir desta versão, o ACS não impõe limites ao número de provedores de identidade, aplicativos de terceira parte confiável, 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 Controle de Acesso.

Limitações de serviços

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