Como: Migrar a partir do Serviço Controlo de Acesso do Azure
Aviso
Este conteúdo destina-se ao ponto final Azure AD v1.0 mais antigo. Utilize o plataforma de identidades da Microsoft para novos projetos.
O Serviço de Controlo de Acesso do Microsoft Azure (ACS), um serviço do Azure Active Directory (Azure AD), será descontinuado a 7 de novembro de 2018. As aplicações e os serviços que utilizam atualmente Controlo de Acesso têm de ser totalmente migrados para um mecanismo de autenticação diferente até lá. Este artigo descreve recomendações para os clientes atuais, uma vez que planeia descontinuar a sua utilização de Controlo de Acesso. Se atualmente não utilizar Controlo de Acesso, não precisa de efetuar qualquer ação.
Descrição Geral
Controlo de Acesso é um serviço de autenticação na cloud que oferece uma forma fácil de autenticar e autorizar utilizadores para aceder às suas aplicações e serviços Web. Permite que muitas funcionalidades de autenticação e autorização sejam tidas em conta no seu código. Controlo de Acesso é utilizada principalmente por programadores e arquitetos de clientes .NET da Microsoft, ASP.NET aplicações Web e serviços Web do Windows Communication Foundation (WCF).
Os casos de utilização de Controlo de Acesso podem ser divididos em três categorias principais:
- Autenticação em determinados serviços cloud da Microsoft, incluindo Azure Service Bus e Dynamics CRM. As aplicações cliente obtêm tokens de Controlo de Acesso para se autenticarem nestes serviços para efetuar várias ações.
- Adicionar autenticação a aplicações Web, personalizadas e pré-embaladas (como o SharePoint). Ao utilizar Controlo de Acesso autenticação "passiva", as aplicações Web podem suportar o início de sessão com uma conta Microsoft (anteriormente Live ID) e com contas da Google, Facebook, Yahoo, Azure AD e Serviços de Federação do Active Directory (AD FS) (AD FS).
- Proteger serviços Web personalizados com tokens emitidos por Controlo de Acesso. Ao utilizar a autenticação "ativa", os serviços Web podem garantir que permitem o acesso apenas a clientes conhecidos que tenham sido autenticados com Controlo de Acesso.
Cada um destes casos de utilização e as respetivas estratégias de migração recomendadas são abordados nas secções seguintes.
Aviso
Na maioria dos casos, são necessárias alterações significativas ao código para migrar aplicações e serviços existentes para tecnologias mais recentes. Recomendamos que comece imediatamente a planear e executar a migração para evitar eventuais interrupções ou períodos de indisponibilidade.
Controlo de Acesso tem os seguintes componentes:
- Um serviço de token seguro (STS), que recebe pedidos de autenticação e emite tokens de segurança em troca.
- O portal clássico do Azure, onde cria, elimina e ativa e desativa Controlo de Acesso espaços de nomes.
- Um portal de gestão de Controlo de Acesso separado, onde personaliza e configura Controlo de Acesso espaços de nomes.
- Um serviço de gestão, que pode utilizar para automatizar as funções dos portais.
- Um motor de regra de transformação de tokens, que pode utilizar para definir lógica complexa para manipular o formato de saída dos tokens que Controlo de Acesso problemas.
Para utilizar estes componentes, tem de criar um ou mais espaços de nomes Controlo de Acesso. Um espaço de nomes é uma instância dedicada de Controlo de Acesso com que as suas aplicações e serviços comunicam. Um espaço de nomes é isolado de todos os outros clientes Controlo de Acesso. Outros Controlo de Acesso clientes utilizam os seus próprios espaços de nomes. Um espaço de nomes no Controlo de Acesso tem um URL dedicado semelhante ao seguinte:
https://<mynamespace>.accesscontrol.windows.net
Todas as comunicações com o STS e as operações de gestão são efetuadas neste URL. Pode utilizar caminhos diferentes para diferentes fins. Para determinar se as suas aplicações ou serviços utilizam Controlo de Acesso, monitorize qualquer tráfego para https://< namespace.accesscontrol.windows.net>. Qualquer tráfego para este URL é processado por Controlo de Acesso e tem de ser descontinuado.
A exceção a isto é qualquer tráfego para https://accounts.accesscontrol.windows.net. O tráfego para este URL já é processado por um serviço diferente e não é afetado pela preterição do Controlo de Acesso.
Para obter mais informações sobre Controlo de Acesso, consulte Controlo de Acesso Service 2.0 (arquivado).
Descubra quais das suas aplicações serão afetadas
Siga os passos nesta secção para saber quais das suas aplicações serão afetadas pela descontinuação do ACS.
Transferir e instalar o ACS PowerShell
Aceda ao Galeria do PowerShell e transfira Acs.Namespaces.
Instalar o módulo ao executar
Install-Module -Name Acs.NamespacesObter uma lista de todos os comandos possíveis ao executar
Get-Command -Module Acs.NamespacesPara obter ajuda sobre um comando específico, execute:
Get-Help [Command-Name] -Fullem que
[Command-Name]é o nome do comando ACS.
Listar os espaços de nomes ACS
Ligue-se ao ACS com o cmdlet Connect-AcsAccount .
Poderá ter de executar
Set-ExecutionPolicy -ExecutionPolicy Bypassantes de poder executar comandos e ser o administrador dessas subscrições para executar os comandos.Liste as subscrições do Azure disponíveis com o cmdlet Get-AcsSubscription .
Liste os espaços de nomes ACS com o cmdlet Get-AcsNamespace .
Verificar que aplicações serão afetadas
Utilize o espaço de nomes do passo anterior e aceda a
https://<namespace>.accesscontrol.windows.netPor exemplo, se um dos espaços de nomes for contoso-test, aceda a
https://contoso-test.accesscontrol.windows.netEm Relações de confiança, selecione Aplicações de entidade confiadoras para ver a lista de aplicações que serão afetadas pela descontinuação do ACS.
Repita os passos 1 a 2 para quaisquer outros espaços de nomes ACS que tenha.
Agenda de descontinuação
A partir de novembro de 2017, todos os componentes Controlo de Acesso são totalmente suportados e operacionais. A única restrição é que não pode criar novos espaços de nomes Controlo de Acesso através do portal clássico do Azure.
Eis a agenda para preterir componentes Controlo de Acesso:
- Novembro de 2017: A experiência de administrador Azure AD no portal clássico do Azure foi descontinuada. Neste momento, a gestão do espaço de nomes para Controlo de Acesso está disponível num NOVO URL dedicado:
https://manage.windowsazure.com?restoreClassic=true. Utilize este URL para ver os espaços de nomes existentes, ativar e desativar espaços de nomes e eliminar espaços de nomes, se assim o preferir. - 2 de abril de 2018: O portal clássico do Azure está completamente descontinuado, o que significa que Controlo de Acesso gestão de espaços de nomes já não está disponível através de qualquer URL. Neste momento, não pode desativar, ativar, eliminar ou enumerar os seus espaços de nomes Controlo de Acesso. No entanto, o portal de gestão do Controlo de Acesso estará totalmente funcional e localizado em
https://<namespace>.accesscontrol.windows.net. Todos os outros componentes do Controlo de Acesso continuam a funcionar normalmente. - 7 de novembro de 2018: Todos os componentes Controlo de Acesso são encerrados permanentemente. Isto inclui o portal de gestão de Controlo de Acesso, o serviço de gestão, STS e o motor de regra de transformação de tokens. Neste momento, todos os pedidos enviados para Controlo de Acesso (localizados em
<namespace>.accesscontrol.windows.net) falham. Deverá ter migrado todas as aplicações e serviços existentes para outras tecnologias muito antes desta altura.
Nota
Uma política desativa espaços de nomes que não tenham pedido um token durante um período de tempo. A partir do início de setembro de 2018, este período de tempo é atualmente de 14 dias de inatividade, mas este será reduzido para 7 dias de inatividade nas próximas semanas. Se tiver Controlo de Acesso espaços de nomes que estão atualmente desativados, pode transferir e instalar o ACS PowerShell para reativar os espaços de nomes.
Estratégias de migração
As secções seguintes descrevem recomendações de alto nível para migrar de Controlo de Acesso para outras tecnologias da Microsoft.
Clientes dos serviços cloud da Microsoft
Cada serviço cloud da Microsoft que aceite tokens emitidos pelo Controlo de Acesso agora suporta, pelo menos, uma forma alternativa de autenticação. O mecanismo de autenticação correto varia para cada serviço. Recomendamos que consulte a documentação específica para cada serviço para obter orientações oficiais. Para conveniência, cada conjunto de documentação é fornecido aqui:
| Serviço | Orientação |
|---|---|
| Service Bus do Azure | Migrar para assinaturas de acesso partilhado |
| Reencaminhamento de Azure Service Bus | Migrar para assinaturas de acesso partilhado |
| Cache Gerida do Azure | Migrar para a Cache do Azure para Redis |
| Azure DataMarket | Migrar para as APIs dos serviços de IA do Azure |
| Serviços BizTalk | Migrar para a funcionalidade Logic Apps do Serviço de Aplicações do Azure |
| Serviços de Multimédia do Azure | Migrar para a autenticação Azure AD |
| Azure Backup | Atualizar o agente do Azure Backup |
Clientes do SharePoint
Os clientes do SharePoint 2013, 2016 e SharePoint Online há muito que utilizam ACS para fins de autenticação na cloud, no local e em cenários híbridos. Algumas funcionalidades e casos de utilização do SharePoint serão afetados pela descontinuação do ACS, enquanto outros não. A tabela abaixo resume as orientações de migração para algumas das funcionalidades mais populares do SharePoint que tiram partido do ACS:
| Funcionalidade | Orientação |
|---|---|
| Autenticar utilizadores a partir de Azure AD | Anteriormente, Azure AD não suportava tokens SAML 1.1 exigidos pelo SharePoint para autenticação e ACS era utilizado como um intermediário que tornava o SharePoint compatível com formatos de token Azure AD. Agora, pode ligar o SharePoint diretamente a Azure AD com Azure AD aplicação SharePoint na Galeria de Aplicações no local. |
| Autenticação de aplicações & autenticação servidor a servidor no SharePoint no local | Não afetado pela descontinuação do ACS; não são necessárias alterações. |
| Autorização de confiança baixa para suplementos do SharePoint (alojados pelo fornecedor e alojados no SharePoint) | Não afetado pela descontinuação do ACS; não são necessárias alterações. |
| Pesquisa híbrida na cloud do SharePoint | Não afetado pela descontinuação do ACS; não são necessárias alterações. |
Aplicações Web que utilizam autenticação passiva
Para aplicações Web que utilizam Controlo de Acesso para autenticação de utilizadores, Controlo de Acesso fornece as seguintes funcionalidades e capacidades para programadores e arquitetos de aplicações Web:
- Integração profunda com o Windows Identity Foundation (WIF).
- Federação com contas Google, Facebook, Yahoo, Azure Active Directory e AD FS e contas Microsoft.
- Suporte para os seguintes protocolos de autenticação: OAuth 2.0 Draft 13, WS-Trust e Federação de Serviços Web (WS-Federation).
- Suporte para os seguintes formatos de token: JSON Web Token (JWT), SAML 1.1, SAML 2.0 e Simple Web Token (SWT).
- Uma experiência de deteção de domínios domésticos, integrada na WIF, que permite aos utilizadores escolher o tipo de conta que utilizam para iniciar sessão. Esta experiência é alojada pela aplicação Web e é totalmente personalizável.
- Transformação de tokens que permite a personalização avançada das afirmações recebidas pela aplicação Web de Controlo de Acesso, incluindo:
- Transmitir afirmações de fornecedores de identidade.
- Adicionar afirmações personalizadas adicionais.
- Lógica if-then simples para emitir afirmações em determinadas condições.
Infelizmente, não existe nenhum serviço que ofereça todas estas capacidades equivalentes. Deve avaliar que capacidades de Controlo de Acesso precisa e, em seguida, escolher entre utilizar Microsoft Entra ID, Azure Active Directory B2C (Azure AD B2C) ou outro serviço de autenticação na cloud.
Migrar para Microsoft Entra ID
Um caminho a considerar é integrar as suas aplicações e serviços diretamente com Microsoft Entra ID. Microsoft Entra ID é o fornecedor de identidades baseado na cloud para contas escolares ou profissionais da Microsoft. Microsoft Entra ID é o fornecedor de identidade do Microsoft 365, do Azure e muito mais. Fornece capacidades de autenticação federadas semelhantes para Controlo de Acesso, mas não suporta todas as funcionalidades de Controlo de Acesso.
O exemplo principal é a federação com fornecedores de identidade social, como Facebook, Google e Yahoo. Se os seus utilizadores iniciarem sessão com estes tipos de credenciais, Microsoft Entra ID não é a solução para si.
Microsoft Entra ID também não suporta necessariamente os mesmos protocolos de autenticação que Controlo de Acesso. Por exemplo, embora Controlo de Acesso e Microsoft Entra ID suportem OAuth, existem diferenças subtis entre cada implementação. As diferentes implementações exigem que modifique o código como parte de uma migração.
No entanto, Microsoft Entra ID fornece várias vantagens potenciais para Controlo de Acesso clientes. Suporta nativamente contas escolares ou profissionais da Microsoft alojadas na cloud, que são normalmente utilizadas por clientes Controlo de Acesso.
Um inquilino Microsoft Entra também pode ser federado numa ou mais instâncias de Active Directory no local através do AD FS. Desta forma, a sua aplicação pode autenticar utilizadores e utilizadores baseados na cloud alojados no local. Também suporta o protocolo WS-Federation, o que torna relativamente simples a integração com uma aplicação Web através da WIF.
A tabela seguinte compara as funcionalidades de Controlo de Acesso que são relevantes para as aplicações Web com as funcionalidades disponíveis no Microsoft Entra ID.
A um nível elevado, Microsoft Entra ID é provavelmente a melhor opção para a sua migração se permitir que os utilizadores iniciem sessão apenas com as respetivas contas escolares ou profissionais da Microsoft.
| Funcionalidade | Controlo de Acesso suporte | suporte de ID de Microsoft Entra |
|---|---|---|
| Tipos de contas | ||
| Contas escolares ou profissionais da Microsoft | Suportado | Suportado |
| Contas do Windows Server Active Directory e do AD FS | - Suportado através da federação com um inquilino Microsoft Entra - Suportado através da federação direta com o AD FS |
Apenas suportado através da federação com um inquilino Microsoft Entra |
| Contas de outros sistemas de gestão de identidades empresariais | - Possível através da federação com um inquilino Microsoft Entra - Suportado através da federação direta |
Possível através da federação com um inquilino Microsoft Entra |
| Contas Microsoft para utilização pessoal | Suportado | Suportado através do protocolo OAuth Microsoft Entra v2.0, mas não através de outros protocolos |
| Facebook, Google, contas Yahoo | Suportado | Não suportado de forma alguma |
| Protocolos e compatibilidade com o SDK | ||
| WIF | Suportado | Suportadas, mas estão disponíveis instruções limitadas |
| WS-Federation | Suportado | Suportado |
| OAuth 2.0 | Suporte para Rascunho 13 | Suporte para RFC 6749, a especificação mais moderna |
| WS-Trust | Suportado | Não suportado |
| Formatos de token | ||
| JWT | Suportado em Beta | Suportado |
| SAML 1.1 | Suportado | Pré-visualizar |
| SAML 2.0 | Suportado | Suportado |
| SWT | Suportado | Não suportado |
| Personalizações | ||
| Deteção de domínios domésticos personalizável/IU de recolha de contas | Código transferível que pode ser incorporado em aplicações | Não suportado |
| Carregar certificados de assinatura de tokens personalizados | Suportado | Suportado |
| Personalizar afirmações em tokens | - Transmitir afirmações de entrada de fornecedores de identidade - Obter o token de acesso do fornecedor de identidade como uma afirmação - Emitir afirmações de saída com base nos valores das afirmações de entrada - Emitir afirmações de saída com valores constantes |
- Não é possível transmitir afirmações de fornecedores de identidade federados - Não é possível obter o token de acesso do fornecedor de identidade como uma afirmação - Não é possível emitir afirmações de saída com base em valores de afirmações de entrada - Pode emitir afirmações de saída com valores constantes - Pode emitir afirmações de saída com base nas propriedades dos utilizadores sincronizados com Microsoft Entra ID |
| Automatização | ||
| Automatizar tarefas de configuração e gestão | Suportado através do Serviço de Gestão de Controlo de Acesso | Suportado com o Microsoft Graph API |
Se decidir que Microsoft Entra ID é o melhor caminho de migração para as suas aplicações e serviços, deve estar ciente de duas formas de integrar a sua aplicação com Microsoft Entra ID.
Para utilizar WS-Federation ou WIF para integrar com Microsoft Entra ID, recomendamos que siga a abordagem descrita em Configurar o início de sessão único federado para uma aplicação não galeria. O artigo refere-se à configuração de Microsoft Entra ID para o início de sessão único baseado em SAML, mas também funciona para configurar a WS-Federation. Seguir esta abordagem requer uma licença Microsoft Entra ID P1 ou P2. Esta abordagem tem duas vantagens:
- Obtém a flexibilidade total da personalização de tokens Microsoft Entra. Pode personalizar as afirmações emitidas por Microsoft Entra ID para corresponder às afirmações emitidas pelo Controlo de Acesso. Isto inclui especialmente a afirmação de ID de utilizador ou Identificador de Nome. Para continuar a receber IDentifiers de utilizador consistentes para os seus utilizadores depois de alterar as tecnologias, certifique-se de que os IDs de utilizador emitidos por Microsoft Entra ID correspondem aos emitidos pelo Controlo de Acesso.
- Pode configurar um certificado de assinatura de tokens específico da sua aplicação e com uma duração que controla.
Nota
Esta abordagem requer uma licença Microsoft Entra ID P1 ou P2. Se for um cliente Controlo de Acesso e precisar de uma licença premium para configurar o início de sessão único para uma aplicação, contacte-nos. Teremos todo o gosto em fornecer licenças de programador para que possa utilizar.
Uma abordagem alternativa é seguir este exemplo de código, que fornece instruções ligeiramente diferentes para configurar a WS-Federation. Este exemplo de código não utiliza WIF, mas sim o middleware OWIN ASP.NET 4.5. No entanto, as instruções para o registo de aplicações são válidas para aplicações que utilizam WIF e não requerem uma licença Microsoft Entra ID P1 ou P2.
Se escolher esta abordagem, terá de compreender o rollover da chave de assinatura no Microsoft Entra ID. Esta abordagem utiliza o Microsoft Entra chave de assinatura global para emitir tokens. Por predefinição, a WIF não atualiza automaticamente as chaves de assinatura. Quando Microsoft Entra ID roda as respetivas chaves de assinatura globais, a implementação wif tem de estar preparada para aceitar as alterações. Para obter mais informações, veja Informações importantes sobre o rollover da chave de assinatura no Microsoft Entra ID.
Se conseguir integrar com Microsoft Entra ID através dos protocolos OpenID Connect ou OAuth, recomendamos que o faça. Temos documentação extensa e documentação de orientação sobre como integrar Microsoft Entra ID na sua aplicação Web disponível no nosso guia para programadores Microsoft Entra.
Migrar para o Azure Active Directory B2C
O outro caminho de migração a considerar é Azure AD B2C. Azure AD B2C é um serviço de autenticação na cloud que, tal como Controlo de Acesso, permite aos programadores subcontratar a lógica de autenticação e gestão de identidades a um serviço cloud. É um serviço pago (com escalões gratuitos e premium) concebido para aplicações destinadas ao consumidor que podem ter até milhões de utilizadores ativos.
Tal como Controlo de Acesso, uma das funcionalidades mais apelativas do Azure AD B2C é o facto de suportar vários tipos de contas diferentes. Com Azure AD B2C, pode iniciar sessão de utilizadores com as respetivas contas Microsoft ou Facebook, Google, LinkedIn, GitHub ou Contas Yahoo e muito mais. Azure AD B2C também suporta "contas locais" ou nome de utilizador e palavras-passe que os utilizadores criam especificamente para a sua aplicação. Azure AD B2C também fornece extensibilidade avançada que pode utilizar para personalizar os fluxos de início de sessão.
No entanto, Azure AD B2C não suporta a amplitude dos protocolos de autenticação e formatos de token que os clientes Controlo de Acesso poderão necessitar. Também não pode utilizar Azure AD B2C para obter tokens e consultar para obter informações adicionais sobre o utilizador a partir do fornecedor de identidade, Microsoft ou de outra forma.
A tabela seguinte compara as funcionalidades de Controlo de Acesso relevantes para as aplicações Web com as que estão disponíveis no Azure AD B2C. A um nível elevado, Azure AD B2C é provavelmente a escolha certa para a sua migração se a sua aplicação estiver virada para o consumidor ou se suportar vários tipos de contas diferentes.
| Funcionalidade | Controlo de Acesso suporte | Azure AD suporte B2C |
|---|---|---|
| Tipos de contas | ||
| Contas escolares ou profissionais da Microsoft | Suportado | Suportado através de políticas personalizadas |
| Contas do Windows Server Active Directory e do AD FS | Suportado através da federação direta com o AD FS | Suportado através da federação SAML através de políticas personalizadas |
| Contas de outros sistemas de gestão de identidades empresariais | Suportado através da federação direta através de WS-Federation | Suportado através da federação SAML através de políticas personalizadas |
| Contas Microsoft para utilização pessoal | Suportado | Suportado |
| Facebook, Google, contas Yahoo | Suportado | Facebook e Google suportados nativamente, o Yahoo suportava através da federação do OpenID Connect através de políticas personalizadas |
| Protocolos e compatibilidade com o SDK | ||
| Windows Identity Foundation (WIF) | Suportado | Não suportado |
| WS-Federation | Suportado | Não suportado |
| OAuth 2.0 | Suporte para Rascunho 13 | Suporte para RFC 6749, a especificação mais moderna |
| WS-Trust | Suportado | Não suportado |
| Formatos de token | ||
| JWT | Suportado em Beta | Suportado |
| SAML 1.1 | Suportado | Não suportado |
| SAML 2.0 | Suportado | Não suportado |
| SWT | Suportado | Não suportado |
| Personalizações | ||
| Deteção de domínios domésticos personalizável/IU de recolha de contas | Código transferível que pode ser incorporado em aplicações | IU totalmente personalizável através do CSS personalizado |
| Carregar certificados de assinatura de tokens personalizados | Suportado | Chaves de assinatura personalizadas, não certificados, suportadas através de políticas personalizadas |
| Personalizar afirmações em tokens | - Transmitir afirmações de entrada de fornecedores de identidade - Obter o token de acesso do fornecedor de identidade como afirmação - Emitir afirmações de saída com base em valores de afirmações de entrada - Emitir afirmações de saída com valores constantes |
- Pode transmitir afirmações de fornecedores de identidade; políticas personalizadas necessárias para algumas afirmações - Não é possível obter o token de acesso do fornecedor de identidade como afirmação - Pode emitir afirmações de saída com base em valores de afirmações de entrada através de políticas personalizadas - Pode emitir afirmações de saída com valores constantes através de políticas personalizadas |
| Automatização | ||
| Automatizar tarefas de configuração e gestão | Suportado através do Serviço de Gestão de Controlo de Acesso | - Criação de utilizadores permitidos através do Microsoft Graph API - Não é possível criar inquilinos, aplicações ou políticas B2C programaticamente |
Se decidir que Azure AD B2C é o melhor caminho de migração para as suas aplicações e serviços, comece pelos seguintes recursos:
Migrar para a Identidade de Ping ou Autenticação0
Em alguns casos, poderá descobrir que Microsoft Entra ID e Azure AD B2C não são suficientes para substituir Controlo de Acesso nas suas aplicações Web sem fazer grandes alterações de código. Alguns exemplos comuns podem incluir:
- Aplicações Web que utilizam WIF ou WS-Federation para iniciar sessão com fornecedores de identidade social, como o Google ou Facebook.
- Aplicações Web que realizam a federação direta para um fornecedor de identidade empresarial através do protocolo WS-Federation.
- Aplicações Web que requerem o token de acesso emitido por um fornecedor de identidade social (como o Google ou Facebook) como uma afirmação nos tokens emitidos pelo Controlo de Acesso.
- As aplicações Web com regras de transformação de tokens complexas que Microsoft Entra ID ou Azure AD B2C não conseguem reproduzir.
- Aplicações Web multi-inquilino que utilizam ACS para gerir centralmente a federação para muitos fornecedores de identidade diferentes
Nestes casos, poderá querer considerar migrar a sua aplicação Web para outro serviço de autenticação na cloud. Recomendamos que explore as seguintes opções. Cada uma das seguintes opções oferece capacidades semelhantes às Controlo de Acesso:
O Auth0 é um serviço de identidade da cloud flexível que criou orientações de migração de alto nível para clientes de Controlo de Acesso e suporta quase todas as funcionalidades que o ACS faz.
O Ping Identity oferece duas soluções semelhantes à ACS. O PingOne é um serviço de identidade na cloud que suporta muitas das mesmas funcionalidades que o ACS e o PingFederate é um produto de identidade no local semelhante que oferece mais flexibilidade. Veja a documentação de orientação sobre a descontinuação do ACS do Ping para obter mais detalhes sobre como utilizar estes produtos.
O nosso objetivo em trabalhar com a Identidade e Autenticação de Ping é garantir que todos os Controlo de Acesso clientes têm um caminho de migração para as suas aplicações e serviços que minimiza a quantidade de trabalho necessário para passar do Controlo de Acesso.
Serviços Web que utilizam autenticação ativa
Para serviços Web protegidos com tokens emitidos por Controlo de Acesso, Controlo de Acesso oferece as seguintes funcionalidades e capacidades:
- Capacidade de registar uma ou mais identidades de serviço no seu espaço de nomes Controlo de Acesso. As identidades de serviço podem ser utilizadas para pedir tokens.
- Suporte para os protocolos OAuth WRAP e OAuth 2.0 Draft 13 para pedir tokens, utilizando os seguintes tipos de credenciais:
- Uma palavra-passe simples criada para a identidade de serviço
- Um SWT assinado com uma chave simétrica ou um certificado X509
- Um token SAML emitido por um fornecedor de identidade fidedigno (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 tokens simples.
Normalmente, as identidades de serviço no Controlo de Acesso são utilizadas para implementar a autenticação servidor a servidor.
Migrar para Microsoft Entra ID
A nossa recomendação para este tipo de fluxo de autenticação é migrar para Microsoft Entra ID. Microsoft Entra ID é o fornecedor de identidade baseado na cloud para contas escolares ou profissionais da Microsoft. Microsoft Entra ID é o fornecedor de identidade do Microsoft 365, do Azure e muito mais.
Também pode utilizar Microsoft Entra ID para autenticação servidor a servidor com a implementação Microsoft Entra da concessão de credenciais de cliente OAuth. A tabela seguinte compara as capacidades de Controlo de Acesso na autenticação servidor a servidor com as que estão disponíveis no Microsoft Entra ID.
| Funcionalidade | Controlo de Acesso suporte | suporte de ID de Microsoft Entra |
|---|---|---|
| Como registar um serviço Web | Criar uma entidade confiadora no portal de gestão do Controlo de Acesso | Criar uma aplicação Web Microsoft Entra no portal do Azure |
| Como registar um cliente | Criar uma identidade de serviço no portal de gestão do Controlo de Acesso | Criar outra aplicação Web Microsoft Entra no portal do Azure |
| Protocolo utilizado | - Protocolo OAuth WRAP - Concessão de credenciais de cliente do OAuth 2.0 Draft 13 |
Concessão de credenciais de cliente OAuth 2.0 |
| Métodos de autenticação de cliente | - Palavra-passe simples - SWT Assinado - Token SAML de um fornecedor de identidade federado |
- Palavra-passe simples - JWT assinado |
| Formatos de tokens | - JWT - SAML 1.1 - SAML 2.0 - SWT |
Apenas JWT |
| Transformação de tokens | - Adicionar afirmações personalizadas - Lógica de emissão de afirmações if-then simples |
Adicionar afirmações personalizadas |
| Automatizar tarefas de configuração e gestão | Suportado através do Serviço de Gestão de Controlo de Acesso | Suportado através do Microsoft Graph API |
Para obter orientações sobre a implementação de cenários servidor a servidor, veja os seguintes recursos:
- Secção Serviço a Serviço do guia do programador do Microsoft Entra
- Exemplo de código daemon com credenciais de cliente de palavra-passe simples
- Exemplo de código daemon com credenciais de cliente de certificado
Migrar para a Identidade de Ping ou Autenticação0
Em alguns casos, poderá descobrir que as credenciais de cliente Microsoft Entra e a implementação da concessão OAuth não são suficientes para substituir Controlo de Acesso na sua arquitetura sem grandes alterações de código. Alguns exemplos comuns podem incluir:
- Autenticação servidor a servidor com formatos de token diferentes dos JWTs.
- Autenticação servidor a servidor com um token de entrada fornecido por um fornecedor de identidade externo.
- A autenticação servidor a servidor com regras de transformação de tokens que Microsoft Entra ID não pode ser reproduzida.
Nestes casos, poderá considerar migrar a sua aplicação Web para outro serviço de autenticação na cloud. Recomendamos que explore as seguintes opções. Cada uma das seguintes opções oferece capacidades semelhantes às Controlo de Acesso:
O Auth0 é um serviço de identidade da cloud flexível que criou orientações de migração de alto nível para clientes de Controlo de Acesso e suporta quase todas as funcionalidades que o ACS faz.
Ping Identidade oferece duas soluções semelhantes à ACS. O PingOne é um serviço de identidade na cloud que suporta muitas das mesmas funcionalidades que o ACS e o PingFederate é um produto de identidade no local semelhante que oferece mais flexibilidade. Veja a documentação de orientação para a descontinuação acS do Ping para obter mais detalhes sobre a utilização destes produtos.
O nosso objetivo é trabalhar com o Ping Identity e o Auth0 para garantir que todos os Controlo de Acesso clientes têm um caminho de migração para as respetivas aplicações e serviços que minimiza a quantidade de trabalho necessário para sair do Controlo de Acesso.
Autenticação pass-through
Para autenticação pass-through com transformação de tokens arbitrários, não existe nenhuma tecnologia equivalente da Microsoft para ACS. Se for isso que os seus clientes precisam, a Autenticação0 poderá ser aquela que fornece a solução de aproximação mais próxima.
Perguntas, preocupações e comentários
Compreendemos que muitos Controlo de Acesso clientes não encontrarão um caminho de migração claro após ler este artigo. Poderá precisar de ajuda ou orientação para determinar o plano correto. Se quiser discutir os seus cenários de migração e perguntas, deixe um comentário nesta página.