Integrando o Okta com a federação multilateral InCommon

Introdução à integração do Okta e do InCommon

Para instituições de ensino superior e centros de pesquisa parceiros, a utilização da estrutura InCommon é essencial. Tradicionalmente, a Okta não oferece suporte ao modelo de federação bilateral usado pela InCommon; no entanto, existe uma solução. Este guia fornece uma visão geral técnica e padrões arquitetônicos para integrar um locatário Okta a um modelo de federação multilateral, como o InCommon ou o eduGAIN, permitindo que você participe da Federação InCommon como um provedor de identidade (IdP) ou um provedor de serviços (SP).

Casos de uso de integração principais

Este guia foi desenvolvido para arquitetos de identidade em instituições que usam o Okta como sua principal plataforma de identidade, mas que precisam de interoperabilidade com a comunidade mais ampla de pesquisa e educação (P&E) por meio do InCommon — seja como um provedor de identidade InCommon (IDP) ou um provedor de serviços InCommon (SP).

Vamos explorar dois cenários principais: 

1. Okta como IdP do InCommon: concedendo acesso a recursos de terceiros do InCommon a alunos autenticados em instituições habilitadas para Okta
2. Okta como um SP do InCommon: protegendo **aplicativos** institucionais com o Okta, ao mesmo tempo que permite que a comunidade InCommon em geral tenha acesso a elas

Embora apresentemos o Okta em ambos os lados da transação, os modelos se aplicam a outras soluções de gerenciamento de identidade e acesso (IAM) Enterprise.

Contextualizando a terminologia de federação: IdP vs. SP

O uso dos termos provedor de identidade (IdP) e provedor de serviços (SP), embora apropriado, pode depender do contexto. 

• No padrão arquitetônico 1 (Okta como IdP InCommon): A Okta é o IdP para aplicativos universitários e o IdP para o adaptador de federação, Cirrus Bridge. O adaptador funciona como um SP para a Okta. No entanto, neste caso de uso, o Cirrus Bridge também funciona como um IdP InCommon, permitindo que alunos e professores obtenham SSO para recursos de terceiros que atuam como SPs InCommon. Neste caso, a Okta é um IdP, a Cirrus Bridge é simultaneamente um SP e um IdP, e os recursos de terceiros são SPs.
• No padrão arquitetônico 2 (Okta como SP InCommon): a Okta é o IdP para os aplicativos da instituição de pesquisa usados tanto por alunos quanto por professores da instituição de pesquisa. Ao mesmo tempo, a Okta permite que usuários externos do InCommon acessem o aplicativo.  Para usuários externos do InCommon, o Okta é um SP (provedor de serviços) e o Cirrus Proxy é o IdP (provedor de identidade).  No entanto, o Cirrus Proxy é um SP do InCommon. 

Comparando modelos de federação: bilateral vs. multilateral

Modelo de federação bilateral da Okta

Okta é o serviço IAM líder de mercado, desenvolvido para fornecer acesso à linguagem de marcação de asserções de segurança (SAML), OpenID Connect (OIDC) e aplicativos locais baseados em cabeçalhos. Muitas instituições de ensino superior e de pesquisa utilizam o Okta e, em alguns casos, uma única instituição pode funcionar tanto como IdP quanto como SP. A arquitetura de federação da Okta se baseia em uma relação de confiança ponto a ponto exclusiva, configurada entre um único IdP e um único SP. 

Essa abordagem ponto a ponto é chamada de federação bilateral, que é o modelo padrão usado por todos os principais fornecedores comerciais de IAM. Este modelo proporciona controle granular e é padrão para aplicações Enterprise e aplicativos comerciais. 

Modelo de federação multilateral da InCommon

Em contraste com a abordagem bilateral da Okta, que exige uma conexão específica e pré-configurada para cada parceria de federação, a InCommon opera em um modelo de federação multilateral. Trata-se de uma estrutura de confiança de muitos para muitos que permite que milhares de instituições participantes interoperem sem criar relações bilaterais individuais. 

Um registro central de confiança torna isso possível ao hospedar um serviço de metadados que contém os metadados SAML de todos os membros. A InCommon fornece este registro de confiança como o “Agregado de Metadados SAML Legado” ou como o “Serviço de Consulta de Metadados (MDQ)”. Um SP pode confiar em toda a federação InCommon e, ao consumir esses metadados, aceitar autenticação de qualquer IdP registrado. 

