Visão geral dos fornecedores de identidade para o Azure Stack Hub

O Azure Stack Hub requer Azure Ative Directory (Azure AD) ou Serviços de Federação do Ative Directory (AD FS) (AD FS), apoiado pelo Ative Directory como fornecedor de identidade. A escolha de um fornecedor é uma decisão única que se tomam quando implementamos o Azure Stack Hub pela primeira vez. Os conceitos e detalhes de autorização neste artigo podem ajudá-lo a escolher entre fornecedores de identidade.

A sua escolha de Azure AD ou AD FS é determinada pelo modo em que implementa O Azure Stack Hub:

  • Quando o implementar num modo ligado, pode utilizar Azure AD ou AD FS.
  • Quando o implementa num modo desligado, sem ligação à internet, apenas o AD FS é suportado.

Para obter mais informações sobre as suas opções, que dependem do ambiente Azure Stack Hub, consulte os seguintes artigos:

Importante

A Azure AD Graph está a ser depreciada, e será reformada a 30 de junho de 2022. Para mais informações, consulte esta secção.

Conceitos comuns para fornecedores de identidade

As próximas secções discutem conceitos comuns sobre fornecedores de identidade e a sua utilização no Azure Stack Hub.

Terminology for identity providers

Inquilinos e organizações de diretórios

Um diretório é um contentor que contém informações sobre utilizadores, aplicações, grupos e diretores de serviço.

Um inquilino de diretório é uma organização, como a Microsoft ou a sua própria empresa.

  • O Azure AD suporta vários inquilinos e pode suportar múltiplas organizações, cada uma no seu diretório. Se você usar Azure AD e tiver vários inquilinos, você pode conceder apps e utilizadores de um inquilino acesso a outros inquilinos do mesmo diretório.
  • A AD FS suporta apenas um único inquilino e, portanto, apenas uma organização.

Utilizadores e grupos

As contas de utilizador (identidades) são contas padrão que autenticam indivíduos utilizando um ID do utilizador e uma palavra-passe. Os grupos podem incluir utilizadores ou outros grupos.

A forma como cria e gere utilizadores e grupos depende da solução de identidade que utiliza.

No Azure Stack Hub, contas de utilizador:

  • São criados no formato username@domain . Embora o AD FS mapeia as contas dos utilizadores para uma instância do Ative Directory, o AD FS não suporta a utilização do formato \<domain>\<alias> .
  • Pode ser configurado para utilizar a autenticação de vários fatores.
  • Limitam-se ao diretório onde se registam pela primeira vez, que é o diretório da sua organização.
  • Pode ser importado dos seus diretórios no local. Para mais informações, consulte Integrar os seus diretórios no local com Azure Ative Directory.

Quando iniciar sôs o seu acesso ao portal de utilizador da sua organização, utiliza o https://portal.local.azurestack.external URL. Ao iniciar a sessão no portal Azure Stack Hub a partir de domínios que não o utilizado para registar o Azure Stack Hub, o nome de domínio utilizado para registar o Azure Stack Hub deve ser anexado ao url do portal. Por exemplo, se o Azure Stack Hub tiver sido registado com fabrikam.onmicrosoft.com e a conta de utilizador estiver admin@contoso.comem sessão, o URL a utilizar para iniciar sessão no portal do utilizador será: https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

Utilizadores convidados

Os utilizadores convidados são contas de utilizadores de outros inquilinos do diretório que tiveram acesso a recursos no seu diretório. Para suportar utilizadores convidados, utiliza Azure AD e permite suporte para vários arrendamentos. Quando o suporte está ativado, pode convidar os utilizadores convidados a acederem aos recursos no seu inquilino de diretório, o que por sua vez permite a sua colaboração com organizações externas.

Para convidar utilizadores convidados, operadores de nuvem e utilizadores podem utilizar a colaboração Azure AD B2B. Os utilizadores convidados têm acesso a documentos, recursos e aplicações do seu diretório, e mantêm o controlo sobre os seus próprios recursos e dados.

Como utilizador convidado, pode inscrever-se no inquilino do diretório de outra organização. Para tal, você anexa o nome do diretório dessa organização ao URL do portal. Por exemplo, se você pertence à organização Contoso e quer assinar no diretório de Fabrikam, você usa https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

