Tutorial - Personalize o fornecimento de produtos de fornecimento de utilizadores para aplicações SaaS em Azure Ative Directory

Microsoft Azure AD fornece suporte para o fornecimento de utilizadores a aplicações SaaS de terceiros, tais como Salesforce, Suíte G e outros. Se ativar o fornecimento de um pedido saaS de terceiros, o portal do Azure controla os valores dos seus atributos através de mapeamentos de atributos.

Antes de começar, certifique-se de que está familiarizado com a gestão de aplicações e conceitos de Sign-On (SSO). Confira os seguintes links:

Há um conjunto pré-configurado de atributos e mapeamentos de atributos entre Azure AD objetos de utilizador e objetos de utilizadores de cada aplicação SaaS. Algumas aplicações gerem outros tipos de objetos juntamente com os Utilizadores, como grupos.

Pode personalizar os mapeamentos de atributos padrão de acordo com as necessidades do seu negócio. Assim, pode alterar ou eliminar os mapeamentos de atributos existentes ou criar novos mapeamentos de atributos.

Edição de mapeamentos de atributos do utilizador

Siga estes passos para aceder à funcionalidade Mappings do fornecimento do utilizador:

  1. Inscreva-se no portal Azure Ative Directory.

  2. Selecione aplicações Enterprise a partir do painel esquerdo. É mostrada uma lista de todas as aplicações configuradas, incluindo aplicações que foram adicionadas da galeria.

  3. Selecione qualquer aplicação para carregar o painel de gestão de aplicações, onde pode ver relatórios e gerir as definições de aplicações.

  4. Selecione Provisioning para gerir as definições de provisão de conta de utilizador para a aplicação selecionada.

  5. Expandir mapeamentos para visualizar e editar os atributos do utilizador que fluem entre Azure AD e a aplicação alvo. Se a aplicação-alvo o suportar, esta secção permite configurar opcionalmente o fornecimento de grupos e contas de utilizador.

    Use Mappings to view and edit user attributes

  6. Selecione uma configuração mapping para abrir o ecrã de mapeamento de atributos relacionado. Alguns mapeamentos de atributos são necessários por uma aplicação SaaS para funcionar corretamente. Para os atributos necessários, a função Eliminar não está disponível.

    Use Attribute Mapping to configure attribute mappings for apps

    Nesta imagem, pode ver que o atributo Username de um objeto gerido em Salesforce é preenchido com o valor do nome do utilizadorPrincipalName do Objeto Azure Ative Directory ligado.

    Nota

    A Clearing Create não afeta os utilizadores existentes. Se a Create não estiver selecionada, não pode criar novos utilizadores.

  7. Selecione um mapeamento de atributos existente para abrir o ecrã EditAr Atributo . Aqui pode editar os atributos do utilizador que fluem entre Azure AD e a aplicação-alvo.

    Use Edit Attribute to edit user attributes

Compreender tipos de mapeamento de atributos

Com os mapeamentos de atributos, você controla como os atributos são povoados numa aplicação SaaS de terceiros. Existem quatro tipos de mapeamento diferentes suportados:

  • Direto – o atributo alvo é povoado com o valor de um atributo do objeto ligado em Azure AD.
  • Constante – o atributo alvo é preenchido com uma cadeia específica especificada.
  • Expressão - o atributo alvo é povoado com base no resultado de uma expressão semelhante ao script. Para mais informações, consulte "Escrever Expressões" para Attribute-Mappings em Azure Ative Directory.
  • Nenhum - o atributo alvo é deixado sem modificação. No entanto, se o atributo alvo estiver sempre vazio, é preenchido com o valor padrão que especifica.

Juntamente com estes quatro tipos básicos, os mapeamentos de atributos personalizados suportam o conceito de uma atribuição de valor padrão opcional. A atribuição de valor predefinido garante que um atributo alvo é povoado com um valor se não houver um valor na Azure AD ou no objeto alvo. A configuração mais comum é deixar este em branco.

Compreender propriedades de mapeamento de atributos