Embora a federação multilateral e o serviço de metadados sejam os maiores diferenciais entre um modelo comercial e o modelo da comunidade de pesquisa e educação, essas não são as únicas diferenças. O InCommon também define requisitos padronizados de autenticação e atributos:

• Expressar afirmações específicas de autenticação multifator (MFA) em conformidade com o Perfil MFA REFEDS. 
• Lançamento de pacotes padronizados de atributos de usuário com base em estruturas de consentimento predefinidas. 

Como o Okta não oferece suporte nativo ao consumo dinâmico de metadados necessário para a federação multilateral, você deve usar um adaptador de federação como intermediário.

A arquitetura do adaptador de federação: um pré-requisito para a integração 

Para conciliar o modelo bilateral da Okta com o modelo multilateral da InCommon, é necessário usar um adaptador especializado tanto no lado do IdP quanto no lado do SP da conexão.  

• Como um IdP InCommon (padrão 1): este adaptador processa o feed de metadados InCommon e se comunica com o Okta por meio de uma conexão SAML bilateral padrão. 
• Como um SP InCommon (padrão 2): este adaptador solicita ao usuário que identifique sua instituição de origem, busca os metadados dessa instituição, gera a solicitação de autenticação correta para essa instituição e, em seguida, consome e valida a afirmação SAML recebida. 

Escolhendo um adaptador: Shibboleth vs. Cirrus Identity

A comunidade de Pesquisa e Educação (R&E) aceita amplamente duas soluções principais de adaptadores: Cirrus Identity e Shibboleth.

• Cirrus Identity: Uma solução comercial baseada em SaaS, projetada especificamente para essa finalidade. Simplifica a implantação e o gerenciamento. A Cirrus oferece duas soluções diferentes: Cirrus Bridge, usada no caso de uso 1 (InCommon IDP); e Cirrus Proxy, usada no caso de uso 2 (InCommon SP). A Cirrus fornece documentação detalhada para essas integrações, que serve como referência principal:

  • Documentação do Cirrus Bridge

  • Documentação do Cirrus Proxy

  • Guia de configuração do Cirrus Bridge específico para Okta

  • Integração da Okta com o Cirrus

• Shibboleth: um projeto de software de código aberto amplamente utilizado na comunidade de P&E. Você pode implantá-lo local ou em uma nuvem privada. O software Shibboleth IdP serve como componente adaptador. Os principais recursos incluem: 

  • Página inicial do Projeto Shibboleth

  • Documentação do provedor de identidade Shibboleth

  • Guia Shibboleth do InCommon

Tanto o Cirrus Identity quanto o Shibboleth funcionarão ao usar a Okta e um adaptador InCommon. A escolha da solução depende das preferências da sua organização.

Padrão de arquitetura 1: Okta como provedor de identidade InCommon

Nesse cenário, uma universidade utiliza o Okta para seus alunos, professores e funcionários. A universidade alimenta o Okta com informações de seus sistemas de alunos e/ou de RH e fornece provisionamento, autenticação única (SSO) e autenticação multifator (MFA) para vários aplicativos, incluindo Google Workspace, Microsoft Entra ID, Canvas e Blackboard. O Okta também provisiona usuários no Active Directory. O objetivo é permitir que os usuários da universidade acessem serviços externos federados pelo InCommon, como periódicos de pesquisa, serviços de biblioteca de terceiros e aplicativos da NSF. 

Configuração da arquitetura

1. A universidade registra o Cirrus Bridge como seu provedor de identidade oficial no registro de confiança InCommon.
2. O Cirrus Bridge está configurado para apontar upstream para o locatário da Okta da universidade como seu IdP SAML autoritativo.
3. A Okta gerencia a autenticação primária do usuário, a aplicação da MFA e o gerenciamento principal do ciclo de vida da identidade.

Como funcionam os fluxos de autenticação para a Okta como IdP

Para um fluxo iniciado pelo IdP, comece com o login opcional 

1. O usuário não autenticado acessa diretamente o painel do usuário do Okta.
2. O usuário clica em um link para o aplicativo InCommon externo de destino.
3. A Okta gera uma afirmação SAML e a envia para o Cirrus Bridge.
4. A Cirrus Bridge traduz a afirmação para um formato multilateral e a repassa para o recurso de destino.

