Visão geral da arquitetura de linha de base

A Microsoft frequentemente fala com universidades de pesquisa que operam em ambientes híbridos nos quais os aplicativos são baseados em nuvem ou hospedados localmente. Em ambos os casos, os aplicativos podem usar vários protocolos de autenticação. Em alguns casos, esses protocolos estão chegando ao fim da vida útil ou não estão fornecendo o nível de segurança necessário.

Os aplicativos geram grande parte da necessidade de diferentes protocolos de autenticação e diferentes mecanismos de gerenciamento de identidade (IdM).

Em ambientes universitários de pesquisa, os aplicativos de pesquisa geralmente exigem os requisitos de IdM. Uma universidade pode usar um provedor de federação, como o Shibboleth, como provedor primário de identidade (IdP). Nesse caso, o Microsoft Entra ID geralmente é configurada para federar com o Shibboleth. Se o Microsoft 365 Apps também estiver em uso, a ID do Microsoft Entra permitirá que você configure a integração.

Os aplicativos usados nas universidades de pesquisa operam em várias partes da área geral do volume de TI:

• Os aplicativos de pesquisa e de federação multilateral estão disponíveis através do InCommon e do eduGAIN.

• Os aplicativos de biblioteca fornecem acesso a diários eletrônicos e outros provedores de conteúdo eletrônico.

• Alguns aplicativos usam protocolos de autenticação herdados, como o Serviço Central de Autenticação, para habilitar o logon único.

• Os aplicativos de alunos e docentes geralmente usam vários mecanismos de autenticação. Por exemplo, alguns estão integrados ao Shibboleth ou a outros provedores de federação, enquanto outros estão integrados ao Microsoft Entra ID.

• Os aplicativos do Microsoft 365 estão integrados ao Microsoft Entra ID.

• O Windows Server Active Directory pode estar em uso e sincronizado com o Microsoft Entra ID.

• O Lightweight Directory Access Protocol (LDAP) está em uso em muitas universidades que podem ter um diretório LDAP externo ou um registro de identidade. Esses registros geralmente são usados para hospedar atributos confidenciais, informações de hierarquia de função e até mesmo certos tipos de usuários, como candidatos.

• O Active Directory local, ou um diretório LDAP externo, é frequentemente usado para habilitar a entrada de credencial única para aplicativos que não sejam da Web e várias entradas de sistemas operacionais que não sejam da Microsoft.

Desafios da arquitetura de linha de base

As arquiteturas de linha de base geralmente evoluem ao longo do tempo, introduzindo complexidade e rigidez no design e na capacidade de atualização. Alguns dos desafios do uso da arquitetura de linha de base incluem:

• Difícil reagir aos novos requisitos: Ter um ambiente complexo dificulta a rápida adaptação e o acompanhamento dos regulamentos e requisitos mais recentes. Por exemplo, se você tiver aplicativos em muitos locais e esses aplicativos estiverem conectados de maneiras diferentes com IdMs diferentes, você precisará decidir onde localizar serviços de autenticação multifator e como impor a autenticação multifator.

  O ensino superior também experimentou a propriedade de serviços fragmentos. As pessoas responsáveis pelos principais serviços, como planejamento de recursos corporativos, sistemas de gerenciamento de aprendizado, soluções de divisão e departamento, podem resistir aos esforços para alterar ou modificar os sistemas que operam.

• Não é possível aproveitar todas as funcionalidades do Microsoft 365 para todos os aplicativos (por exemplo, Intune, Acesso Condicional, sem senha): muitas universidades desejam migrar para a nuvem e usar seus investimentos existentes no Microsoft Entra ID. No entanto, com um provedor de federação diferente como seu IdP principal, as universidades não podem aproveitar todos os recursos do Microsoft 365 nos outros aplicativos.

• Complexidade de uma solução: Há muitos componentes a serem gerenciados. Alguns componentes estão na nuvem, e alguns estão no local ou em instâncias de infraestrutura como serviço (IaaS). Os aplicativos são operados em muitos lugares. Do ponto de vista do usuário, essa experiência pode ser desarticulada. Por exemplo, os usuários às vezes veem uma página de entrada do Shibboleth e outras vezes veem uma página de entrada do Microsoft Entra.

Apresentamos três soluções para resolver esses desafios, ao mesmo tempo em que abordamos os seguintes requisitos:

• Capacidade de participar de federações multilaterais, como o InCommon e eduGAIN

• Capacidade de dar todos os tipos de aplicativos (mesmo aplicativos que exigem protocolos herdados)

• Capacidade de dar suporte a diretórios externos e repositórios de atributos

Apresentamos as três soluções em ordem, da mais preferencial para a menos preferencial. Cada uma satisfaz os requisitos, mas introduz decisões de compensação que são esperadas em uma arquitetura complexa. Com base em seus requisitos e ponto de partida, selecione aquele mais adequado ao seu ambiente. Também fornecemos uma árvore de decisões para auxiliar nessa decisão.

Próximas etapas

Confira estes artigos relacionados à federação multilateral:

Introdução à federação multilateral

Solução 1 de federação multilateral: Microsoft Entra ID com Cirrus Bridge

Solução de federação multilateral 2: Microsoft Entra ID com Shibboleth como um proxy Security Assertion Markup Language (SAML)

Solução 3 de federal multilateral: ID do Microsoft Entra com AD FS e Shibboleth

Árvore de decisão da federação multilateral