Aplicações

Pode registar aplicações para Azure AD ou AD FS e, em seguida, oferecer as aplicações aos utilizadores da sua organização.

As aplicações incluem:

  • Aplicações web: Exemplos incluem o portal do Azure e Azure Resource Manager. Eles suportam chamadas web API.
  • Cliente nativo: Exemplos incluem Azure PowerShell, Visual Studio e Azure CLI.

As aplicações podem suportar dois tipos de arrendamento:

  • Inquilino único: Suporta utilizadores e serviços apenas a partir do mesmo diretório onde a aplicação está registada.

    Nota

    Como a AD FS suporta apenas um único diretório, as aplicações que você cria em uma topologia AD FS são, por design, aplicações de inquilino único.

  • Multi-inquilino: Suporta o uso por utilizadores e serviços tanto do diretório onde a app está registada e de diretórios de inquilinos adicionais. Com aplicações multi-arrendatários, os utilizadores de outro diretório de inquilinos (outro inquilino Azure AD) podem iniciar sação na sua app.

    Para obter mais informações sobre o multi-arrendamento, consulte Ative multi-arrendamento.

    Para obter mais informações sobre o desenvolvimento de uma app multi-inquilino, consulte aplicações multi-inquilinos.

Quando regista uma aplicação, cria dois objetos:

  • Objeto de aplicação: A representação global da app em todos os inquilinos. Esta relação é um para um com a aplicação de software e existe apenas no diretório onde a aplicação é registada pela primeira vez.

  • Objeto principal do serviço: uma credencial criada para uma aplicação no diretório onde a aplicação é registada pela primeira vez. Um diretor de serviço também é criado no diretório de cada inquilino adicional onde essa aplicação é usada. Esta relação pode ser de um para muitos com a aplicação de software.

Para saber mais sobre aplicações e objetos principais de serviço, consulte os objetos principais de aplicação e serviço em Azure Ative Directory.

Principais de serviço

Um diretor de serviço é um conjunto de credenciais para uma app ou serviço que concedem acesso a recursos no Azure Stack Hub. O uso de um diretor de serviço separa as permissões da aplicação das permissões do utilizador da aplicação.

Um diretor de serviço é criado em cada inquilino onde a app é usada. O diretor de serviço estabelece uma identidade para a inscrição e acesso a recursos (como utilizadores) que são garantidos por esse inquilino.

  • Uma aplicação de inquilino único tem apenas um diretor de serviço, que está no diretório onde é criado pela primeira vez. Este diretor de serviço é criado e consente em ser usado durante o registo da app.
  • Uma aplicação web multi-inquilino ou API tem um principal serviço que é criado em cada inquilino onde um utilizador desse inquilino consente com o uso da app.

As credenciais para os principais de serviço podem ser uma chave que é gerada através do portal do Azure ou um certificado. A utilização de um certificado é adequada para automatização porque os certificados são considerados mais seguros do que as chaves.

Nota

Quando utiliza O FS AD com Azure Stack Hub, apenas o administrador pode criar principais serviços. Com a AD FS, os principais de serviço requerem certificados e são criados através do ponto final privilegiado (PEP). Para obter mais informações, consulte Utilizar uma identidade de aplicação para aceder aos recursos.

Para saber mais sobre os principais serviços do Azure Stack Hub, consulte os principais de serviços Create.

Serviços

Os serviços no Azure Stack Hub que interagem com o fornecedor de identidade estão registados como aplicações com o fornecedor de identidade. Tal como as aplicações, o registo permite que um serviço autense com o sistema de identidade.

Todos os serviços da Azure utilizam protocolos de Ligação OpenID e Tokens Web JSON para estabelecer a sua identidade. Uma vez que o Azure AD e o AD FS utilizam protocolos de forma consistente, pode utilizar Azure Ative Directory Autenticação (ADAL) para autenticar no local ou no Azure (num cenário ligado). Com a ADAL, também pode utilizar ferramentas como Azure PowerShell e Azure CLI para a gestão de recursos em nuvem cruzada e no local.

Identidades e o seu sistema de identidade

As identidades do Azure Stack Hub incluem contas de utilizadores, grupos e diretores de serviço.

