Gestione utenti
Gestisci l'accesso degli utenti per IBM Bob on-premises usando Keycloak come identity provider, con federazione LDAP o Active Directory oppure account gestiti localmente.
IBM Bob on-premises include un identity provider Keycloak per l'autenticazione degli utenti e la gestione degli accessi. Gli utenti possono essere federati da un ambiente LDAP o Active Directory esistente, oppure creati direttamente in Keycloak. Indipendentemente da come vengono provisioning, agli utenti deve essere assegnato un ruolo Bob appropriato prima di poter accedere al servizio.
Panoramica
| Concetto | Descrizione |
|---|---|
| Identity provider | Keycloak — deployato e gestito dall'operator Bob. |
| Sorgenti utenti | Gli utenti possono essere creati direttamente in Keycloak o federati da un servizio LDAP o Active Directory. |
| Autenticazione | Gli utenti si autenticano tramite Keycloak usando OpenID Connect (OIDC). Keycloak emette un codice di autorizzazione di breve durata che bob-authn scambia per un bearer token Bob. |
| Autorizzazione | L'accesso alle funzionalità di Bob è governato dai ruoli assegnati agli utenti in Keycloak. |
| Superficie di configurazione | L'integrazione LDAP viene gestita tramite la custom resource BobLDAP usando il comando bobctl configure-idp. |
Tipi di directory LDAP supportati
Bob on-premises supporta qualsiasi servizio di directory conforme a LDAPv3. Il parametro vendor nella configurazione LDAP determina il template del provider Keycloak da utilizzare, che definisce le impostazioni specifiche del protocollo per il tipo di directory selezionato.
Valore vendor | Tipo di directory |
|---|---|
other | OpenLDAP e altri servizi di directory generici compatibili con LDAPv3 |
ad | Microsoft Active Directory |
rhds | Red Hat Directory Server |
tivoli | IBM Security Directory Server (già Tivoli Directory Server) |
edirectory | NetIQ / Micro Focus eDirectory |
Architettura di autenticazione e federazione
Quando un utente accede, Bob passa la richiesta a Keycloak, che gestisce l'autenticazione. Tutti gli utenti si autenticano tramite Keycloak. La federazione LDAP è opzionale ed è attiva solo se configurata.
- Federazione LDAP abilitata: Keycloak autentica gli utenti direttamente nella directory LDAP. Le password degli utenti rimangono nella directory LDAP e non vengono memorizzate in Keycloak.
- Federazione LDAP disabilitata: Keycloak autentica gli utenti usando il repository locale di Keycloak.
Flusso di autenticazione
- L'utente inserisce le credenziali.
- Keycloak autentica l'utente.
- Keycloak emette un codice di autorizzazione di breve durata.
bob-authnscambia il codice di autorizzazione per un bearer token Bob.- Tutte le richieste API successive usano il token emesso da Bob.
Comportamento della sincronizzazione utenti
Bob on-premises supporta due modalità di sincronizzazione, configurate tramite l'impostazione userSync.enabled nella configurazione LDAP:
| Modalità | userSync.enabled | Comportamento |
|---|---|---|
| On-demand | false (predefinito) | Gli utenti vengono importati in Keycloak solo quando accedono correttamente per la prima volta, eliminando il requisito di una scansione iniziale della directory. Questa opzione è consigliata per ambienti di directory molto grandi. |
| Eager sync (consigliato) | true | Quando viene registrato un provider LDAP, una sincronizzazione completa una tantum importa tutti gli utenti dalla directory. Dopo l'importazione iniziale, Keycloak sincronizza automaticamente gli aggiornamenti degli utenti ogni cinque minuti. Questo approccio garantisce che tutti gli utenti siano immediatamente disponibili e che gli account amministratore specificati tramite adminEmails possano essere provisioning senza richiedere l'accesso degli utenti. |
Sincronizzazione on-demand
Usa questa modalità per directory molto grandi in cui l'importazione immediata di tutti gli utenti non è pratica.
Durante il primo tentativo di autenticazione:
- L'utente viene importato in Keycloak.
- L'utente viene sottoposto a provisioning in Bob tramite SCIM.
- Il primo tentativo di accesso fallisce a causa della latenza di provisioning.
- L'utente può accedere correttamente al termine del provisioning.
Sincronizzazione eager
Consigliata per la maggior parte dei deployment. Tutti gli utenti diventano disponibili immediatamente al termine della sincronizzazione e non è necessario che accedano per essere sottoposti a provisioning.
L'intervallo di sincronizzazione è attualmente fisso a 5 minuti.
Sincronizzazione degli utenti con SCIM
IBM Bob on-premises utilizza un plugin SCIM 2.0 personalizzato incorporato in Keycloak per sincronizzare gli account utente tra Keycloak e Bob. L'operator Bob configura questa integrazione automaticamente e non è richiesta alcuna configurazione aggiuntiva.
Come funziona la sincronizzazione degli utenti
Quando si verifica un evento del ciclo di vita di un utente in Keycloak, il plugin SCIM invia l'evento corrispondente al servizio bob-admin. Bob aggiorna quindi l'accesso utente e le informazioni del profilo in base all'evento.
Questa sincronizzazione si applica a tutti gli utenti gestiti da Keycloak, inclusi gli utenti federati LDAP e gli utenti creati direttamente nella console di amministrazione di Keycloak.
| Evento utente | Azione Bob |
|---|---|
| Utente creato o primo accesso | Effettua il provisioning dell'utente e concede l'accesso a Bob |
| Utente aggiornato | Sincronizza le modifiche del profilo |
| Utente rimosso da LDAP | Revoca l'accesso a Bob mantenendo i dati dell'utente |
La rimozione di un utente da LDAP revoca il suo accesso a Bob ma non elimina i suoi dati. Se l'utente viene aggiunto nuovamente alla directory, l'accesso viene ripristinato e il lavoro precedentemente creato rimane disponibile.
Verifica della sincronizzazione
Bob non fornisce attualmente una condizione di stato o un health check che confermi che la sincronizzazione SCIM è attiva. Per verificare che il provisioning funzioni, crea o importa un utente di test e conferma che l'utente appaia in Bob dopo il primo accesso o dopo l'importazione iniziale di userSync.
Gestione dei ruoli e dell'appartenenza ai gruppi
IBM Bob usa i gruppi Keycloak per controllare i ruoli degli utenti. L'operator Bob crea e mantiene automaticamente i gruppi richiesti e le mappature dei ruoli.
| Gruppo Keycloak | Ruolo Keycloak assegnato | Chi viene aggiunto |
|---|---|---|
bob-users | bob-user | Tutti gli utenti autenticati vengono aggiunti automaticamente al loro primo accesso riuscito tramite il gruppo predefinito del realm. |
bob-admins | bob-admin | Gli utenti specificati nel campo adminEmails della configurazione BobLDAP vengono assegnati automaticamente dall'operator durante ogni ciclo di riconciliazione. |
Accesso amministratore
Tutti gli utenti autenticati ricevono l'accesso standard a Bob.
Per concedere privilegi amministratori:
- Aggiungi l'indirizzo email dell'utente in
adminEmailsnel file di configurazione IDP. - Applica la modifica:
./bobctl configure-idp --config my-idp.yaml
Per revocare i privilegi amministratori:
- Rimuovi l'indirizzo email da
adminEmails. - Riapplica la configurazione.
bobctl configure-idp è l'unico metodo supportato per la gestione dell'accesso amministratore a Bob. L'aggiunta di un indirizzo email in adminEmails non crea un account utente — l'utente deve già esistere in Keycloak tramite la federazione LDAP o la creazione diretta.
Amministrazione di Keycloak
Bob on-premises include un deployment Keycloak che fornisce servizi di gestione delle identità e degli accessi. L'amministrazione di Keycloak è separata dall'amministrazione di Bob e ogni interfaccia ha uno scopo diverso.
Interfacce di amministrazione
| Interfaccia | URL | Scopo |
|---|---|---|
| Console di amministrazione Keycloak | https://bob-keycloak.<namespace>.<ingress-domain> | Gestisci l'infrastruttura Keycloak, utenti, gruppi, identity provider e impostazioni di federazione. |
| Bob Admin UI | https://bob.<namespace>.<ingress-domain>/admin | Gestisci utenti, ruoli, inviti e impostazioni specifiche del tenant Bob. |
L'operator Bob crea automaticamente entrambe le route durante l'installazione.
I log delle attività non sono disponibili nella Bob Admin UI per questa release. Per accedere ai log del servizio, visualizza i log dei pod per il servizio di autenticazione, il servizio di autorizzazione e il servizio amministrativo direttamente dalla console OpenShift Container Platform o dalla CLI. Per ulteriori informazioni, vedere Limitazioni note.
Accesso alla console di amministrazione Keycloak
Per trovare la route Keycloak nel tuo cluster, esegui:
oc get route -n <instance-namespace> | grep keycloakRecupera le credenziali amministratore iniziali dal secret del cluster:
oc get secret bob-keycloak-initial-admin \
-n <instance-namespace> \
-o jsonpath='{.data.username}' | base64 -d && echooc get secret bob-keycloak-initial-admin \
-n <instance-namespace> \
-o jsonpath='{.data.password}' | base64 -d && echoNon modificare il secret bob-keycloak-initial-admin. L'operator Bob usa queste credenziali durante la riconciliazione. La modifica delle credenziali memorizzate può interrompere le funzionalità gestite dall'operator.
Se hai bisogno di un account amministratore personale, accedi con le credenziali amministratore iniziali e crea un utente separato nel realm master per le attività amministrative correnti.
Dopo aver effettuato l'accesso, passa al realm bob usando il selettore del realm nell'angolo in alto a sinistra della console Keycloak. Tutti gli utenti, i gruppi, gli identity provider e i provider di federazione Bob vengono gestiti da questo realm.
Comprensione dei realm Keycloak
Un realm è un dominio di gestione isolato che contiene i propri utenti, credenziali, ruoli, gruppi e identity provider.
Bob on-premises usa due realm:
| Realm | Scopo |
|---|---|
| master | Riservato all'amministrazione di Keycloak. Gli utenti in questo realm possono amministrare Keycloak ma non possono accedere a Bob. |
| bob | Contiene tutti gli utenti, i gruppi, i provider di federazione LDAP e i client applicativi Bob. L'operator Bob crea e gestisce questo realm. |
I due realm sono completamente indipendenti. L'appartenenza o i privilegi in un realm non concedono accesso alle risorse nell'altro.
Il realm bob è gestito dall'operator. Puoi apportare modifiche dirette tramite la console Keycloak, ma il supporto IBM è limitato alla risoluzione di problemi che interessano l'autenticazione e l'accesso a Bob.
Gestione dei provider di federazione LDAP
I provider di federazione LDAP configurati tramite bobctl configure-idp o la custom resource BobLDAP sono visibili nella sezione User Federation del realm bob.
L'operator Bob registra i provider LDAP quando vengono creati. Le modifiche successive apportate direttamente nella console Keycloak non vengono sincronizzate nuovamente nella custom resource BobLDAP corrispondente.
Per una gestione coerente della configurazione, usa la custom resource BobLDAP e i comandi bobctl configure-idp quando possibile.
Considerazioni sulla sicurezza
Segui queste raccomandazioni quando amministri Keycloak:
- Limita l'accesso al secret
bob-keycloak-initial-adminagli amministratori del cluster. - Esegui le attività di amministrazione di Bob nel realm
bob. - Usa il realm
mastersolo per l'amministrazione dell'infrastruttura Keycloak. - Non creare realm o client aggiuntivi a meno che non sia esplicitamente richiesto e supportato.
- Gestisci la federazione LDAP tramite risorse
BobLDAPinvece di modificare direttamente le impostazioni del provider nella console Keycloak. - Tratta l'account amministratore iniziale come account di emergenza o bootstrap e usa account amministratore personali dedicati per l'amministrazione di routine.
Gestione degli utenti Keycloak diretti
Gli utenti possono essere creati e gestiti direttamente in Keycloak senza integrare una directory LDAP. Questo approccio è adatto per ambienti proof-of-concept, deployment su piccola scala o installazioni in cui non è disponibile un server LDAP. Per gli ambienti di produzione che già utilizzano un servizio di directory aziendale, la federazione LDAP è l'approccio consigliato.
Aggiunta di un utente
Per creare un utente locale, apri la sezione Users nel realm bob e crea un nuovo account utente. Dopo aver salvato l'utente, configura una password e assegna le appartenenze ai gruppi appropriate:
- Aggiungi l'utente a bob-users per concedere l'accesso standard.
- Aggiungi l'utente sia a bob-users che a bob-admins per concedere l'accesso amministrativo.
Gestione delle password
Le password per gli utenti gestiti localmente vengono amministrate tramite la console di amministrazione Keycloak. Apri il record dell'utente e usa la scheda Credentials per creare, aggiornare o reimpostare la password dell'utente.
Rimozione di un utente
Per rimuovere l'accesso a un utente, apri il record dell'utente nella console di amministrazione Keycloak ed elimina o disabilita l'account. Gli utenti disabilitati non possono più autenticarsi, mentre le loro informazioni utente rimangono disponibili nel sistema.