Quando si tratta di modelli di identità, i prodotti B2B sono in una classe a sé. Devono navigare nelle complessità della multi-tenancy soddisfacendo al contempo la richiesta dei clienti aziendali di una gestione unificata delle identità e degli accessi dei dipendenti tra una miriade di servizi e applicazioni. Anche Logto ha incontrato queste esigenze da parte dei clienti. In questo articolo, adotteremo un approccio orientato al prodotto per comprendere l'SSO avviato dal SP e come risponde alle esigenze dei tuoi clienti.
Concetto#
Iniziamo introducendo alcuni elementi chiave che devi comprendere:
- Fornitore di servizi (SP): Le tue applicazioni o servizi, che potrebbero essere una o più app che condividono un singolo sistema di identità.
- Fornitore di identità aziendale (IdP): Il fornitore di identità su cui i tuoi clienti aziendali fanno affidamento per gestire le identità dei dipendenti e le autorizzazioni per le applicazioni. Potrebbero utilizzare diversi fornitori, come Okta, Azure AD, Google Workspace o persino IdP personalizzati.
- Organizzazione del fornitore di servizi (SP Org): Le app B2B spesso supportano la multi-tenancy per le diverse organizzazioni cliente.
- Organizzazione del fornitore di identità (IdP Org): Anche gli IdP supportano la multi-tenancy per le diverse organizzazioni cliente. Idealmente, un'impresa dovrebbe essere in grado di collegare la propria IdP Org a una SP Org, replicando le identità dei dipendenti, ma la realtà può essere più complessa.
- Account utente aziendale: Tipicamente identificato dall'utilizzo di un dominio email aziendale per il login. Questo account email aziendale appartiene infine all'azienda.
Poi, approfondiamo l'SSO e due protocolli chiave:
- Single Sign-On (SSO): L'SSO consente agli utenti di accedere a più servizi o applicazioni con un solo set di credenziali. Semplifica la gestione degli accessi e migliora la sicurezza.
- Protocolli SAML e OIDC: L'SSO si basa su questi protocolli per l'autenticazione e l'autorizzazione, ognuno con i propri vantaggi e svantaggi.
Ci sono due principali meccanismi di attivazione dell'SSO da considerare:
- SSO avviato dall'IdP: Nell'SSO avviato dall'IdP, è il fornitore di identità (IdP) a controllare principalmente il processo di Single Sign-On. Gli utenti iniziano l'autenticazione dall'interfaccia dell'IdP.
- SSO avviato dal SP: Nell'SSO avviato dal SP, è il fornitore di servizi (SP) a prendere l'iniziativa nell'avviare e gestire il processo di Single Sign-On, spesso preferito negli scenari B2B.
Ora, esploriamo in dettaglio l'SSO avviato dal SP.
Livello superficiale: esperienza dell'utente#
Diversamente dai prodotti B2C che possono offrire un paio di pulsanti di accesso fisso con IdP sociali, i prodotti B2B non possono imporre quale specifico IdP aziendale ogni cliente utilizza. Pertanto, gli utenti devono prima dichiarare la propria identità. Dopo aver confermato di essere membri di un'azienda abilitata per l'SSO, vengono reindirizzati al rispettivo IdP aziendale per il login.
Per ottenere questo, devi stabilire sulla pagina di accesso se l'utente ha bisogno di accedere tramite SSO e a quale IdP deve essere reindirizzato. I metodi comuni includono:
- Mappatura del dominio email: Associa un dominio email a un connettore IdP specifico. Ciò riguarda gli utenti con indirizzi email sotto quel dominio. Assicurati della verifica della proprietà del dominio per prevenire configurazioni dannose.
- Mappatura del nome dell'organizzazione: Collega il nome di un'organizzazione a un connettore IdP, affidandosi agli utenti affinché ricordino il nome della loro organizzazione.
- Mappatura dell'email personale dell'utente: Questo ti consente di determinare direttamente se un account utente è abilitato per l'SSO, senza fare affidamento sui domini email o sui nomi delle organizzazioni. Puoi realizzarlo invitando gli utenti manualmente, personalizzando le regole del SSO richiesto, o sincronizzando automaticamente i loro account tramite la sincronizzazione della directory.
Nella progettazione della homepage di accesso, ci sono tipicamente due forme, tra cui puoi scegliere in base al business del tuo prodotto:
- Prodotti B2B: Si raccomanda di visualizzare direttamente i pulsanti dell'SSO per rendere intuitivo ai membri dei tuoi clienti aziendali che devono utilizzare l'SSO.
- Prodotti compatibili con B2C e B2B: Poiché la maggior parte degli utenti non utilizzerà l'SSO, valuta i domini email per determinare se l'SSO è necessario. Puoi ritardare la presentazione della verifica delle credenziali, nascondendola inizialmente e rivelandola una volta confermata l'identità dell'utente.
Complessità sottostante: modello di identità dell'utente#
Tuttavia, integrare l'SSO nel tuo sistema di identità comporta molta più complessità che semplicemente aggiungere un pulsante SSO alla pagina di accesso. Devi considerare molti più fattori.
Le relazioni tra gli elementi chiave sono raramente uno a uno; devi considerare scenari uno-a-molti e persino molti-a-molti. Per esplorare gradualmente queste variazioni:
- Un'IdP Org con più domini email: Se fai affidamento sui domini email per determinare l'identità dell'utente, devi supportare più associazioni di domini.
- Un dominio email corrispondente a più IdP Org: Se un dominio può appartenere a più IdP Org, gli utenti devono scegliere l'IdP che desiderano per il Single Sign-On.
- Un'IdP Org collegato a più SP Org: Considera di fornire la possibilità veloce di collegare un IdP a più SP Org.
- Un account utente in più IdP Org e SP Org: Diverse SP Org possono richiedere la verifica tramite IdP diversi.
Abilitare o disabilitare l'SSO all'interno di un'azienda può cambiare il modo in cui gli utenti si autenticano, richiedendo una transizione sicura e fluida.
- Processo decisionale per l'attivazione dell'SSO: Devono essere prese decisioni su se l'SSO influisce solo su alcune SP Org tenant o su tutte le SP Org tenant. La prima offre flessibilità, mentre la seconda si allinea alla tendenza del controllo delle identità e degli accessi a livello aziendale.
- Considerazioni sul periodo di transizione: Come SP, devi adattarti alle incertezze dei servizi IdP di terze parti. Gli amministratori aziendali devono sempre avere la possibilità di accedere alla tua app tramite SSO o credenziali, come alternativa, e i membri dell'impresa potrebbero necessitarne durante la transizione.
Questi sono solo alcuni punti per affrontare vari scenari; molte altre capacità e dettagli possono essere esplorati.
Conclusione#
Speriamo che questa analisi dell'SSO avviato dal SP ti offra nuove prospettive sulle soluzioni di identità aziendale. La buona notizia è che Logto sta sviluppando diligentemente soluzioni che offrono una configurazione semplice e esperienze di autenticazione SSO pronte all'uso. Resta sintonizzato per la nostra prossima release, in cui approfondiremo ulteriormente le soluzioni specifiche per l'SSO avviato dal SP.