Ao instalar o Azure Stack Hub, várias aplicações e serviços incorporados registam-se automaticamente com o seu fornecedor de identidade no inquilino do diretório. Alguns serviços que se registam são utilizados para administração. Outros serviços estão disponíveis para os utilizadores. Os registos predefinidos dão identidades de serviços fundamentais que podem interagir entre si e com identidades que adiciona mais tarde.

Se configurar o Azure AD com vários arrendamentos, algumas aplicações propagam-se aos novos diretórios.

Autenticação e autorização

Autenticação por apps e utilizadores

Identity between layers of Azure Stack Hub

Para apps e utilizadores, a arquitetura do Azure Stack Hub é descrita por quatro camadas. As interações entre cada uma destas camadas podem utilizar diferentes tipos de autenticação.

Camada Autenticação entre camadas
Ferramentas e clientes, como o portal do administrador Para aceder ou modificar um recurso no Azure Stack Hub, ferramentas e clientes usam um Token Web JSON para fazer uma chamada para a Azure Resource Manager.
A Azure Resource Manager valida o JSON Web Token e espreita as reclamações no token emitido para estimar o nível de autorização que o utilizador ou diretor de serviço tem no Azure Stack Hub.
A Azure Resource Manager e os seus serviços essenciais O Azure Resource Manager comunica com fornecedores de recursos para transferir a comunicação dos utilizadores.
As transferências utilizam chamadas imperativas diretas ou chamadas declarativas através de modelos de Resource Manager Azure.
Fornecedores de recursos As chamadas passadas aos fornecedores de recursos são asseguradas com autenticação baseada em certificados.
O Azure Resource Manager e o fornecedor de recursos permanecem em comunicação através de uma API. Para cada chamada recebida da Azure Resource Manager, o fornecedor de recursos valida a chamada com esse certificado.
Infraestrutura e lógica de negócio Os fornecedores de recursos comunicam com a lógica e infraestrutura do negócio utilizando um modo de autenticação à sua escolha. Os fornecedores de recursos predefinidos que enviam com o Azure Stack Hub utilizam Windows Autenticação para garantir esta comunicação.

Information needed for authentication

Autenticação para Azure Resource Manager

Para autenticar com o fornecedor de identidade e receber um Token Web JSON, deve ter as seguintes informações:

  1. URL para o sistema de identidade (Autoridade): O URL no qual o seu fornecedor de identidade pode ser alcançado. Por exemplo, https://login.windows.net.
  2. App ID URI para Azure Resource Manager: O identificador único da Azure Resource Manager que está registado no seu fornecedor de identidade. Também é único em cada instalação do Azure Stack Hub.
  3. Credenciais: A credencial que utiliza para autenticar com o fornecedor de identidade.
  4. URL para Azure Resource Manager: O URL é a localização do serviço Azure Resource Manager. Por exemplo, https://management.azure.com ou https://management.local.azurestack.external.

Quando um principal (um cliente, apps ou utilizador) faz um pedido de autenticação para aceder a um recurso, o pedido deve incluir:

  • As credenciais do diretor.
  • A aplicação ID URI do recurso a que o diretor quer aceder.

As credenciais são validadas pelo fornecedor de identidade. O fornecedor de identidade também valida que a app ID URI é para uma aplicação registada, e que o principal tem os privilégios corretos para obter um símbolo para esse recurso. Se o pedido for válido, é concedido um Token Web JSON.

O símbolo deve então passar no cabeceamento de um pedido a Azure Resource Manager. A Azure Resource Manager faz o seguinte, sem ordem específica:

  • Valida a alegação do emitente (iss) para confirmar que o token é do fornecedor de identidade correto.
  • Valida a alegação do público (aud) para confirmar que o token foi emitido para Azure Resource Manager.
  • Valida que o JSON Web Token é assinado com um certificado configurado através do OpenID e conhecido por Azure Resource Manager.
  • Reveja as alegações emitidas em (iat) e expiração (exp) para confirmar que o token está ativo e pode ser aceite.

Quando todas as validações estiverem completas, a Azure Resource Manager usa o id de objeto (oid) e os grupos alegam fazer uma lista de recursos a que o principal pode aceder.

Diagram of the token exchange protocol

Nota

