Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aviso
Este conteúdo é destinado ao endpoint antigo do Azure AD v1.0. Use a plataforma de identidade da Microsoft para obter novos projetos.
O ACS (Serviço de Controle de Acesso do Microsoft Azure), um serviço do Azure AD (Azure Active Directory), será desativado em 7 de novembro de 2018. Aplicativos e serviços que atualmente usam o Controle de Acesso devem ser totalmente migrados para um mecanismo de autenticação diferente até lá. Este artigo descreve as recomendações para os clientes atuais, pois você planeja preterir o uso do Controle de Acesso. Se você não usar o Controle de Acesso no momento, não precisará executar nenhuma ação.
Visão geral
O Controle de Acesso é um serviço de autenticação de nuvem que oferece uma maneira fácil de autenticar e autorizar usuários para acesso aos seus aplicativos e serviços Web. Ele permite que muitos recursos de autenticação e autorização sejam considerados fora do seu código. O Controle de Acesso é usado principalmente por desenvolvedores e arquitetos de clientes do Microsoft .NET, ASP.NET aplicativos Web e serviços Web do Windows Communication Foundation (WCF).
Os casos de uso do Controle de Acesso podem ser divididos em três categorias principais:
- Autenticação em determinados serviços de nuvem da Microsoft, incluindo o Barramento de Serviço do Azure e o Dynamics CRM. Os aplicativos cliente obtêm tokens do Controle de Acesso para autenticar nesses serviços para executar várias ações.
- Adicionando autenticação a aplicativos Web, personalizados e pré-empacotados (como o SharePoint). Usando a autenticação "passiva" do Controle de Acesso, os aplicativos Web podem dar suporte à entrada com uma conta da Microsoft (anteriormente Live ID) e com contas do Google, Facebook, Yahoo, Azure AD e Serviços de Federação do Active Directory (AD FS).
- Protegendo serviços Web personalizados com tokens emitidos pelo Controle de Acesso. Usando a autenticação "ativa", os serviços Web podem garantir que eles permitam o acesso somente a clientes conhecidos que se autenticaram com o Controle de Acesso.
Cada um desses casos de uso e suas estratégias de migração recomendadas são discutidos nas seções a seguir.
Aviso
Na maioria dos casos, alterações significativas de código são necessárias para migrar aplicativos e serviços existentes para tecnologias mais recentes. Recomendamos que você comece imediatamente a planejar e executar sua migração para evitar possíveis interrupções ou tempo de inatividade.
O Controle de Acesso tem os seguintes componentes:
- Um STS (serviço de token seguro), que recebe solicitações de autenticação e emite tokens de segurança em troca.
- O portal clássico do Azure, no qual você cria, exclui e habilita e desabilitar namespaces do Controle de Acesso.
- Um portal de gerenciamento de Controle de Acesso separado, em que você personaliza e configura namespaces do Controle de Acesso.
- Um serviço de gerenciamento, que você pode usar para automatizar as funções dos portais.
- Um mecanismo de regra de transformação de token, que você pode usar para definir uma lógica complexa para manipular o formato de saída de tokens que o Controle de Acesso emite.
Para usar esses componentes, você deve criar um ou mais namespaces do Controle de Acesso. Um namespace é uma instância dedicada do Controle de Acesso com a qual seus aplicativos e serviços se comunicam. Um namespace é isolado de todos os outros clientes do Controle de Acesso. Outros clientes do Controle de Acesso usam seus próprios namespaces. Um namespace no Controle de Acesso tem uma URL dedicada semelhante a esta:
https://<mynamespace>.accesscontrol.windows.net
Toda a comunicação com o STS e as operações de gerenciamento são feitas nessa URL. Você usa caminhos diferentes para diferentes finalidades. Para determinar se seus aplicativos ou serviços usam o Controle de Acesso, monitore qualquer tráfego para https://<namespace>.accesscontrol.windows.net. Qualquer tráfego para essa URL é tratado pelo Controle de Acesso e precisa ser descontinuado.
A exceção a isso é qualquer tráfego para https://accounts.accesscontrol.windows.net. O tráfego para essa URL já é tratado por um serviço diferente e não é afetado pela descontinuação do Controle de Acesso.
Para obter mais informações sobre o Controle de Acesso, consulte o Serviço de Controle de Acesso 2.0 (arquivado).
Descobrir quais dos seus aplicativos serão afetados
Siga as etapas nesta seção para descobrir quais dos seus aplicativos serão afetados pela desativação do ACS.
Baixar e instalar o ACS PowerShell
Instalar o módulo executando
Install-Module -Name Acs.NamespacesObter uma lista de todos os comandos possíveis executando
Get-Command -Module Acs.NamespacesPara obter ajuda em um comando específico, execute:
Get-Help [Command-Name] -Fullonde
[Command-Name]é o nome do comando ACS.
Listar os namespaces do ACS
Conecte-se ao ACS usando o cmdlet Connect-AcsAccount.
Talvez seja necessário executar
Set-ExecutionPolicy -ExecutionPolicy Bypassantes de executar comandos e ser o administrador dessas assinaturas para executar os comandos.Liste suas assinaturas disponíveis do Azure usando Get-AcsSubscription do cmdlet.
Liste seus namespaces do ACS usando o cmdlet Get-AcsNamespace.
Verificar quais aplicativos serão afetados
Usar o namespace da etapa anterior e ir para
https://<namespace>.accesscontrol.windows.netPor exemplo, se um dos namespaces for contoso-test, vá para
https://contoso-test.accesscontrol.windows.netEm relações de confiança, selecione aplicativos de terceira parte confiável para ver a lista de aplicativos que serão afetados pela desativação do ACS.
Repita as etapas 1 a 2 para qualquer outro namespace do ACS que você tenha.
Agenda de Aposentadoria
A partir de novembro de 2017, todos os componentes do Controle de Acesso têm suporte total e estão operacionais. A única restrição é que você não pode criar novos namespaces do Controle de Acesso por meio do portal clássico do Azure.
Aqui está o agendamento para a substituição de componentes do Controle de Acesso:
-
Novembro de 2017: A experiência de administrador do Azure AD no portal clássico do Azure foi desativada. Neste ponto, o gerenciamento de namespace para Controle de Acesso está disponível em uma URL nova e dedicada:
https://manage.windowsazure.com?restoreClassic=true. Use essa URL para exibir seus namespaces existentes, habilitar e desabilitar namespaces e excluir namespaces, se preferir. -
2 de abril de 2018: O portal clássico do Azure está completamente desativado, o que significa que o gerenciamento de namespace do Controle de Acesso não está mais disponível por meio de qualquer URL. Neste ponto, você não pode desabilitar ou habilitar, excluir ou enumerar seus namespaces do Controle de Acesso. No entanto, o portal de gerenciamento do Controle de Acesso será totalmente funcional e localizado em
https://<namespace>.accesscontrol.windows.net. Todos os outros componentes do Controle de Acesso continuam operando normalmente. -
7 de novembro de 2018: todos os componentes do Controle de Acesso são desligados permanentemente. Isso inclui o portal de gerenciamento do Controle de Acesso, o serviço de gerenciamento, o STS e o motor de regras de transformação de token. Neste ponto, todas as solicitações enviadas ao Controle de Acesso (localizadas em
<namespace>.accesscontrol.windows.net) falharão. Você deve ter migrado todos os aplicativos e serviços existentes para outras tecnologias antes desse momento.
Observação
Uma política desabilita namespaces que não solicitaram um token por um período de tempo. A partir do início de setembro de 2018, esse período está atualmente em 14 dias de inatividade, mas isso será reduzido para 7 dias de inatividade nas próximas semanas. Se você tiver namespaces de Controle de Acesso desabilitados no momento, poderá baixar e instalar o ACS PowerShell para habilitar novamente os namespaces.
Estratégias de migração
As seções a seguir descrevem recomendações de alto nível para migrar do Controle de Acesso para outras tecnologias da Microsoft.
Clientes de serviços de nuvem da Microsoft
Cada serviço de nuvem da Microsoft que aceita tokens emitidos pelo Controle de Acesso agora dá suporte a pelo menos uma forma alternativa de autenticação. O mecanismo de autenticação correto varia para cada serviço. Recomendamos que você consulte a documentação específica para cada serviço para obter diretrizes oficiais. Para conveniência, cada conjunto de documentação é fornecido aqui:
| Serviço | Orientação |
|---|---|
| Azure Service Bus | Migrar para assinaturas de acesso compartilhado |
| Retransmissão do Barramento de Serviço do Azure | Migrar para assinaturas de acesso compartilhado |
| Cache Gerenciado do Azure | Migrar para o Azure Cache para Redis |
| Azure DataMarket | Migrar para as APIs de serviços de IA do Azure |
| Serviços BizTalk | Migrar para o recurso Aplicativos Lógicos do Serviço de Aplicativo do Azure |
| Serviços de Mídia do Azure | Migrar para a autenticação do Azure AD |
| Serviço de Backup do Azure | Atualizar o agente de Backup do Azure |
Clientes do SharePoint
Os clientes do SharePoint 2013, 2016 e SharePoint Online há muito usaram o ACS para fins de autenticação em cenários de nuvem, locais e híbridos. Alguns recursos do SharePoint e casos de uso serão afetados pela desativação do ACS, enquanto outros não. A tabela abaixo resume as diretrizes de migração para alguns dos recursos mais populares do SharePoint que aproveitam o ACS:
| Característica | Orientação |
|---|---|
| Autenticando usuários do Azure AD | Anteriormente, o Azure AD não era compatível com tokens SAML 1.1 exigidos pelo SharePoint para autenticação e o ACS era usado como um intermediário que tornava o SharePoint compatível com formatos de token do Azure AD. Agora, você pode conectar o SharePoint diretamente ao Azure AD usando o aplicativo do SharePoint local da Galeria de Aplicativos do Azure AD. |
| Autenticação de aplicativo e autenticação de servidor para servidor no SharePoint local | Não afetado pela desativação do ACS; nenhuma alteração necessária. |
| Autorização de baixa confiança para complementos do SharePoint (provedor hospedado e hospedado pelo SharePoint) | Não afetado pela desativação do ACS; nenhuma alteração necessária. |
| Pesquisa híbrida na nuvem do SharePoint | Não afetado pela desativação do ACS; nenhuma alteração necessária. |
Aplicativos Web que usam autenticação passiva
Para aplicações web que usam o Controle de Acesso para autenticação de usuário, o Controle de Acesso oferece as seguintes características e capacidades para desenvolvedores e arquitetos de aplicações web:
- Integração profunda com o Windows Identity Foundation (WIF).
- Federação com contas do Google, Facebook, Yahoo, Azure Active Directory e AD FS e contas da Microsoft.
- Suporte para os seguintes protocolos de autenticação: OAuth 2.0 Draft 13, WS-Trust e Web Services Federation (WS-Federation).
- Suporte para os seguintes formatos de token: JWT (Token Web JSON), SAML 1.1, SAML 2.0 e SWT (Token Web Simples).
- Uma experiência de descoberta de domínio, integrada ao WIF (Framework de Identidade do Windows), que permite aos usuários escolher o tipo de conta que usam para fazer login. Essa experiência é hospedada pelo aplicativo Web e é totalmente personalizável.
- Transformação de token que permite a personalização avançada das declarações recebidas pelo aplicativo Web do Controle de Acesso, incluindo:
- Passe as declarações de provedores de identidade.
- Adicionando declarações personalizadas adicionais.
- Lógica simples if-then para emitir declarações em determinadas condições.
Infelizmente, não há um serviço que ofereça todas essas funcionalidades equivalentes. Você deve avaliar quais recursos do Controle de Acesso você precisa e escolher entre usar a ID do Microsoft Entra, o Azure Active Directory B2C (Azure AD B2C) ou outro serviço de autenticação de nuvem.
Migrar para a ID do Microsoft Entra
Um caminho a ser considerado é integrar seus aplicativos e serviços diretamente à ID do Microsoft Entra. O Microsoft Entra ID é o provedor de identidade baseado em nuvem para contas corporativas ou de estudante da Microsoft. O Microsoft Entra ID é o provedor de identidade do Microsoft 365, do Azure e muito mais. Ele fornece recursos de autenticação federados semelhantes ao Controle de Acesso, mas não dá suporte a todos os recursos do Controle de Acesso.
O exemplo principal é a federação com provedores de identidade social, como Facebook, Google e Yahoo. Se os usuários entrarem com esses tipos de credenciais, a ID do Microsoft Entra não será a solução para você.
A ID do Microsoft Entra também não dá suporte necessariamente aos mesmos protocolos de autenticação que o Controle de Acesso. Por exemplo, embora o Controle de Acesso e a ID do Microsoft Entra ofereçam suporte ao OAuth, há diferenças sutis entre cada implementação. Diferentes implementações exigem que você modifique o código como parte de uma migração.
No entanto, a ID do Microsoft Entra fornece várias vantagens potenciais para os clientes do Controle de Acesso. Ele dá suporte nativo a contas corporativas ou de estudante da Microsoft hospedadas na nuvem, que geralmente são usadas pelos clientes do Controle de Acesso.
Um tenant do Microsoft Entra também pode ser federado a uma ou mais instâncias do Active Directory local via AD FS. Dessa forma, seu aplicativo pode autenticar usuários e usuários baseados em nuvem hospedados no local. Ele também dá suporte ao protocolo WS-Federation, o que torna relativamente simples a integração com um aplicativo Web usando WIF.
A tabela a seguir compara os recursos do Controle de Acesso relevantes para aplicativos Web com os recursos disponíveis na ID do Microsoft Entra.
Em um alto nível, a ID do Microsoft Entra é provavelmente a melhor opção para sua migração se você permitir que os usuários entrem apenas com suas contas corporativas ou de estudante da Microsoft.
| Capacidade | Suporte ao Controle de Acesso | Suporte para Microsoft Entra ID |
|---|---|---|
| Tipos de contas | ||
| Contas corporativas ou de estudante da Microsoft | Suportado | Suportado |
| Contas do Windows Server Active Directory e do AD FS | – Com suporte por meio de federação com um locatário do Microsoft Entra – Suportado por federação direta com o AD FS |
Com suporte apenas por meio de federação com um cliente do Microsoft Entra |
| Contas de outros sistemas de gerenciamento de identidade empresarial | - Possível por meio de federação com um tenant do Microsoft Entra – Com suporte por meio da federação direta |
Possível por meio de federação com um tenant do Microsoft Entra |
| Contas da Microsoft para uso pessoal | Suportado | Com suporte por meio do protocolo OAuth do Microsoft Entra v2.0, mas não em nenhum outro protocolo |
| Contas do Facebook, Google, Yahoo | Suportado | Não há suporte nenhum |
| Protocolos e compatibilidade do SDK | ||
| WIF | Suportado | Há suporte, mas há instruções limitadas disponíveis |
| WS-Federation | Suportado | Suportado |
| OAuth 2.0 | Suporte para o Rascunho 13 | Suporte para RFC 6749, a especificação mais moderna |
| WS-Trust | Suportado | Sem suporte |
| Formatos de token | ||
| JWT | Suporte disponível no Beta | Suportado |
| SAML 1.1 | Suportado | Versão prévia |
| SAML 2.0 | Suportado | Suportado |
| SWT | Suportado | Sem suporte |
| Personalizações | ||
| Descoberta de domínio doméstico personalizável/IU de seleção de conta | Código baixável que pode ser incorporado em aplicativos | Sem suporte |
| Carregar certificados personalizados de assinatura de token | Suportado | Suportado |
| Personalizar declarações em tokens | Passar as declarações recebidas de provedores de identidade – Obter o token de acesso do provedor de identidade como uma reivindicação - Emitir declarações de saída com base em valores de declarações de entrada - Emitir declarações de saída com valores constantes |
- Não é possível transmitir declarações de provedores de identidade federados - Não é possível obter o token de acesso do provedor de identidade como uma declaração - Não é possível emitir declarações de saída com base em valores de declarações de entrada - Pode emitir declarações de saída com valores constantes - Pode emitir declarações de saída com base nas propriedades dos usuários sincronizados com o Microsoft Entra ID |
| Automação | ||
| Automatizar tarefas de configuração e gerenciamento | Com suporte por meio do Serviço de Gerenciamento de Controle de Acesso | Com suporte usando a API do Microsoft Graph |
Se você decidir que a ID do Microsoft Entra é o melhor caminho de migração para seus aplicativos e serviços, você deve estar ciente de duas maneiras de integrar seu aplicativo à ID do Microsoft Entra.
Para usar WS-Federation ou WIF para integrar com o Microsoft Entra ID, recomendamos seguir a abordagem descrita em Configurar logon único federado para um aplicativo que não seja da galeria. O artigo refere-se à configuração do Microsoft Entra ID para autenticação única baseada em SAML, mas também pode ser usado para configurar o WS-Federation. Seguir essa abordagem requer uma licença Microsoft Entra ID P1 ou P2. Essa abordagem tem duas vantagens:
- Você obtém toda a flexibilidade da personalização do token do Microsoft Entra. Você pode personalizar as declarações emitidas pela ID do Microsoft Entra para corresponder às declarações emitidas pelo Controle de Acesso. Isso inclui especialmente a ID do usuário ou a declaração do Name Identifier. Para continuar a receber identificadores de usuário consistentes após alterar as tecnologias, assegure que os IDs de usuário emitidos pelo Microsoft Entra ID correspondam aos emitidos pelo Controle de Acesso.
- Você pode configurar um certificado de assinatura de token específico ao seu aplicativo e com um tempo de vida que você controla.
Observação
Essa abordagem requer licença Microsoft Entra ID P1 ou P2. Se você for um cliente do Controle de Acesso e precisar de uma licença premium para configurar o logon único para um aplicativo, entre em contato conosco. Teremos o prazer de fornecer licenças de desenvolvedor para você usar.
Uma abordagem alternativa é seguir este exemplo de código, que fornece instruções ligeiramente diferentes para configurar o WS-Federation. Este exemplo de código não usa WIF, mas sim o middleware OWIN ASP.NET 4.5. No entanto, as instruções para o registro de aplicativo são válidas para aplicativos que usam WIF e não exigem uma licença P1 ou P2 do Microsoft Entra.
Se você escolher essa abordagem, precisará entender a substituição de chave de assinatura no Microsoft Entra ID. Essa abordagem usa a chave de assinatura global do Microsoft Entra para emitir tokens. Por padrão, o WIF não atualiza automaticamente as chaves de assinatura. Quando o Microsoft Entra ID rotaciona suas chaves de assinatura globais, sua implementação do WIF precisa estar preparada para aceitar as alterações. Para obter mais informações, consulte Informações importantes sobre a substituição de chave de assinatura na ID do Microsoft Entra.
Se você puder se integrar à ID do Microsoft Entra por meio dos protocolos OpenID Connect ou OAuth, recomendamos fazer isso. Temos ampla documentação e diretrizes sobre como integrar a ID do Microsoft Entra ao seu aplicativo Web disponível em nosso guia de desenvolvedor do Microsoft Entra.
Migrar para o Azure Active Directory B2C
O outro caminho de migração a ser considerado é o Azure AD B2C. O Azure AD B2C é um serviço de autenticação de nuvem que, como o Controle de Acesso, permite aos desenvolvedores terceirizar sua lógica de autenticação e gerenciamento de identidade para um serviço de nuvem. É um serviço pago (com camadas gratuitas e premium) projetado para aplicativos voltados para o consumidor que podem ter até milhões de usuários ativos.
Assim como o Controle de Acesso, um dos recursos mais atraentes do Azure AD B2C é que ele dá suporte a muitos tipos diferentes de contas. Com o Azure AD B2C, você pode conectar usuários usando sua conta da Microsoft ou contas do Facebook, Google, LinkedIn, GitHub ou Yahoo e muito mais. O Azure AD B2C também dá suporte a "contas locais" ou nome de usuário e senhas que os usuários criam especificamente para seu aplicativo. O Azure AD B2C também fornece extensibilidade avançada que você pode usar para personalizar seus fluxos de entrada.
No entanto, o Azure AD B2C não dá suporte à amplitude de protocolos de autenticação e formatos de token que os clientes do Controle de Acesso podem exigir. Você também não pode usar o Azure AD B2C para obter tokens e consultar informações adicionais sobre o usuário do provedor de identidade, Microsoft ou de outra forma.
A tabela a seguir compara os recursos do Controle de Acesso relevantes para aplicativos Web com aqueles que estão disponíveis no Azure AD B2C. Em um alto nível, o Azure AD B2C provavelmente será a escolha certa para sua migração se o aplicativo estiver voltado para o consumidor ou se ele oferecer suporte a muitos tipos diferentes de contas.
| Capacidade | Suporte ao Controle de Acesso | Suporte ao Azure AD B2C |
|---|---|---|
| Tipos de contas | ||
| Contas corporativas ou de estudante da Microsoft | Suportado | Com suporte por meio de políticas personalizadas |
| Contas do Windows Server Active Directory e do AD FS | Compatível por meio da federação direta com o AD FS | Com suporte por meio da federação SAML usando políticas personalizadas |
| Contas de outros sistemas de gerenciamento de identidade empresarial | Com suporte por meio de federação direta por meio de WS-Federation | Com suporte por meio da federação SAML usando políticas personalizadas |
| Contas da Microsoft para uso pessoal | Suportado | Suportado |
| Contas do Facebook, Google, Yahoo | Suportado | O Facebook e o Google têm suporte nativo, o Yahoo tem suporte por meio da federação OpenID Connect usando políticas personalizadas |
| Protocolos e compatibilidade do SDK | ||
| Windows Identity Foundation (WIF) | Suportado | Sem suporte |
| WS-Federation | Suportado | Sem suporte |
| OAuth 2.0 | Suporte para o Rascunho 13 | Suporte para RFC 6749, a especificação mais moderna |
| WS-Trust | Suportado | Sem suporte |
| Formatos de token | ||
| JWT | Com suporte em Beta | Suportado |
| SAML 1.1 | Suportado | Sem suporte |
| SAML 2.0 | Suportado | Sem suporte |
| SWT | Suportado | Sem suporte |
| Personalizações | ||
| UI personalizável para descoberta de realm doméstico/seleção de conta | Código baixável que pode ser incorporado em aplicativos | Interface do usuário totalmente personalizável por meio do CSS personalizado |
| Carregar certificados personalizados de assinatura de token | Suportado | Chaves de assinatura personalizadas, não certificados, com suporte por meio de políticas personalizadas |
| Personalizar declarações em tokens | - Encaminhar declarações de entrada de provedores de identidade – Obter o token de acesso do provedor de identidade como uma declaração - Emitir declarações de saída com base em valores de declarações de entrada - Emitir declarações de saída com valores constantes |
- Pode passar declarações de provedores de identidade; políticas personalizadas necessárias para algumas declarações - Não é possível obter o token de acesso do provedor de identidade como uma declaração - Pode emitir declarações de saída com base em valores de declarações de entrada por meio de políticas personalizadas - Pode emitir declarações de saída com valores constantes por meio de políticas personalizadas |
| Automação | ||
| Automatizar tarefas de configuração e gerenciamento | Com suporte por meio do Serviço de Gerenciamento de Controle de Acesso | – Criação de usuários permitidos usando a API do Microsoft Graph - Não é possível criar locatários, aplicativos ou políticas B2C programaticamente |
Se você decidir que o Azure AD B2C é o melhor caminho de migração para seus aplicativos e serviços, comece com os seguintes recursos:
Migrar para Ping Identity ou Auth0
Em alguns casos, você pode descobrir que a ID do Microsoft Entra e o Azure AD B2C não são suficientes para substituir o Controle de Acesso em seus aplicativos Web sem fazer grandes alterações de código. Alguns exemplos comuns podem incluir:
- Aplicativos Web que usam WIF ou WS-Federation para entrar com provedores de identidade social, como Google ou Facebook.
- Aplicativos Web que executam a federação direta para um provedor de identidade empresarial por meio do protocolo WS-Federation.
- Aplicativos Web que exigem o token de acesso emitido por um provedor de identidade social (como Google ou Facebook) como uma declaração nos tokens emitidos pelo Controle de Acesso.
- Aplicativos Web com regras complexas de transformação de tokens que o Microsoft Entra ID ou o Azure AD B2C não conseguem reproduzir.
- Aplicativos Web multilocatários que usam o ACS para gerenciar centralmente a federação para muitos provedores de identidade diferentes
Nesses casos, talvez você queira considerar a migração do aplicativo Web para outro serviço de autenticação de nuvem. Recomendamos explorar as opções a seguir. Cada uma das opções a seguir oferece funcionalidades semelhantes ao Controle de Acesso:
O Auth0 é um serviço de identidade de nuvem flexível que criou diretrizes de migração de alto nível para clientes do Controle de Acesso e dá suporte a quase todos os recursos que o ACS faz.
O Ping Identity oferece duas soluções semelhantes ao ACS. PingOne é um serviço de identidade de nuvem que dá suporte a muitos dos mesmos recursos que o ACS, e o PingFederate é um produto de identidade local semelhante que oferece mais flexibilidade. Consulte as orientações para desativação do ACS do Ping para obter mais detalhes sobre a utilização desses produtos.
Nosso objetivo em trabalhar com o Ping Identity e o Auth0 é garantir que todos os clientes do Controle de Acesso tenham um caminho de migração para seus aplicativos e serviços que minimizem a quantidade de trabalho necessária para migrar do Controle de Acesso.
Serviços Web que usam autenticação ativa
Para serviços Web protegidos com tokens emitidos pelo Controle de Acesso, o Controle de Acesso oferece os seguintes recursos e capacidades:
- Capacidade de registrar uma ou mais identidades de serviço no namespace do Controle de Acesso. As identidades de serviço podem ser usadas para solicitar tokens.
- Suporte para os protocolos OAuth WRAP e OAuth 2.0 Draft 13 para solicitar tokens usando os seguintes tipos de credenciais:
- Uma senha simples criada para a identidade do serviço
- Um SWT assinado usando uma chave simétrica ou um certificado X509
- Um token SAML emitido por um provedor de identidade confiável (normalmente, uma instância do AD FS)
- Suporte para os seguintes formatos de token: JWT, SAML 1.1, SAML 2.0 e SWT.
- Regras de transformação de token simples.
As identidades de serviço no Controle de Acesso normalmente são usadas para implementar a autenticação de servidor para servidor.
Migrar para a ID do Microsoft Entra
Nossa recomendação para esse tipo de fluxo de autenticação é migrar para a ID do Microsoft Entra. O Microsoft Entra ID é o provedor de identidade baseado em nuvem para contas corporativas ou de estudante da Microsoft. O Microsoft Entra ID é o provedor de identidade do Microsoft 365, do Azure e muito mais.
Você também pode usar a ID do Microsoft Entra para autenticação servidor a servidor usando a implementação do Microsoft Entra da concessão de credenciais do cliente OAuth. A tabela a seguir compara os recursos do Controle de Acesso na autenticação servidor a servidor com aqueles que estão disponíveis na ID do Microsoft Entra.
| Capacidade | Suporte ao Controle de Acesso | Suporte para Microsoft Entra ID |
|---|---|---|
| Como registrar um serviço Web | Criar uma parte confiável no portal de gerenciamento do Controle de Acesso | Criar um aplicativo Web do Microsoft Entra no portal do Azure |
| Como registrar um cliente | Criar uma identidade de serviço no portal de gerenciamento do Controle de Acesso | Criar outro aplicativo Web do Microsoft Entra no portal do Azure |
| Protocolo usado | – Protocolo WRAP OAuth – Concessão de credenciais de cliente do Draft 13 do OAuth 2.0 |
Concessão de credenciais de cliente do OAuth 2.0 |
| Métodos de autenticação do cliente | - Senha simples - SWT assinado - Token SAML de um provedor de identidade federado |
- Senha simples - JWT assinado |
| Formatos de Token | - JWT - SAML 1.1 - SAML 2.0 - SWT |
Somente JWT |
| Transformação de token | - Adicionar declarações personalizadas – Lógica de emissão de declaração simples if-then |
Adicionar declarações personalizadas |
| Automatizar tarefas de configuração e gerenciamento | Com suporte por meio do Serviço de Gerenciamento de Controle de Acesso | Com suporte usando a API do Microsoft Graph |
Para obter diretrizes sobre como implementar cenários de servidor para servidor, consulte os seguintes recursos:
- Seção Serviço-a-Serviço do guia do desenvolvedor do Microsoft Entra
- Exemplo de código daemon usando credenciais de cliente de senha simples
- Exemplo de código daemon usando credenciais de cliente de certificado
Migrar para Ping Identity ou Auth0
Em alguns casos, você pode descobrir que as credenciais do cliente do Microsoft Entra e a implementação de concessão OAuth não são suficientes para substituir o Controle de Acesso em sua arquitetura sem grandes alterações de código. Alguns exemplos comuns podem incluir:
- Autenticação de servidor para servidor usando formatos de token diferentes de JWTs.
- Autenticação de servidor para servidor usando um token de entrada fornecido por um provedor de identidade externo.
- Autenticação de servidor para servidor com regras de transformação de token que a ID do Microsoft Entra não pode reproduzir.
Nesses casos, você pode considerar migrar seu aplicativo Web para outro serviço de autenticação de nuvem. Recomendamos explorar as opções a seguir. Cada uma das opções a seguir oferece funcionalidades semelhantes ao Controle de Acesso:
O Auth0 é um serviço de identidade de nuvem flexível que criou diretrizes de migração de alto nível para clientes do Controle de Acesso e dá suporte a quase todos os recursos que o ACS faz.
Ping Identity oferece duas soluções semelhantes ao ACS. PingOne é um serviço de identidade de nuvem que dá suporte a muitos dos mesmos recursos que o ACS, e o PingFederate é um produto de identidade local semelhante que oferece mais flexibilidade. Consulte as diretrizes de aposentadoria do ACS da Ping para mais detalhes sobre o uso desses produtos.
Nosso objetivo em trabalhar com o Ping Identity e o Auth0 é garantir que todos os clientes do Controle de Acesso tenham um caminho de migração para seus aplicativos e serviços que minimizem a quantidade de trabalho necessária para migrar do Controle de Acesso.
Autenticação direta
Para autenticação de passagem com transformação arbitrária de token, não há tecnologia equivalente da Microsoft para ACS. Se for disso que seus clientes precisam, o Auth0 pode ser aquele que fornece a solução de aproximação mais próxima.
Perguntas, preocupações e comentários
Entendemos que muitos clientes do Controle de Acesso não encontrarão um caminho de migração claro depois de ler este artigo. Talvez você precise de alguma assistência ou orientação para determinar o plano certo. Se você quiser discutir seus cenários de migração e perguntas, deixe um comentário nesta página.