Aprenda sobre SSO iniciado por SP para aplicativos B2B

Quando se trata de modelos de identidade, os produtos B2B estão em uma categoria à parte. Eles devem navegar pelas complexidades da multi-locação enquanto satisfazem a demanda de clientes empresariais por identidade unificada de funcionários e gerenciamento de acesso em uma infinidade de serviços e aplicativos. Logto também encontrou essas demandas de clientes. Neste artigo, adotaremos uma abordagem orientada ao produto para entender o SSO iniciado por SP e como ele atende às necessidades dos seus clientes.

Conceito#

Vamos começar apresentando alguns elementos-chave que você precisa entender:

• Provedor de serviço (SP): Suas aplicações ou serviços, que podem ser um ou vários aplicativos compartilhando um único sistema de identidade.
• Provedor de identidade empresarial (IdP): O provedor de identidade no qual seus clientes empresariais confiam para gerenciar identidades de funcionários e permissões de aplicativos. Eles podem usar diferentes provedores, como Okta, Azure AD, Google Workspace ou até mesmo IdPs personalizados.
• Organização do provedor de serviço (SP Org): Aplicativos B2B muitas vezes suportam múltiplas locações para diferentes organizações clientes.
• Organização do provedor de identidade (IdP Org): IdPs também suportam múltiplas locações para diferentes organizações de clientes. Idealmente, uma empresa deve ser capaz de vincular seu IdP Org a um SP Org, replicando identidades de funcionários, mas a realidade pode ser mais complexa.
• Conta de usuário empresarial: Normalmente identificada pelo uso de um domínio de e-mail da empresa para login. Esta conta de e-mail empresarial, em última análise, pertence à empresa.

Em seguida, mergulhe no SSO e em dois protocolos-chave:

• Single sign-on (SSO): O SSO permite que os usuários acessem vários serviços ou aplicativos com um único conjunto de credenciais. Ele simplifica o gerenciamento de acesso e melhora a segurança.
• Protocolos SAML e OIDC: O SSO depende desses protocolos para autenticação e autorização, cada um com suas próprias vantagens e desvantagens.

Existem dois principais mecanismos de gatilho de SSO a considerar:

• SSO iniciado por IdP: No SSO iniciado por IdP, o Provedor de Identidade (IdP) controla principalmente o processo de single sign-on. Os usuários iniciam a autenticação a partir da interface do IdP.
• SSO iniciado por SP: No SSO iniciado por SP, o Provedor de Serviço (SP) assume a liderança na iniciação e no gerenciamento do processo de single sign-on, frequentemente preferido em cenários B2B.

Agora, vamos explorar o SSO iniciado por SP em detalhes.

Nível superficial: experiência do usuário#

Ao contrário dos produtos B2C, que podem oferecer alguns botões fixos de login social IdP, os produtos B2B não podem ditar qual IdP empresarial específico cada cliente usa. Portanto, os usuários precisam primeiro declarar sua identidade. Depois de confirmar que eles são membros de uma empresa habilitada para SSO, eles são redirecionados para seu respectivo IdP empresarial para login.

Para conseguir isso, você deve, na página de login, determinar se o usuário precisa fazer login via SSO e para qual IdP ele deve ser redirecionado. Métodos comuns incluem:

1. Mapeamento de domínio de e-mail: Associar um domínio de e-mail a um conector IdP específico. Isso afeta usuários com endereços de e-mail desse domínio. Garantir a verificação de propriedade do domínio para evitar configurações maliciosas.
2. Mapeamento de nome de organização: Vincular o nome de uma organização a um conector IdP, contando com os usuários para lembrar o nome de sua organização.
3. Mapeamento de e-mail pessoal do usuário: Isso permite determinar diretamente se uma conta de usuário está habilitada para SSO, sem depender de domínios de e-mail ou nomes de organizações. Você pode conseguir isso convidando usuários manualmente, personalizando regras de SSO obrigatório ou sincronizando automaticamente suas contas através da sincronização de diretório.

No design da página inicial de login, existem normalmente duas formas, que podem ser escolhidas com base no negócio do seu produto:

1. Produtos B2B: Recomenda-se exibir diretamente os botões de SSO para tornar intuitivo para os membros dos seus clientes empresariais que precisam usar o SSO.
2. Produtos compatíveis com B2C e B2B: Como a maioria dos usuários não usará SSO, avalie os domínios de e-mail para determinar se o SSO é necessário. Você pode atrasar a apresentação da verificação de credenciais, ocultando-a inicialmente e revelando-a uma vez confirmada a identidade do usuário.

Complexidade subjacente: modelo de identidade do usuário#

No entanto, integrar o SSO ao seu sistema de identidade envolve muito mais complexidade do que simplesmente adicionar um botão de SSO à página de login. Você precisa considerar muitos outros fatores.

As relações entre os principais elementos raramente são um-para-um; você precisa considerar cenários de um-para-muitos e até mesmo muitos-para-muitos. Para explorar essas variações gradualmente:

• Uma IdP Org com múltiplos domínios de e-mail: Se você depender de domínios de e-mail para determinar a identidade do usuário, deverá suportar múltiplas associações de domínios.
• Um domínio de e-mail correspondente a múltiplos IdP Orgs: Se um domínio puder pertencer a múltiplos IdP Orgs, os usuários precisarão escolher o IdP que desejam para o single sign-on.
• Uma IdP Org vinculada a múltiplos SP Orgs: Considere fornecer a capacidade rápida de conectar um IdP a múltiplos SP Orgs.
• Uma conta de usuário em múltiplos IdP Orgs e SP Orgs: Diferentes SP Orgs podem exigir verificação através de diferentes IdPs.

Habilitar ou desabilitar o SSO dentro de uma empresa pode alterar a forma como os usuários se autenticam, exigindo uma transição segura e suave.

• Tomada de decisão para ativação de SSO: Decisões precisam ser tomadas sobre se o SSO afeta apenas certos SP Orgs de locatários ou todos os SP Orgs de locatários. O primeiro oferece flexibilidade, enquanto o segundo alinha-se à tendência de identidade e controle de acesso em toda a empresa.
• Considerações durante o período de transição: Como SP, você deve acomodar incertezas nos serviços de IdP de terceiros. Administradores empresariais sempre precisam acessar seu aplicativo via SSO ou credenciais como opção, e membros empresariais podem precisar delas durante a transição.

Esses são apenas alguns pontos para abordar vários cenários; muitas outras capacidades e detalhes podem ser explorados.

Conclusão#

Esperamos que essa análise sobre o SSO iniciado por SP ofereça novas perspectivas sobre soluções de identidade empresarial. A boa notícia é que o Logto está diligentemente desenvolvendo soluções que oferecem configuração simples e experiências de autenticação SSO prontas para uso. Fique atento ao nosso próximo lançamento, onde iremos nos aprofundar em soluções específicas de SSO iniciado por SP.