Configurazione di OpenID Connect SSO (single sign - on) nell'applicazione personalizzata

Utilizza OpenID Connect per SSO (Single Sign - On) per consentire alle applicazioni di verificare l'identità dei suoi utenti in base all'autenticazione eseguita da Verify. Gli utenti non hanno bisogno di registrarsi per un account con l'applicazione. Gli utenti vengono reindirizzati a Verify per il login. Verify verifica le identità degli utenti, invia le informazioni tramite un token ID e conferma con il relying party che gli utenti sono autorizzati ad accedere e utilizzare la risorsa. Questa applicazione utilizza il provider OpenID Connect con endpoint di rilevamento https://<tenant-host>/oidc/endpoint/default/.well-known/openid-configuration.

1. Navigare nella scheda Sign - on .
2. Nel Metodo di accesso, selezionare OpenID Connect 1.0.
3. Fornire Verify le informazioni di base sul relying party.

   Campo	Descrizione
   URL applicazione	Si tratta dell' URL di inizializzazione del single sign-on che viene utilizzato per accedere alla parte facente affidamento su OpenID Connect. L'applicazione utilizza questo URL per richiedere a Verify il token ID che contiene i dettagli dell'utente. Quando gli utenti accedono all'applicazione tramite questo URL, vengono reindirizzati a Verify per l'autenticazione. È possibile ottenere queste informazioni dal relying party quando si configura un provider di autorizzazione o un OpenID Connect sul proprio sito.
   Tipi di concessioni	Indica il meccanismo che il relying party può utilizzare per recuperare il token ID da Verify. Verify supporta i seguenti tipi di concessione: Codice di autorizzazione Nota: il codice di autorizzazione è preseletto come tipo di grant predefinito con PKCE anche selezionato per impostazione predefinita. Implicito Flusso periferica Nota: se si seleziona Flusso dispositivo, è possibile anche creare un codice QR. Autorizzazione basata sul contesto Connessione JWT Nota: se si seleziona JWT bearer, si ha l'opzione di configurare JWKS URI, JWT bearer user identification e JWT bearer default identity source. Per ulteriori informazioni su come utilizzare il tipo di concessione della connessione JWT, consultare Tipi di concessione. Qualsiasi combinazione di codice di autorizzazione, implicito, flusso di dispositivi e ROPC. È necessario selezionare almeno un tipo di grant. Se ROPC è l'unico tipo di grant selezionato, la sezione Politiche di accesso non viene visualizzata. Consultare Tipi di concessione per un confronto rapido dei tipi di concessione supportati e per stabilire quale tipo di concessione impostare per l'applicazione.
   ID client	È l'identificativo pubblico univoco assegnato all' applicazione client, che è il relying party di OpenID Connect . Il server di autorizzazione utilizza queste informazioni per identificare la parte di affidamento e la richiesta di autorizzazione. Queste informazioni vengono generate automaticamente dopo aver salvato l'applicazione OpenID Connect . Devi fornire queste informazioni al relying party quando configuri Verify come provider OpenID Connect nella console di gestione dell'applicazione. La relying party utilizza il client ID ogni volta che richiede un token di accesso.
   Segreto Kubernetes	Il file Kubernetes segreto YAML viene utilizzato per connettersi con Red Hat OpenShift. È necessario scaricare il file YAML segreto Kubernetes per ottenere i metadati.
   Client pubblico (nessun segreto client)	Indica che il client non ha alcun segreto che deve essere fornito dall'applicazione. Nota: Quando selezionate, il campo Client Secret è nascosto e i seguenti algoritmi vengono rimossi dalle opzioni Signature Algoritmo : HS256 HS384 HS512 Generare un segreto client solo se il tipo di client è riservato. I clienti riservati possono mantenere il cliente ID e segreto in modo sicuro e non mostrano queste credenziali a parti non autorizzate. Un segreto client deve essere conosciuto solo all' applicazione client e al server di autorizzazione.
   Segreto client	Questi dati vengono utilizzati insieme al client ID per autenticare la parte relying e per scambiare un codice di autorizzazione per un token ID. Queste informazioni vengono generate automaticamente dopo aver salvato l'applicazione OpenID Connect . Devi fornire queste informazioni al relying party quando configuri Verify come provider OpenID Connect nella console di gestione dell'applicazione.
   Metodo di autenticazione client	Indica il metodo di autenticazione per endpoint come l'endpoint token che richiedono l'autenticazione client. Verifica supporta i seguenti metodi di autenticazione client: Predefinito Di base segreto client POST segreto client JWT segreto client JWT chiave privata Se lasciato come predefinito, entrambi i client segreti di base e POST sono ammessi. Se la parte di affidamento lo supporta, utilizzare il tasto privato JWT come configurazione.
   Convalida JTI asserzione client	Indica se il JTI nell'asserzione client JWT è convalidato per uso singolo. Questa opzione viene visualizzata solo quando viene selezionato il JWT segreto client o il metodo di autenticazione client JWT client.
   Chiavi di verifica della firma consentite	Gli ID chiave di verifica della firma che possono essere utilizzati per verificare l'asserzione del client JWT. Questa opzione viene visualizzata solo quando viene selezionato il metodo di autenticazione client JWT della chiave privata.
   Richiedere verifica PKCE (proof key for code exchange - chiave prova per scambio codice)	PKCE viene utilizzato per mitigare gli attacchi di intercettazione dei codici di autorizzazione. Richiede una sfida di codice prima che il flusso di codice di autorizzazione possa procedere. Questa opzione viene visualizzata solo quando viene selezionato il flusso di concessione del codice di autorizzazione.
   URI di reindirizzamento	È l' URL di callback; l'indirizzo a cui Verify invia la risposta di autenticazione alla parte fidata. Gli utenti vengono reindirizzati a questo URL dopo essere stati autenticati e autorizzati da Verify. È necessario specificare almeno un URI. Se l'URI di callback è il dominio dell'applicazione, può essere il dominio dell'inquilino. Nota: Il dominio può avere un valore jolly. Anche se i caratteri jolly non sono supportati nel percorso URI, il carattere "*" è un carattere di percorso URI valido e viene considerato come una stringa letterale. È possibile aggiungere un massimo di 400 URI. È possibile ottenere queste informazioni dal relying party quando si configura un provider di autorizzazione o un OpenID Connect sul proprio sito.
   URI JWKS	L'URI dove la parte relying pubblica i propri tasti pubblici in formato JSON Web Keys (JWKs). Questo URI è utilizzato per la verifica della firma JWT. Il sistema può rifiutare un URI JWKS non raggiungibile o non rispondente. Il sistema può anche rifiutare l' URL JWKS se la dimensione del JWKS è troppo grande. Se la parte richiedente non pubblica un URI JWKS, è possibile aggiungere al sistema una chiave pubblica sotto forma di certificato X509. Consultare Gestione dei certificati. Il § Friendly Name ` associato al certificato pubblico è il valore dell'intestazione key ID (kid) di JWT.
   Identificazione utente connessione JWT Disponibile solo per il tipo di borsa di studio JWT bearer.	Questa configurazione racconta al sistema come il soggetto JWT bearer oggetto (sub) viene interpretato per identificare l'Utente associato a questo token bearer JWT. Il sub può essere il User ID, il Usernameo il External ID.
   Origine di identità predefinita connessione JWT Disponibile solo per il tipo di borsa di studio JWT bearer.	Se il JWT non specifica il realm, è il realm di origine di identità predefinito che l'utente identificato dal sub appartiene. Quando l'opzione JWT bearer user identification è impostata su User ID, questa impostazione non è applicabile.

   Se si sta modificando un'applicazione esistente, è possibile utilizzare le seguenti opzioni segrete client:

   • Selezionare per visualizzare il segreto del client.
   • Selezionare per nascondere il segreto del client.
   • Selezionare per copiare l'ID o il segreto del client negli appunti.
   • Selezionare per visualizzare i segreti del cliente ruotati.
     • Selezionare uno o più segreti client ruotati dall'elenco e fare clic su Elimina per eliminarli.
   • Selezionare per generare un nuovo segreto del cliente. Usa questa opzione se pensi che il segreto del cliente sia compromesso. Se si rigenera il segreto del cliente, è necessario aggiornare il segreto del client in tutti i client OAuth per l'applicazione.
     • Selezionare la casella di controllo per Mantieni segreto corrente per aggiungere il segreto del client corrente all'elenco dei segreti del client ruotati.
     • Se è selezionata la casella di controllo Mantieni il segreto corrente, scegliere la descrizione del segreto del client e l'ora di scadenza (nell'ora locale del browser). Se non viene selezionato alcun tempo di scadenza, verrà applicata la durata del segreto ruotato del tenant impostata nelle impostazioni dell'applicazione.
     • I segreti del client ruotati sono sottoposti a hash e non possono più essere recuperati in testo normale, ma possono ancora essere utilizzati fino alla data di scadenza selezionata.
     • Dopo la conferma, il segreto del cliente viene immediatamente ruotato. Il nuovo segreto del cliente viene visualizzato sullo schermo.
4. Configurare il token di accesso e la scadenza del token di aggiornamento per limitare il tempo di accesso non autorizzato quando questi token vengono rubati.

   Il token di accesso è utilizzato per autorizzare l'accesso alla risorsa protetta. Dopo la scadenza del token di accesso, l'autorizzazione viene revocata.

   Tabella 1. Impostazioni token

   Campo	Descrizione
   Scadenza token di accesso (sec)	Imposta la durata del tempo in secondi dopo il quale, il token di accesso è scaduto. Impostare una scadenza token di accesso per limitare il tempo in cui un aggressore può accedere alla risorsa con il token rubato quando l' applicazione client è compromessa. Sono ammessi solo numeri interi positivi. Il valore predefinito è 7200 secondi. Il valore minimo consentito è 1 e il massimo è 2147483647 secondi.
   Formato token di accesso	Indica se il token di accesso è prodotto come stringa opaca, ovveroDefaultimpostazione, o in formato JWT.
   Audience	Specifica gli obiettivi che sono i destinatari del token. Questi valori sono elencati nella richiesta aud per i token formattati JWT e nel payload di introspezione come una singola stringa o un array di stringhe.
   Associazione degli attributi Introspection	Questo elenco di mappatura degli attributi è utilizzato per includere i crediti nel payload introspezione e il token di accesso formato JWT.
   Nome attributo	Il nome dell'attributo che la parte dipendente utilizza e richiede da Verify. I seguenti nomi attributo non possono essere utilizzati: aud, exp, groupIds, groupUids, at_hash, c_hash, rt_hash, s_hash, iat, iss, nonce, sub, client_id, grant_id, grant_type e scope.
   Attributi	Elenca tutte le fonti di attributi definite per ogni tipo in Directory > Attributes. Il valore della tua origine attributo selezionata viene assegnato come valore di attributo per il nome attributo relying party definito nel token ID.
   Genera token di aggiornamento	Indica se l' applicazione client può richiedere e utilizzare un token di aggiornamento per ottenere un nuovo token di accesso dal server di autorizzazione del provider di identità OpenID Connect . Utilizzare questa opzione solo se l'applicazione intende utilizzare il token di accesso per eseguire le operazioni utilizzando le API Verify . È necessario ottenere un nuovo token di accesso se il precedente è scaduto. Questa opzione non è rilevante se si seleziona "Implicit" come Grant Type.
   Scadenza token di aggiornamento (sec)	Imposta la durata del tempo in secondi dopo il quale, il token di aggiornamento è scaduto. Questa impostazione determina la frequenza con cui l'utente può riautenticarsi. Impostare la scadenza del token di aggiornamento per garantire che l'utente tenti nuovamente l'operazione SSO (single sign - on) completa su Verify dopo un certo periodo di tempo. Questa opzione viene visualizzata solo se è abilitata Generate Refresh Token. Viene utilizzato un token di aggiornamento per ottenere un nuovo token di accesso per continuare l'accesso alla risorsa protetta. Sono ammessi solo numeri interi positivi. Il valore predefinito è 604800 secondi. Il valore minimo consentito è 1 e il massimo è 2147483647 secondi.
   Rinnova durata del token di aggiornamento	Questa opzione indica se la durata del token di aggiornamento viene rinnovata quando viene utilizzato un token di aggiornamento per ottenere una nuova serie di token. Quando questa casella di controllo viene selezionata, la durata impostata da Refresh Token Scadenza viene rinnovata ogni volta che vengono aggiornati i token di aggiornamento. Se non viene selezionato, il token di aggiornamento rinnovato scade quando viene raggiunto l'originale Refresh Token Scadenza .

5. Specificare le opzioni di firma del token ID e la crittografia . Il relying party utilizza la firma per verificare l'integrità e l'autenticità delle richieste utente contenute nel token e il provider di identità OpenID Connect che ha firmato il token. Il token può essere crittografato in modo che solo la parte di affidamento possa decodificarlo.

   Tabella 2. Opzioni di firma e crittografia

   Campo	Descrizione
   Algoritmo di firma	L'algoritmo che Verify usa per firmare il token ID. L'algoritmo deve corrispondere a quello che il relying party ha registrato con Verify. Scegli tra i seguenti algoritmi di hashing per verificare la firma: HS256 HS384 HS512 ES256 ES384 ES512 PS256 PS384 PS512 RS256 (valore predefinito) RS384 RS512 Nota: Se viene selezionato l'algoritmo di firma ES256 , il certificato deve essere ECDSA con P-256. Se viene selezionato l'algoritmo di firma ES384 , il certificato deve essere ECDSA con P-384. Se viene selezionato l'algoritmo di firma ES512 , il certificato deve essere ECDSA con P-521. Gli algoritmi HS non vengono visualizzati quando si è scelto di non generare un segreto client.
   Certificato di firma	Questa opzione viene visualizzata solo se si seleziona uno degli algoritmi di firma RS, ES o PS . Utilizzare questo certificato per firmare il token ID durante il single sign - on. La selezione predefinita si riferisce al certificato personale predefinito configurato in Sicurezza > Certificati > Certificati personali.
   Algoritmo di codifica	L'algoritmo crittografico utilizzato per crittografare o determinare il valore della chiave di codifica dei contenuti (CEK). Sono supportati i seguenti algoritmi: RSA-OAEP RSA-OAEP-256
   Algoritmo di contenuto	L'algoritmo di codifica dei contenuti che viene utilizzato per eseguire la crittografia autenticata sul testo semplice per produrre il testo di cifratura e il tag di autenticazione. Sono supportati i seguenti algoritmi: A128GCM A192GCM A256GCM
   Chiave di crittografia	L'etichetta del certificato o l'ID chiave della chiave da utilizzare per la crittografia.

6. Associare gli attributi utente che Verify supporta e fornisce al relying party tramite il token ID.
   Verify potrebbe estendere lo schema standard delle richieste JSON per includere attributi aggiuntivi come il ruolo del dipendente, il manager e il reparto.

   Nota: The following attributes are already added to the ID token by default: userType, uniqueSecurityName, displayName, realmName, name, preferred_username, jti, at_hash, ext. Some of these attributes can be removed from the ID token by mapping them to an attribute source that is configured to return no value.

   La sezione Mappature degli attributi è costituita dai seguenti elementi, descritti in Tabella 3.

   • Un'opzione di checkbox per inviare tutti gli attributi utente noti.
   • Opzione per aggiungere i nomi attributo e l'origine attributo corrispondente in Verify.

   Tabella 3. Associazioni attributo

   Informazioni	Descrizioni
   Inviare tutti gli attributi utente noti nel token ID	Quando selezionato, tutti gli attributi delle credenziali utente noti disponibili dall'origine di identità OpenID Connect provider vengono inclusi automaticamente nel token ID. Gli attributi delle credenziali utente note sono costituiti da: Attributi standard Questi attributi provengono dalla Verify Cloud Directory, che include gli attributi integrati visualizzati in Directory > Attributi. Attributi estesi Questi attributi provengono dal provider di identità SAML Enterprise configurato in Autenticazione > Provider di identità. In caso contrario, definire solo gli attributi specifici che la relying party richiede nel token ID. Specificare il nome attributo e l'attributo source.
   Nome attributo	Il nome dell'attributo che la relying party utilizza e richiede da Verify.Non è possibile utilizzare i seguenti nomi attributo: aud, exp, groupIds, groupUids, at_hash, c_hash, rt_hash, s_hash, iat, iss, nonce, client_id, grant_id, grant_type e scope. Se il nome dell'attributo è sub, questa associazione di attributi modifica il valore di sub nella risposta di introspezione, nel token di accesso JWT, nella risposta userinfo e nel token ID.
   Attributi	Elenca tutte le fonti di attributi definite per ogni tipo in Directory > Attributes. Il valore della tua origine attributo selezionata viene assegnato come valore di attributo per il nome attributo relying party definito nel token ID. Nota: Se l' attributo Untagged viene mostrato per il valore dell'attributo source, è perché lo scopo dell'attributo è stato modificato. Le applicazioni esistenti che consumano l'attributo possono continuare a utilizzare l'applicazione fino a quando non si rimappa l'applicazione per utilizzare un attributo diverso a tale scopo. Ad esempio, se la casella di controllo Single sign - on (SSO) viene sdoganata su un attributo esistente, le applicazioni che già consumano quell' attributo per SSO possono continuare ad utilizzarlo per SSO. Lo stesso comportamento si applica alle mappature degli attributi di provisioning quando lo scopo Provisioning viene rimosso.

7. Selezionare le fonti di identità e la politica che determinano come gli utenti possono accedere all'applicazione.
   1. Selezionare le fonti di identità che possono essere utilizzate per firmare in questa applicazione.

      L'impostazione predefinita è quella di consentire l'accesso da tutte le fonti di identità aziendali configurate per l'inquilino. Per limitare le fonti di identità che possono essere utilizzate per collegarsi all'applicazione, selezionare Seleziona fonti di identità supportate specifiche. Selezionare le caselle di controllo per le fonti di identità da cui si desidera consentire l'iscrizione.

   2. Selezionare la normativa che determina come gli utenti possono accedere all'applicazione.
      È possibile continuare ad utilizzare la normativa di accesso predefinita che viene assegnata, ovvero Consenti l'accesso da tutti i dispositivi. In alternativa, è possibile deselezionare la casella di controllo e selezionare per scegliere dall'elenco dei criteri di accesso predefiniti. Quando viene selezionata una politica di accesso, è possibile applicare la politica di accesso ai tipi di concessione API selezionando la check box per ciascun tipo di concessione. Per ulteriori informazioni, vedere Criteri di accesso.
8. Selezionare se chiedere il consenso dell'utente.
   La richiesta di consenso dell'utente può essere aggiunta alle applicazioni Open ID Connect. E'disponibile per tutti i tipi di grant tranne che per le credenziali di Password Proprietario (ROPC). Se ROPC è l'unico tipo di grant selezionato per l'applicazione, l'opzione User Consent è nascosta. Se il default, Chiedi il consenso, rimane selezionato, l'utente viene spinto a consenso esplicito agli ambiti e ai diritti di accesso alle API. L'utente può concedere o negare l'autorizzazione per l'accesso alle API. Le applicazioni Open ID Connect esistenti non richiedono il consenso. È necessario modificare quelle applicazioni se si desidera chiedere il consenso dell'utente. Vedere Gestione dei consensi per le applicazioni.

   Dopo la creazione dell'applicazione, il campo Tipo Coninviato con il valore di Advanced viene visualizzato sotto Chiedi il consenso. Il valore Advanced indica che i consensi dell'utente sono memorizzati in DPCM. Le applicazioni personalizzate OIDC più vecchie visualizzano questo campo dopo aver migrato i loro consensi a DPCM.

9. Opzionale: Limiti ambiti personalizzati.
   Gli ambiti personalizzati possono essere richiesti da un client OIDC/OAuth nei flussi di grant OIDC/OAuth supportati. Se Limitare Gli Ambiti Personalizzati è abilitato, ovvero l'impostazione predefinita, gli ambiti che vengono concessi al client alla fine del flusso sono limitati a quegli ambiti specificati in questa sezione. Se Limitare Gli Ambiti Personalizzati è disabilitato, gli eventuali ambiti personalizzati richiesti vengono concessi quando il flusso si completa.

   Nota: gli ambiti standard openid, profile, email, phonee address non possono essere limitati.
   1. Assicurarsi che la casella di checkbox Limitare Gli Ambiti Personalizzati sia selezionata.
   2. Digita il nome dell'ambito personalizzato che si desidera concedere e una descrizione.
      Il nome di ambito si riferisce all'ambito OAuth2/OIDC richiesto da una party/client di affidamento. La descrizione è una spiegazione amichevole per l'ambito.
      Viene visualizzata un'altra serie di campi di ambito.
   3. Ripetere il passo precedente per ogni ambito personalizzato che si desidera concedere.
10. Opzionale: Concessione i diritti delle API al token di collegamento.
    Limitare l'accesso all'API è l'impostazione predefinita per le nuove applicazioni. L'applicazione non ha diritti token di collegamento. Per concedere i diritti per l'accesso API effettuare i seguenti passaggi.
    1. Selezionare l'icona di modifica.
       Inizia la procedura guidata Modifica client API.
    2. Selezionare le autorizzazioni utente e non utente che si desidera concedere al token di collegamento.
       Se si delinea la casella di checkbox Accesso API Limite , al token viene concessa una serie di titoli predefiniti. Vedere Diritti API del token di accesso predefinito.
    3. Selezionare Salva.
11. Selezionare Salva.