Para um fluxo iniciado pelo SP, não utilize o login opcional e realize o login quando necessário

1. O usuário navega diretamente para o recurso InCommon de terceiros desejado.
2. O recurso redireciona o usuário para o Cirrus Bridge usando a pesquisa de metadados do InCommon.
3. O Cirrus Bridge redireciona o usuário para o Okta para verificação das credenciais principais.
4. Após a autenticação bem-sucedida, o Okta emite um token para o Cirrus Bridge, que redireciona o usuário de volta ao recurso.

Padrão de arquitetura 2: Okta como provedor de serviços InCommon

Nesse cenário, uma instituição de pesquisa utiliza a Okta para proteger o acesso aos seus aplicativos. Em vez de emitir credenciais separadas para cada usuário, a instituição deseja aceitar usuários da Federação InCommon. Isso permite que esses usuários acessem os aplicativos da instituição de pesquisa usando suas próprias credenciais universitárias, sem precisar criar uma nova conta. A instituição de pesquisa também deseja permitir o login direto para sua equipe de pesquisadores. 

Configuração da arquitetura

1. O Cirrus Proxy está registrado como um SP InCommon no registro multilateral.
2. O Okta está configurado para confiar no Cirrus Proxy como um IdP de entrada usando uma configuração SAML bilateral.
3. Os aplicativos de destino permanecem integrados diretamente ao Okta como SSO padrão nos aplicativos.

Descoberta de identidade e fluxos de autenticação

Um componente importante ao habilitar o acesso do InCommon ao Okta é garantir que os usuários façam login pelos caminhos corretos.

Fluxo de login direto para funcionários internos

1. Os funcionários internos de pesquisa acessam o aplicativo diretamente por meio de sua conta Okta.
2. O Okta autentica usuários internos diretamente, sem invocar o pipeline de descoberta externo.

Fluxo de login iniciado pelo SP para usuários externos do InCommon

Um usuário externo acessa o aplicativo diretamente ou a partir do painel de controle de sua universidade. Neste ponto, o usuário pode ser solicitado a fornecer suas credenciais usando uma das duas abordagens abaixo. A abordagem será baseada nos requisitos da instituição.  

1. Usuário > Acessar Recurso > Okta apresenta widget de login com link para a tela de descoberta no Cirrus Proxy 

   • O usuário pode fazer login diretamente pelo widget do Okta ou selecionar “Fazer login com o InCommon”, o que o leva à tela de descoberta do IdP no Cirrus Proxy.

2. Usuário > Acessar Recurso > O Cirrus Proxy apresenta uma página de login com um link para o widget Okta

   • O usuário visualiza imediatamente a tela de descoberta do IDP Cirrus Proxy

   • Os funcionários podem fazer login diretamente pelo widget da Okta

Neste exemplo, o usuário opta por usar o InCommon para autenticação.

1. O usuário é redirecionado para a interface de descoberta do Cirrus Proxy para selecionar sua instituição de origem.
2. O Cirrus Proxy consulta o serviço MDQ, recupera os metadados SAML da instituição de origem e redireciona o usuário para a página de login da sua universidade local.
3. Após o login bem-sucedido na universidade de origem, o IdP de origem envia uma afirmação SAML para o Cirrus Proxy.
4. O Cirrus Proxy valida a afirmação e envia uma afirmação formatada para o Okta, concedendo ao usuário acesso ao aplicativo.

Simplifique sua federação multilateral com a Okta

Integrar o Okta com federações multilaterais não precisa ser complexo. Nossa integração com o Cirrus Federação Bridge permite a autenticação e o provisionamento para usuários finais em instituições de ensino superior e pesquisa. 

Diferentemente de outros kits de ferramentas de gerenciamento de identidade, o Okta não exige que você gaste tempo e Recursos conectando manualmente aplicativos web aos seus diretórios de usuários. Em vez disso, integramos os aplicativos diretamente em nosso serviço, para que você possa simplesmente implantá-los para seus usuários.

Baixe o whitepaper sobre integrações de aplicativos para saber mais sobre como simplificamos as conexões de aplicativos em todo o seu ecossistema.