Na secção anterior, já foi introduzido na propriedade do tipo de mapeamento de atributos. Juntamente com esta propriedade, os mapeamentos de atributos também suportam os seguintes atributos:

  • Atributo de origem - O atributo do utilizador a partir do sistema de origem (exemplo: Azure Ative Directory).
  • Atributo-alvo – O atributo do utilizador no sistema alvo (exemplo: ServiceNow).
  • Valor predefinido se nulo (opcional) - O valor que será passado para o sistema-alvo se o atributo de origem for nulo. Este valor só será a provisionado quando um utilizador for criado. O "valor predefinido quando nulo" não será previsto ao atualizar um utilizador existente. Se, por exemplo, pretender doar todos os utilizadores existentes no sistema-alvo com um determinado Título de Trabalho (quando é nulo no sistema de origem), pode utilizar a seguinte expressão: Switch(IsPresent([jobTitle]), "DefaultValue", "True", [jobTitle]). Certifique-se de que substitui o "Valor Predefinido" pelo que pretende prever quando forlo nulo no sistema de origem.
  • Corresponda os objetos que utilizam este atributo – Se este mapeamento deve ser utilizado para identificar exclusivamente os utilizadores entre os sistemas de origem e alvo. É normalmente definido no nome de utilizadorPrincipalName ou atributo de correio em Azure AD, que é tipicamente mapeado para um campo de nome de utilizador numa aplicação alvo.
  • Precedência correspondente - Podem ser definidos múltiplos atributos correspondentes. Quando há múltiplos, são avaliados na ordem definida por este campo. Assim que um fósforo é encontrado, não são avaliados mais atributos correspondentes. Embora possa definir quantos atributos correspondentes quiser, considere se os atributos que está a usar como atributos correspondentes são verdadeiramente únicos e precisam de ser atributos correspondentes. Geralmente, os clientes têm 1 ou 2 atributos correspondentes na sua configuração.
  • Aplique este mapeamento
    • Sempre – Aplique este mapeamento tanto na criação do utilizador como nas ações de atualização.
    • Apenas durante a criação - Aplique este mapeamento apenas nas ações de criação de utilizadores.

Utilizadores correspondentes nos sistemas de origem e alvo

O serviço de prestação de Azure AD pode ser implementado tanto em cenários de "campo verde" (onde os utilizadores não existem no sistema-alvo) como em cenários "brownfield" (onde os utilizadores já existem no sistema-alvo). Para suportar ambos os cenários, o serviço de fornecimento utiliza o conceito de atributos correspondentes. Os atributos correspondentes permitem-lhe determinar como identificar um utilizador de forma única na fonte e corresponder ao utilizador no alvo. Como parte do planeamento da sua implementação, identifique o atributo que pode ser usado para identificar exclusivamente um utilizador nos sistemas de origem e alvo. Coisas a notar:

  • Os atributos correspondentes devem ser únicos: Os clientes usam frequentemente atributos como userPrincipalName, mail ou object ID como o atributo correspondente.
  • Vários atributos podem ser usados como atributos correspondentes: Pode definir vários atributos a avaliar ao combinar utilizadores e a ordem na qual são avaliados (definidos como precedência correspondente na UI). Se, por exemplo, definir três atributos como atributos correspondentes, e um utilizador for exclusivamente compatível após a avaliação dos dois primeiros atributos, o serviço não avaliará o terceiro atributo. O serviço avaliará os atributos correspondentes na ordem especificada e deixará de avaliar quando uma correspondência for encontrada.
  • O valor na fonte e no alvo não tem de corresponder exatamente: O valor no alvo pode ser uma função simples do valor na fonte. Assim, pode-se ter um atributo e-mailApo na fonte e no userPrincipalName no alvo, e corresponder por uma função do atributo emailAddress que substitui alguns caracteres por algum valor constante.
  • A correspondência com base numa combinação de atributos não é suportada: A maioria das aplicações não suporta consultas com base em duas propriedades. Portanto, não é possível combinar com base numa combinação de atributos. É possível avaliar propriedades individuais após outra.
  • Todos os utilizadores devem ter um valor para pelo menos um atributo correspondente: Se definir um atributo correspondente, todos os utilizadores devem ter um valor para esse atributo no sistema de origem. Se, por exemplo, definir o nome de utilizadorPrincipal como o atributo de correspondência, todos os utilizadores devem ter um nome de utilizadorPrincipal. Se definir vários atributos de correspondência (por exemplo, extensãoTribute1 e correio), nem todos os utilizadores têm de ter o mesmo atributo de correspondência. Um utilizador pode ter uma extensãoAtribute1 mas não correio enquanto outro utilizador pode ter correio, mas sem extensãoAttribute1.
  • A aplicação-alvo deve suportar a filtragem no atributo correspondente: Os desenvolvedores de aplicações permitem a filtragem de um subconjunto de atributos no seu utilizador ou grupo API. Para aplicações na galeria, garantimos que o mapeamento de atributos predefinidos é para um atributo que a API da aplicação-alvo suporta a filtragem. Ao alterar o atributo de correspondência padrão para a aplicação-alvo, consulte a documentação da API de terceiros para garantir que o atributo pode ser filtrado.