Após a implementação, Azure Ative Directory autorização global de administrador não é necessária. No entanto, algumas operações podem exigir as credenciais de administração global (por exemplo, um script de instalador de recursos ou uma nova funcionalidade que exija uma permissão para ser concedida). Pode reintegrar temporariamente as permissões de administração global da conta ou utilizar uma conta de administração global separada que seja proprietária da subscrição do fornecedor predefinido.

Use Role-Based Controlo de Acesso

Role-Based Controlo de Acesso (RBAC) no Azure Stack Hub é consistente com a implementação em Microsoft Azure. Pode gerir o acesso aos recursos atribuindo o papel apropriado do RBAC aos utilizadores, grupos e aplicações. Para obter informações sobre como utilizar o RBAC com o Azure Stack Hub, consulte os seguintes artigos:

Autenticar com o Azure PowerShell

Os detalhes sobre a utilização de Azure PowerShell para autenticar com o Azure Stack Hub podem ser encontrados no Configure o ambiente PowerShell do utilizador do Azure Stack Hub.

Autenticar com Azure CLI

Para obter informações sobre a utilização de Azure PowerShell para autenticar com o Azure Stack Hub, consulte instalar e configurar o Azure CLI para utilização com o Azure Stack Hub.

Azure Policy

Azure Policy ajuda a impor normas organizacionais e a avaliar o cumprimento em escala. Através do seu painel de conformidade, proporciona uma visão agregada para avaliar o estado geral do ambiente, com a capacidade de aprofundar a granularidade por recurso, por política. Também ajuda a levar os seus recursos ao cumprimento através da reparação a granel para os recursos existentes e a remediação automática de novos recursos.

Os casos de utilização comum para Azure Policy incluem a implementação da governação para a consistência dos recursos, a conformidade regulamentar, a segurança, os custos e a gestão. As definições de política para estes casos de uso comum já estão incorporadas no seu ambiente Azure para ajudá-lo a começar.

Nota

Azure Policy não é suportado no Azure Stack Hub.

Azure AD Graph

Microsoft Azure anunciou a depreciação da Azure AD Graph em 30 de junho de 2020 e a data da sua reforma de 30 de junho de 2022. A Microsoft informou os clientes via e-mail sobre esta mudança. A secção seguinte descreve como esta depreciação afeta o Azure Stack Hub.

A equipa do Azure Stack Hub está a trabalhar em estreita colaboração com a equipa do Azure Graph para garantir que os seus sistemas continuem a funcionar para além de 30 de junho de 2022, se necessário, para garantir uma transição suave. A ação mais importante é garantir que está em conformidade com a política de manutenção do Azure Stack Hub. Os clientes receberão um alerta no portal de administrador do Azure Stack Hub e serão obrigados a atualizar o diretório doméstico e todos os diretórios de hóspedes a bordo.

A maior parte da migração em si será feita pela experiência integrada de atualização do sistema; haverá um passo manual exigido pelos clientes para conceder novas permissões a essas aplicações, que exigirão permissões globais de administrador em cada diretório AD Azure usado com os seus ambientes Azure Stack Hub. Após o pacote de atualização com estas alterações terminar a instalação, será levantado um alerta no portal de administração que o direciona para completar este passo utilizando os nossos scripts UI ou PowerShell de vários arrendamentos (esta é a mesma operação que executa ao embarcar diretórios adicionais ou fornecedores de recursos; mais informações podem ser encontradas aqui.)

Se utilizar o AD FS como sistema de identidade com o Azure Stack Hub, estas alterações Graph não afetarão diretamente o seu sistema. No entanto, as versões mais recentes de ferramentas como a Azure CLI, Azure PowerShell, etc. exigirão as novas APIs Graph, e não funcionarão. Certifique-se de que utiliza apenas as versões destas ferramentas que são explicitamente suportadas com a sua construção do Azure Stack Hub. Este artigo será atualizado no futuro e listará versões de ferramentas suportadas para Azure Stack Hub para AD FS.

Além do alerta no portal de administração, comunicaremos alterações através das notas de lançamento da atualização e comunicaremos qual o pacote de atualização que requer a atualização do diretório doméstico e todos os diretórios de hóspedes a bordo.

Passos seguintes