Dare a ogni persona l’accesso necessario

L’autenticazione stabilisce quale utente accede tramite un account locale o un sistema di identità esterno supportato. L’autorizzazione determina progetti e azioni accessibili a quell’utente Semaphore. Abilitare SSO non assegna automaticamente il ruolo operativo corretto. Progetta entrambi insieme: verifica la connessione delle identità, assegna l’appartenenza prevista e testa le azioni reali con un account rappresentativo prima di delegare un task operativo.

Il ruolo integrato Task Runner può eseguire ogni modello nel progetto. Per delegare solo alcuni job usa un ruolo Enterprise personalizzato con diritti sui Task Template e workflow scelti e senza esecuzione a livello progetto. Tutti i ruoli si sommano: un ruolo più ampio può ancora consentire altri modelli.

Sì. Un ruolo Enterprise combina permessi di progetto e su singoli oggetti. Lascia i primi disattivati e aggiungi solo Task Template e workflow previsti con lettura, esecuzione o modifica, e approvazione per workflow. Un ruolo globale è riusato tra progetti; quello di progetto rimane locale. I ruoli si sommano: verifica l’intero insieme per l’automazione sensibile.

La granularità per singolo oggetto si applica a Task Template e workflow. Non presumere che un permesso di progetto per inventari, repository, gruppi di variabili o Key Store sia limitabile a uno solo di tali oggetti. Usa confini di progetto e modello di ruoli deliberatamente per separare le responsabilità. Se il progetto di accesso richiede altre restrizioni a livello di risorsa, verifica quel requisito preciso prima di affidargli la produzione.

Le opzioni documentate sono account locali, LDAP e Active Directory, OpenID Connect e JWT da un reverse proxy fidato, secondo il confronto attuale delle offerte. L’utente esterno ha ancora un account Semaphore e necessita accesso al progetto. Verifica identificativi dei provider e collegamento degli account prima di modificare un’installazione. Abilitare il provider non mappa automaticamente tutti i gruppi ai ruoli previsti.

Mantieni un percorso locale di recupero amministrativo testato accanto all’autenticazione esterna. Documenta responsabile, posizione delle credenziali e modalità di accesso durante un guasto. Testalo prima di un incidente per evitare di scoprire che tutti gli amministratori dipendono dallo stesso provider indisponibile. Dopo il recupero controlla account e progetti coinvolti, così modifiche temporanee non diventano permessi permanenti involontari.

Sì. Task Runner esegue i modelli lasciando altre risorse in sola lettura. Per job selezionati usa un ruolo Enterprise con diritti su quei modelli e workflow. Verifica tutti i ruoli: i permessi si sommano. Un Task Template preparato mantiene la configurazione disponibile al team.

Guest fornisce accesso di sola lettura al progetto. Un ospite può vedere informazioni e risultati senza eseguire task o cambiare impostazioni. Aggiungi la persona al team corretto e controlla anche gli altri ruoli: uno più ampio assegnato insieme a Guest può concedere ulteriori permessi.

Le mappature Enterprise associano un gruppo del provider OIDC a un ruolo di progetto Semaphore. Configura il claim dei gruppi nel provider e aggiungi la mappatura per progetto e ruolo previsti. Semaphore aggiorna le assegnazioni all’accesso tramite quel provider: le modifiche valgono quindi dall’accesso successivo, non immediatamente per una sessione aperta.

Sì. Abilita TOTP nel server per permettere di registrare un’app locale e usare il codice dopo la password. La registrazione genera un codice di recupero per assenza dell’app. Abilitare non forza tutti a registrarsi: l’adozione è un processo. La stessa area configura un limite assoluto che termina la sessione dopo un tempo fisso indipendentemente dall’attività.