Migrando namespaces do ACS para o Google OpenID Connect
Este tópico destina-se a proprietários de namespaces do Serviço de Controle de Acesso (ACS) 2.0 que atualmente usam o Google como um provedor de identidade. O ACS fornece esse recurso usando a implementação OpenID 2.0 do Google. O Google planeja descontinuar o suporte ao OpenID 2.0 até 20 de abril de 2015. Os namespaces ACS continuarão a funcionar com a implementação do OpenID 2.0 do Google até 1º de junho de 2015, quando você deverá concluir a migração desses namespaces para usar a implementação do OpenID Connect do Google ou os usuários não poderão mais fazer login no seu aplicativo com uma Conta do Google. Migrar seus namespaces ACS para o OpenID Connect não causará tempo de inatividade do aplicativo. Com uma exceção (veja a nota abaixo), essa migração é possível sem alterar o código do aplicativo. Depois de migrar seus namespaces ACS para usar o OpenID Connect, você precisará migrar os identificadores de seus usuários em seu back-end para identificadores do OpenID Connect. Essa migração deve ser concluída até 1º de janeiro de 2017. Isso exigirá alterações de código em seu back-end. Consulte a importante nota abaixo para obter detalhes sobre ambas as fases da migração.
Importante
Observe as seguintes datas importantes e conclua as ações exigidas por cada data para garantir que seus namespaces ACS que usam o Google como provedor de identidade continuem funcionando:
-
1º de junho de 2015 - Os namespaces ACS deixarão de funcionar com a implementação OpenID 2.0 do Google. Você deve concluir a migração do namespace ACS para usar o Google OpenID Connect até esta data. Antes dessa data, você pode reverter para o OpenID 2.0 se encontrar problemas durante a migração. Para namespaces que não foram migrados até essa data, os usuários não poderão mais fazer login com uma Conta do Google e receberão uma página que indica que o OpenID 2.0 para contas do Google desapareceu. Para restaurar o recurso de login com as Contas do Google, você precisará migrar o namespace.
Na maioria dos casos, nenhuma alteração no código do aplicativo deve ser necessária. No entanto, se você tiver a regra "passthrough all claims" para o Google como provedor de identidade em um grupo de regras associado ao seu aplicativo, talvez seja necessário fazer alterações no código. Isso ocorre porque, após a migração, um novo tipo de declaração (Assunto) fica disponível para o ACS do Google, e talvez seja necessário fazer alterações no código para garantir que seu aplicativo possa lidar com a presença do novo tipo de declaração normalmente. Para concluir a migração com êxito, não será necessário processar o novo tipo de declaração em seu aplicativo.
-
1 de janeiro de 2017 – As implementações OpenID 2.0 e OpenID Connect do Google usam identificadores diferentes para identificar exclusivamente os usuários do Google. Quando você migra seu namespace ACS, o ACS disponibiliza dois identificadores, o identificador OpenID 2.0 atual e o novo identificador OpenID Connect, para seu aplicativo. Você deve alternar os identificadores de seus usuários em seu sistema de back-end para identificadores OpenID Connect até esta data e começar a usar apenas identificadores OpenID Connect no futuro. Isso requer alterações no código do aplicativo.
Você pode postar perguntas sobre migração no Stack Overflow e marcá-las com 'acs-google'. Responderemos o mais rapidamente possível.
Para obter mais informações sobre os planos do Google, consulte o Guia de migração do OpenID 2.0 .
Lista de verificação de migração
A tabela a seguir contém uma lista de verificação que resume as etapas necessárias para migrar seu namespace ACS para usar a implementação do OpenID Connect do Google:
Passo | Descrição | Deve ser preenchido até |
---|---|---|
1 |
Crie um aplicativo do Google+ no Google Developers Console. |
Junho 1, 2015 |
2 |
Se você tiver a regra "passar todas as declarações" para o Google como um provedor de identidade em um grupo de regras associado ao seu aplicativo, teste seu aplicativo para garantir que ele esteja pronto para migração; caso contrário, esta etapa é opcional. |
Junho 1, 2015 |
3 |
Use o Portal de Gerenciamento ACS para alternar seu namespace ACS para usar a implementação OpenID Connect do Google, fornecendo-lhe os parâmetros do aplicativo Google+ (ID do cliente e segredo do cliente). Se você encontrar problemas com sua migração, reverter para o OpenID 2.0 é possível até 1º de junho de 2015. |
Junho 1, 2015 |
4 |
Migre os identificadores de seus usuários em seu sistema de back-end dos identificadores atuais do Google OpenID 2.0 para os novos identificadores do Google OpenID Connect. Isso requer alterações de código. |
1 de janeiro, 2017 |
Passo a passo da migração
Para migrar seu namespace ACS para usar a implementação OpenID Connect do Google, conclua as seguintes etapas:
Criar um aplicativo do Google+
Para obter instruções detalhadas sobre como fazer isso, consulte a seção Como criar um aplicativo do Google+.
Verifique se seu aplicativo está pronto para migração
Se você tiver a regra "passar todas as declarações" para o Google como provedor de identidade em um grupo de regras associado ao seu aplicativo, siga as instruções na seção Como: Garantir a prontidão de migração de um aplicativo ACS para testar a prontidão da migração do aplicativo. Isso ocorre porque, após a migração, um novo tipo de declaração (Assunto) fica disponível para o ACS do Google.
Observação
Uma regra "passthrough all claims" é uma regra em que de tipo de declaração de entrada e de valor de declaração de entrada são definidos como Qualquer e tipo de declaração de saída e valor da declaração de saída são definidos como Passar pelo primeiro tipo de declaração de entrada e Passar pelo valor da declaração de entrada respectivamente. A regra está listada na Portal de Gerenciamento ACS do
, conforme mostrado abaixo, com a coluna Declaração de Saída definida como de Passagem. Se você já gerou regras ou adicionou regras manualmente para o Google como provedor de identidade em um grupo de regras associado ao seu aplicativo, ignore esta etapa. Isso ocorre porque, nesses casos, após a migração, o novo tipo de declaração Subject não é enviado para o aplicativo.
Para saber mais sobre essas opções, consulte Grupos de regras e Regras.
Alterne o namespace ACS para usar a implementação OpenID Connect do Google
Vá para o Portal de Gerenciamento do Microsoft Azure, entre e clique em Ative Directory. Selecione o namespace ACS que precisa ser migrado e clique em Gerenciar para iniciar o Portal de Gerenciamento ACS.
No
Portal de Gerenciamento ACS , clique emProvedores de Identidade na árvore à esquerda ou clique no link Provedores de Identidade na seção Introdução ao . Clique Google. Na página Editar do Google Identity Provider, marque Usar o OpenID Connect.
Nos campos ID do cliente e secreto do cliente (agora ativado), copie os valores correspondentes do seu aplicativo do Google+.
Observação
Neste ponto, se você clicar em Salvar, todas as solicitações do provedor de identidade do Google do seu namespace ACS usarão automaticamente a implementação OpenID Connect do Google. Se precisar reverter, desmarque Usar OpenID Connect. A ID do Cliente e o segredo do Cliente permanecem guardados e podem ser reutilizados mais tarde.
Clique Salvar.
Tente fazer login com um ID do Google para garantir que a mudança para o uso do OpenID Connect foi bem-sucedida. Se você tiver problemas para fazer login, volte para a página
Editar provedor de identidade do Google e desmarque de ID do ClienteUsar OpenID Connect para reverter para o OpenID 2.0. Depois de reverter, verifique se oe Secreto copiados do Google Developer Console foram inseridos corretamente para seu namespace; Por exemplo, verifique se há erros de digitação.
Migrar os identificadores de usuários em seu sistema de back-end do Open ID 2.0 para o OpenID Connect
Você deve migrar os identificadores de usuários em seu sistema de back-end dos identificadores existentes do Google Open ID 2.0 para os novos identificadores do Google OpenID Connect antes de 1º de janeiro de 2017. Esta etapa requer alterações de código. Para obter mais informações, consulte Como migrar os identificadores Open ID 2.0 existentes dos usuários para novos identificadores de usuário do OpenID Connect
Como criar um aplicativo do Google+
Você precisará de uma Conta do Google para executar as etapas a seguir; se você não tiver um, você pode obter um em https://accounts.google.com/SignUp.
Numa janela do navegador, navegue até ao
Google Developers Console e inicie sessão com as credenciais da sua Conta Google. Clique em
Criar Projeto e insira umNome do projeto e ID do projeto . Marque a caixa de seleção Termos de Serviço. Em seguida, clique em Criar. Isso registra o aplicativo no Google.Clique em APIs & de autenticação no painel esquerdo. E, em seguida, clique em Credenciais. Em OAuth , clique em Criar nova ID de Cliente. Selecione Aplicativo Web e clique tela Configurar consentimento. Forneça um Nome do Produto e clique em Salvar.
Clique em APIs & de autenticação no painel esquerdo. E, em seguida, clique em APIs. Em Procurar APIs, pesquise e encontre API do Google+. Ligue o Status
para ON .Na caixa de diálogo Criar de ID do Cliente, selecione de Aplicativo Web como o Tipo de Aplicativo.
No campo
Origens Javascript Autorizadas, especifique o URL do nome de domínio totalmente qualificado (FQDN) do seu namespace, incluindo o "HTTPS://" à esquerda e o número da porta à direita; por exemplo, . No campo URIs de Redirecionamento Autorizado
, especifique um URI que contenha a URL de nome de domínio totalmente qualificado (FQDN) do seu namespace, incluindo o "HTTPS://" à esquerda e o número da porta à direita, seguido por "/v2/openid"; por exemplo, . Clique Criar ID do Cliente.
Anote os valores de
ID do Cliente esecreto do Cliente na página ID do Cliente para aplicativo Web. Você precisará deles para configurar a implementação do OpenID Connect do Google no Portal de Gerenciamento ACS . de aplicativos Web
Importante
Segredo do Cliente é uma credencial de segurança importante. Mantenha-o em segredo.
Como: Migrar os identificadores existentes do Open ID 2.0 de seus usuários para novos identificadores de usuário do OpenID Connect
Depois de migrar com êxito seu namespace ACS para usar a implementação OpenID Connect do Google, você tem até 1º de janeiro de 2017 (de acordo com o Guia de Migração do OpenID 2.0 do Google) para migrar os identificadores dos usuários em seu sistema de back-end dos identificadores atuais do OpenID 2.0 para os novos identificadores do OpenID Connect.
A tabela a seguir mostra os tipos de declaração que ficam disponíveis para o ACS do Google depois que o namespace do ACS é migrado para usar a implementação OpenID Connect do Google:
Tipo de reclamação | URI | Descrição | Disponibilidade do protocolo |
---|---|---|---|
Identificador de nome |
https://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier |
Um identificador exclusivo para a conta de usuário, fornecido pelo Google. Este é o identificador OpenID 2.0 (existente). |
OpenID 2.0, OpenID Connect |
Assunto |
https://schemas.microsoft.com/identity/claims/subject |
Um identificador exclusivo para a conta de usuário, fornecido pelo Google. Este é o (novo) identificador OpenID Connect. |
Conexão OpenID |
Designação |
https://schemas.xmlsoap.org/ws/2005/05/identity/claims/name |
O nome de exibição da conta de usuário, fornecido pelo Google. |
OpenID 2.0, OpenID Connect (ver nota abaixo) |
Endereço de e-mail |
https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress |
O endereço de e-mail da conta de utilizador, fornecido pela Google |
OpenID 2.0, OpenID Connect |
Provedor de identidade |
https://schemas.microsoft.com/accesscontrolservice/2010/07/claims/IdentityProvider |
Uma declaração fornecida pelo ACS que informa ao aplicativo de terceira parte confiável que o usuário se autenticou usando o provedor de identidade padrão do Google. O valor dessa declaração é visível no Portal de Gerenciamento ACS por meio do campo Realm na página Editar provedor de identidade. |
OpenID 2.0, OpenID Connect |
Observação
Para um usuário do Google que não tenha um perfil (registrado) do Google+, o valor do nome tipo de declaração é o mesmo que o valor do endereço de e-mail tipo de declaração no OpenID Connect.
Os tipos de declaração Name Identifier e Subject podem ser usados para rastrear e alternar os identificadores exclusivos dos usuários existentes em seu back-end mapeando identificadores OpenID 2.0 (antigos) para (novos) identificadores OpenID Connect.
Se você tiver a regra "passar todas as declarações" para o Google como provedor de identidade em um grupo de regras associado ao seu aplicativo, seu aplicativo começará automaticamente a receber o tipo de declaração Assunto.
Se você já gerou regras ou adicionou regras manualmente para o Google como provedor de identidade em um grupo de regras associado ao seu aplicativo, será necessário adicionar o tipo de declaração Assunto manualmente. Para obter mais informações sobre como fazer isso, consulte Grupos de regras e Regras.
Por exemplo, se você já gerou regras para o Google como provedor de identidade em um grupo de regras e, em seguida, adicionou o novo tipo de declaração Assunto (conforme mostrado acima), verá o seguinte.
O aplicativo que usa esse grupo de regras receberá o Assunto tipo de declaração, juntamente com outros tipos de declaração.
Observação
Após 1º de janeiro de 2017, quando o Google descontinuar seu suporte para mapeamento de identificadores, o ACS preencherá os tipos de declaração NameIdentifier e Subject com o mesmo identificador de usuário do OpenID Connect.
Como garantir a prontidão de migração de um aplicativo ACS
Com uma exceção, migrar seu namespace ACS para usar a implementação OpenID Connect do Google é possível sem alterar o código do aplicativo. O caso de exceção é se você tiver a regra "passthrough all claims" para o Google como um provedor de identidade em um grupo de regras associado ao seu aplicativo. Isso ocorre porque, neste caso, após a migração, um novo tipo de reivindicação (Assunto) é enviado automaticamente para o aplicativo.
Esta seção descreve o procedimento de alteração e teste recomendado que você pode seguir para garantir que todos os aplicativos que serão afetados pela migração estejam prontos para lidar com o novo tipo de declaração.
Para os fins deste Como, suponha que você seja o proprietário de um namespace ACS chamado ns-contoso e que seu aplicativo em produção seja chamado ProdContosoApp. Suponha também que este aplicativo usa o Google como um provedor de identidade e tem a regra "passthrough all claims" ativada para o Google.
Configuração
Para começar, vá para o Portal de Gerenciamento do Microsoft Azure, entre e clique em Ative Directory. Selecione o namespace ACS (ns-contoso) e clique em Gerenciar para iniciar o Portal de Gerenciamento ACS.
No
Portal de Gerenciamento ACS , clique em Aplicativos de Terceira Parte Confiável na árvore à esquerda ou clique no link Aplicativos de Terceira Parte Confiável na seção Introdução ao . Em seguida, clique em seu aplicativo de produção (ProdContosoApp). Anote as propriedades de ProdContosoApp, você precisará delas mais tarde.
Clique em Grupo de Regras Padrão para ProdContosoApp em Grupos de regras para verificar se ele tem a regra "passthrough all claims" ativada para o Google.
Etapa 1: Configurar uma instância de teste do seu aplicativo no namespace ACS de produção
Configure uma instância de teste do seu aplicativo, TestContosoApp, em um URI raiz diferente; por exemplo, https://contoso-test.com:7777/. Você terá que registrá-lo como um Aplicativo de Terceira Parte Confiável (Aplicativos de Terceira Parte Confiável) no namespace ns-contoso.
No
Portal de Gerenciamento ACS , clique em Aplicativos de Terceira Parte Confiável na árvore à esquerda ou clique no link Aplicativos de Terceira Parte Confiável na seção Introdução ao . Em seguida, clique Adicionar na página Aplicativos deTerceira Parte Confiável. Na página Adicionar Aplicativo de Terceira Parte Confiável, faça o seguinte:
Em Nome, digite o nome do aplicativo de teste. Aqui está TestContosoApp.
Em Modo, selecione Inserir configurações manualmente.
Em Realm, digite o URI do aplicativo de teste. Aqui está https://contoso-test.com:7777/.
Para os fins deste Como, você pode deixar URL de erro (opcional) em branco.
Para o formato
Token ,política de criptografia de Token epropriedades de de tempo de vida do token (segs) e a seção Configurações de Assinatura de Token, use os mesmos valores que você usou para ProdContosoApp . Certifique-se de que selecionou Google como um Identity Provider.
Em Grupos de Regras, selecione Criar novo grupo de regras.
Clique Salvar na parte inferior da página.
Etapa 2: criar um grupo de regras que simule o formato do token ACS que o aplicativo receberá depois que o namespace for migrado para usar a implementação do OpenID Connect do Google
No
Portal de Gerenciamento ACS , clique em Grupos de Regras na árvore à esquerda ou clique no link Grupo de Regras na seção Introdução. Em seguida, clique Adicionar na página Grupos de Regras do. Na página Adicionar Grupo de Regras, forneça um nome para o novo grupo de regras, digamos ManualGoogleRuleGroup. Clique em Salvar.
Na página
Editar Grupo de Regras, clique no link Adicionar .Na página Adicionar Regra de Declaração, certifique-se de que tem os seguintes valores e clique em Guardar. Isso gera uma regra "passthrough all claims" para o Google.
Se seção:
Identity Provider é Google.
Seleção de Tipo de declaração de entrada é Qualquer.
O valor da declaração de entrada é qualquer.
Em seguida, seção:
Tipo de declaração de saída é Passar pelo primeiro tipo de declaração.
Valor da declaração de saída é Passar pelo primeiro valor da declaração de entrada.
Seção informações sobre regras:
- Deixe o campo Descrição do (opcional) em branco.
Na página
Editar Grupo de Regras, clique no link Adicionar novamente.Na página
Adicionar Regra de Declaração, verifique se você tem os seguintes valores e clique em Salvar. Isso gera uma regra de reivindicação "estática" para o Google que simula a adição de um novo tipo de declaração, Subject, que é o novo identificador OpenID Connect do usuário que o Google envia ao aplicativo após a migração. Se seção:
Identity Provider é Google.
Seleção de Tipo de declaração de entrada é Qualquer.
O valor da declaração de entrada é qualquer.
Em seguida, seção:
Tipo de declaração de saída é Tipo Enter. No campo, digite https://schemas.microsoft.com/identity/claims/subject.
Valor da declaração de saída é Insira o valor. No campo, digite 123456.
Seção informações sobre regras:
- Deixe o campo Descrição do (opcional) em branco.
Clique
Salvar na páginaEditar Grupo de Regras.
Etapa 3: Associar o novo Grupo de Regras à instância de teste do aplicativo
No
Portal de Gerenciamento ACS , clique em Aplicativos de Terceira Parte Confiável na árvore à esquerda ou clique no link Aplicativos de Terceira Parte Confiável na seção Introdução ao . Em seguida, clique em TestContosoApp na página Aplicativos de Terceira Parte Confiável. Na página
Editar de Terceira Parte Confiável, selecioneManualGoogleRuleGroup na seção Configurações de Autenticação e clique em Salvar .
Neste ponto, todas as solicitações de login do Google para seus aplicativos de teste incluirão o novo tipo de declaração.
Etapa 4: Teste para garantir que seu aplicativo possa lidar com a adição do tipo de declaração Assunto
Teste seu aplicativo para garantir que ele possa lidar com a presença do novo tipo de declaração (Subject) normalmente. Normalmente, um aplicativo bem escrito deve ser robusto para novos tipos de declaração que estão sendo adicionados ao token. Encontre e corrija quaisquer problemas. Opcionalmente, você também pode seguir a seção Como: Migrar os identificadores Open ID 2.0 existentes de seus usuários para novos identificadores de usuário do OpenID Connect para fazer o mapeamento de identificador de usuário.
Etapa 5: Migrar seu ambiente de produção
Recrie e implante seu aplicativo de produção (ProdContosoApp). Migre o namespace (ns-contoso) para usar a implementação do OpenID Connect do Google seguindo as etapas no passo a passo da migração. Verifique se ProdContosoApp funciona conforme o esperado.