Edição de atributos de grupo-mapeamentos

Um número selecionado de aplicações, tais como ServiceNow, Box e G Suite, suportam a capacidade de fornecer objetos de grupo e objetos do utilizador. Os objetos de grupo podem conter propriedades de grupo, tais como nomes de exibição e pseudónimos de e-mail, juntamente com membros do grupo.

Example shows ServiceNow with provisioned Group and User objects

O provisionamento em grupo pode ser opcionalmente ativado ou desativado selecionando o mapeamento de grupo em Mapeamento, e definição Ativada à opção desejada no ecrã de Mapeamento do Atributo .

Os atributos previstos como parte dos objetos do Grupo podem ser personalizados da mesma forma que os objetos do Utilizador, descritos anteriormente.

Dica

O fornecimento de objetos de grupo (propriedades e membros) é um conceito distinto de atribuir grupos a uma aplicação. É possível atribuir um grupo a uma aplicação, mas apenas disposição dos objetos de utilizador contidos no grupo. O fornecimento de objetos de grupo completos não é necessário utilizar grupos em atribuições.

Edição da lista de atributos suportados

Os atributos do utilizador suportados para uma determinada aplicação são pré-configurados. A maioria das APIs de gestão de utilizadores da aplicação não suportam a descoberta de esquemas. Assim, o serviço de fornecimento Azure AD não é capaz de gerar dinamicamente a lista de atributos suportados fazendo chamadas para a aplicação.

No entanto, algumas aplicações suportam atributos personalizados, e o serviço de fornecimento de Azure AD pode ler e escrever para atributos personalizados. Para introduzir as suas definições no portal do Azure, selecione a caixa de verificação de opções avançadas do Show na parte inferior do ecrã de mapeamento do atributo e, em seguida, selecione editar a lista de atributos editar para a sua aplicação.

As aplicações e sistemas que suportam a personalização da lista de atributos incluem:

  • Salesforce
  • ServiceNow
  • Dia de trabalho para Diretório Ativo / Dia de Trabalho a Azure Ative Directory
  • SuccessFactors para Ative Directory / SuccessFactors to Azure Ative Directory
  • Azure Ative Directory (Azure AD Graph API são suportados atributos predefinidos e extensões de diretório personalizado). Saiba mais sobre a criação de extensões e limitações conhecidas.
  • Aplicativos que suportam SCIM 2.0
  • Para Azure Ative Directory writeback para Workday ou SuccessFactors, é suportado para atualizar metadados relevantes para atributos suportados (XPATH e JSONPath), mas não é suportado para adicionar novos atributos Workday ou SuccessFactors além dos incluídos no esquema padrão

Nota

A edição da lista de atributos suportados é apenas recomendada para administradores que tenham personalizado o esquema das suas aplicações e sistemas, e que tenham conhecimento em primeira mão de como os seus atributos personalizados foram definidos ou se um atributo de origem não é exibido automaticamente no Portal Azure UI. Isto por vezes requer familiaridade com as APIs e ferramentas de desenvolvimento fornecidas por uma aplicação ou sistema. A capacidade de editar a lista de atributos suportados é bloqueada por padrão, mas os clientes podem ativar a capacidade navegando para o seguinte URL: https://portal.azure.com/?Microsoft_AAD_Connect_Provisioning_forceSchemaEditorEnabled=true . Em seguida, pode navegar para a sua aplicação para ver a lista de atributos como descrito acima.

Ao editar a lista de atributos suportados, são fornecidas as seguintes propriedades:

  • Nome - O nome do sistema do atributo, tal como definido no esquema do objeto-alvo.
  • Tipo - O tipo de dados que o atributo armazena, tal como definido no esquema do objeto-alvo, que pode ser um dos seguintes tipos:
    • Binário - O atributo contém dados binários.
    • Boolean - Atributo contém um valor verdadeiro ou falso.
    • DataTime - O atributo contém uma cadeia de datas.
    • Inteiro - Atributo contém um inteiro.
    • Referência - O atributo contém um ID que faz referência a um valor armazenado noutra tabela na aplicação-alvo.
    • String - Atributo contém uma cadeia de texto.
  • Chave Primária? - Se o atributo é definido como um campo chave primário no esquema do objeto alvo.
  • Necessário? - Se o atributo é necessário para ser povoado na aplicação ou sistema alvo.
  • Multi-valor? - Se o atributo suporta vários valores.
  • Caso exato? - Se os valores dos atributos são avaliados de forma sensível ao caso.
  • Expressão API - Não utilize, a menos que seja instruído pela documentação de um conector específico de provisionamento (como o Workday).
  • Atributo de objeto referenciado - Se for um atributo do tipo de referência, este menu permite selecionar a tabela e atribuir na aplicação-alvo que contém o valor associado ao atributo. Por exemplo, se tiver um atributo chamado "Departamento" cujo valor armazenado referencia um objeto numa tabela separada de "Departamentos", escolherá "Departments.Name". As tabelas de referência e os campos de ID primários suportados para uma determinada aplicação são pré-configurados e atualmente não podem ser editados usando o portal do Azure, mas podem ser editados usando o Microsoft Graph API.

Provisionando um atributo de extensão personalizada a uma aplicação compatível com o SCIM

O SCIM RFC define um esquema de utilizador e grupo principal, ao mesmo tempo que permite extensões ao esquema para atender às necessidades da sua aplicação. Para adicionar um atributo personalizado a uma aplicação SCIM:

  1. Inscreva-se no portal Azure Ative Directory, selecione Aplicações empresariais, selecione a sua aplicação e, em seguida, selecione Provisioning.
  2. Em Mapeamentos, selecione o objeto (utilizador ou grupo) para o qual pretende adicionar um atributo personalizado.
  3. Na parte inferior da página, selecione Mostrar opções avançadas.
  4. Selecione a lista de atributos editar para AppName.
  5. Na parte inferior da lista de atributos, insira informações sobre o atributo personalizado nos campos fornecidos. Em seguida, selecione Adicionar Atributo.

Para aplicações SCIM, o nome do atributo deve seguir o padrão indicado no exemplo abaixo. O "CustomExtensionName" e "CustomAttribute" podem ser personalizados de acordo com os requisitos da sua aplicação, por exemplo: urna:ietf:params:scim:schemas:extension:CustomExtensionName:2.0:User:CustomAttribute

Estas instruções só são aplicáveis às aplicações ativadas pelo SCIM. Aplicações como o ServiceNow e Salesforce não estão integradas com Azure AD usando o SCIM, pelo que não requerem este espaço de nome específico ao adicionar um atributo personalizado.

Os atributos personalizados não podem ser atributos referenciais, atributos multi-valor ou complexos. Os atributos personalizados de extensão multi-valor e complexos são atualmente suportados apenas para aplicações na galeria. O cabeçalho de esquema de extensão personalizado é omitido no exemplo abaixo, uma vez que não é enviado em pedidos do Azure AD cliente SCIM. Esta questão será corrigida no futuro e o cabeçalho será enviado no pedido.

Exemplo de representação de um utilizador com um atributo de extensão:

   {
     "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User",
     "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],
     "userName":"bjensen",
     "id": "48af03ac28ad4fb88478",
     "externalId":"bjensen",
     "name":{
       "formatted":"Ms. Barbara J Jensen III",
       "familyName":"Jensen",
       "givenName":"Barbara"
     },
     "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
     "employeeNumber": "701984",
     "costCenter": "4130",
     "organization": "Universal Studios",
     "division": "Theme Park",
     "department": "Tour Operations",
     "manager": {
       "value": "26118915-6090-4610-87e4-49d8ca9f808d",
       "$ref": "../Users/26118915-6090-4610-87e4-49d8ca9f808d",
       "displayName": "John Smith"
     }
   },
     "urn:ietf:params:scim:schemas:extension:CustomExtensionName:2.0:User": {
     "CustomAttribute": "701984",
   },
   "meta": {
     "resourceType": "User",
     "created": "2010-01-23T04:56:22Z",
     "lastModified": "2011-05-13T04:42:34Z",
     "version": "W\/\"3694e05e9dff591\"",
     "location":
 "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646"
   }
 }

Provisionar um papel a uma aplicação SCIM

Utilize os passos abaixo para as funções de provisão para um utilizador à sua aplicação. Note que a descrição abaixo é específica para aplicações SCIM personalizadas. Para aplicações de galeria como Salesforce e ServiceNow, utilize os mapeamentos de funções pré-definidos. As balas abaixo descrevem como transformar as Assinaturas AppRole atribuem ao formato que a sua aplicação espera.

  • Mapear uma assinatura appRoleAssigning em Azure AD para um papel na sua aplicação requer que você transforme o atributo usando uma expressão. O atributo appRoleAssignment não deve ser mapeado diretamente a um atributo de papel sem usar uma expressão para analisar os detalhes do papel.

  • Assinatura SingleAppRoleAssignment

    • Quando usar: Utilize a expressão SingleAppRoleAssignment para prever uma única função para um utilizador e especificar o papel primário.
    • Como configurar: Utilize os passos acima descritos para navegar na página de mapeamentos de atributos e use a expressão SingleAppRoleAssignment para mapear para o atributo de funções. Há três atributos de papel para escolher (roles[primary eq "True"].display, roles[primary eq "True"].typee roles[primary eq "True"].value). Pode optar por incluir todos ou todos os atributos de função nos seus mapeamentos. Se quiser incluir mais do que um, basta adicionar um novo mapeamento e incluí-lo como o atributo alvo.

    Add SingleAppRoleAssignment

    • Coisas a considerar

      • Certifique-se de que várias funções não são atribuídas a um utilizador. Não podemos garantir que papel será aussitado.
    • Pedido de exemplo (POST)

      {
        "schemas": [
            "urn:ietf:params:scim:schemas:core:2.0:User"
        ],
        "externalId": "alias",
        "userName": "alias@contoso.OnMicrosoft.com",
        "active": true,
        "displayName": "First Name Last Name",
        "meta": {
             "resourceType": "User"
        },
        "roles": [
           {
                 "primary": true,
                 "type": "WindowsAzureActiveDirectoryRole",
                 "value": "Admin"
           }
        ]
    }
    
    • Saída de exemplo (PATCH)
    "Operations": [
       {
         "op": "Add",
         "path": "roles",
         "value": [
           {
             "value": "{\"id\":\"06b07648-ecfe-589f-9d2f-6325724a46ee\",\"value\":\"25\",\"displayName\":\"Role1234\"}"
           }
         ]
    

O formato de pedido no PATCH e POST difere. Para garantir que o POST e o PATCH são enviados no mesmo formato, pode utilizar a bandeira de funcionalidades aqui descrita.

  • AppRoleAssignmentsComplex

    • Quando usar: Utilize a expressão AppRoleAssignmentsComplex para obter várias funções para um utilizador.

    • Como configurar: Editar a lista de atributos suportados como descrito acima para incluir um novo atributo para funções:

      Add roles

      Em seguida, utilize a expressão AppRoleAssignmentsComplex para mapear o atributo de função personalizada, tal como mostrado na imagem abaixo:

      Add AppRoleAssignmentsComplex

    • Coisas a considerar

      • Todas as funções serão avisadas como primárias = falsas.
      • O POST contém o tipo de função. O pedido PATCH não contém o tipo. Estamos a trabalhar no envio do tipo em pedidos POST e PATCH.
      • AppRoleAssignmentsComplex não é compatível com a definição de âmbito para "Sync Todos os utilizadores e grupos".
    • Produção de exemplo

    {
         "schemas": [
             "urn:ietf:params:scim:schemas:core:2.0:User"
        ],
        "externalId": "alias",
        "userName": "alias@contoso.OnMicrosoft.com",
        "active": true,
        "displayName": "First Name Last Name",
        "meta": {
             "resourceType": "User"
        },
        "roles": [
           {
                 "primary": false,
                 "type": "WindowsAzureActiveDirectoryRole",
                 "display": "Admin",
                 "value": "Admin"
           },
           {
                 "primary": false,
                 "type": "WindowsAzureActiveDirectoryRole",
                 "display": "User",
               "value": "User"
           }
        ]
    }
    

Provisionamento de um atributo multi-valor

Certos atributos, como telefoneS, números e e-mails são atributos de vário valor onde poderá ser necessário especificar diferentes tipos de números de telefone ou e-mails. Utilize a expressão abaixo para atributos de vários valores. Permite especificar o tipo de atributo e mapear que para o Azure AD atributo do utilizador correspondente para o valor.

  • phoneNumbers[type eq "work"].value

  • phoneNumbers[type eq "mobile"].value

  • números de telefone[tipo eq "fax"].valor

    "phoneNumbers": [
         {
           "value": "555-555-5555",
           "type": "work"
        },
        {
           "value": "555-555-5555",
           "type": "mobile"
        },
        {
           "value": "555-555-5555",
           "type": "fax"
        }
    ]
    

Restaurar os atributos padrão e os mapeamentos de atributos

Se precisar de recomeçar e repor os mapeamentos existentes de volta ao seu estado predefinido, pode selecionar a caixa de verificação de mapeamentos predefinidos de Restaurar e guardar a configuração. Ao fazê-lo, define todos os mapeamentos e filtros de deteção como se a aplicação tivesse sido adicionada ao seu inquilino Azure AD da galeria de aplicações.

A seleção desta opção forçará efetivamente a ressincronização de todos os utilizadores enquanto o serviço de fornecimento estiver em execução.

Importante

Recomendamos vivamente que o estatuto de Provisioning seja definido para Off antes de invocar esta opção.

O que deve saber

  • Microsoft Azure AD proporciona uma implementação eficiente de um processo de sincronização. Num ambiente inicializado, apenas os objetos que necessitam de atualizações são processados durante um ciclo de sincronização.
  • A atualização dos mapeamentos de atributos tem um impacto no desempenho de um ciclo de sincronização. Uma atualização da configuração de mapeamento de atributos requer que todos os objetos geridos sejam reavaliados.
  • Uma boa prática recomendada é manter no mínimo o número de alterações consecutivas nos seus mapeamentos de atributos.
  • A adição de um atributo de fotografia a ser aprovisionado numa aplicação não é suportado hoje em dia, uma vez que não é possível especificar o formato para sincronizar a fotografia. Pode solicitar a funcionalidade no User Voice
  • O atributo IsSoftDeleted é frequentemente parte dos mapeamentos padrão para uma aplicação. O IsSoftdeleted pode ser verdade num dos quatro cenários (o utilizador está fora de alcance por não ter sido atribuído à aplicação, o utilizador está fora de alcance por não ter atendedo a um filtro de escotagem, o utilizador foi apagado suavemente em Azure AD, ou a propriedade AccountEnabled é definida como falsa no utilizador). Não é aconselhável remover o atributo IsSoftDeleted dos mapeamentos do seu atributo.
  • O serviço de prestação de Azure AD não suporta o fornecimento de valores nulos.
  • A chave primária, tipicamente "ID", não deve ser incluída como um atributo-alvo nos mapeamentos do seu atributo.
  • O atributo de função normalmente precisa ser mapeado usando uma expressão, em vez de um mapeamento direto. Consulte a secção acima para obter mais detalhes sobre o mapeamento de funções.
  • Embora possa desativar grupos dos seus mapeamentos, os utilizadores incapacitados não são suportados.

Passos seguintes