Prima di poter utilizzare un componente OAuth2Client, OAuth2AccountLink o OAuthAccountLink in una competenza, un amministratore deve registrare un'applicazione riservata (definita anche client OAuth) con IAM o OAM OCI.

Per informazioni su come registrare un'applicazione con IAM OCI, consulta la sezione relativa all'aggiunta di un'applicazione riservata nella documentazione di Oracle Cloud Infrastructure. Le informazioni sulla registrazione di un'applicazione con OAM sono disponibili in Configurazione dei servizi OAuth in Amministrazione di Oracle Access Management.

Quando registri un'applicazione (client) con IAM o OAM OCI, dovrai fornire le seguenti informazioni:

• Tipi di privilegio consentiti: l'applicazione deve utilizzare il tipo di privilegio Codice autorizzazione o il tipo di privilegio Credenziali client.

• Scope o ruoli: includere le risorse a cui devono accedere i componenti personalizzati. Se si include il tipo di privilegio del token di aggiornamento, è necessario aggiungere anche l'ambito corrispondente, ovvero offline_access per IAM OCI.

• URL di reindirizzamento o di callback: per restituire il codice di autorizzazione è necessario fornire l'URL utilizzato dall'IDP. Alcuni provider di identità fanno riferimento a questo come URL di reindirizzamento o URI di callback. Per capire cosa usare per l'URL di reindirizzamento, vai alla pagina Canali e apri qualsiasi canale Facebook o Webhook (se non ne hai, creane uno fittizio). Utilizzare il dominio e la porta dell'URL del webhook del canale (ad esempio, https://<domain>:<port>/connectors/v2/tenants/<tenantId>/listeners/facebook/channels/<channelId>) per creare l'URL di reindirizzamento, che deve essere nel formato https://<domain>:<port>/connectors/v2/callback. Ad esempio, https://example.com:443/connectors/v2/callback.

  Se il provisioning dell'istanza viene eseguito su Oracle Cloud Platform (come tutte le istanze della versione 19.4.1), utilizzare v1 anziché v2.

Se si utilizza OAuth2Client o OAuth2AccountLink per l'autenticazione con il provider di identità, dopo aver creato l'applicazione (client OAuth), annotare le credenziali client, il token IDP e l'URL di autorizzazione. Queste informazioni saranno necessarie quando si crea un servizio di autenticazione come descritto in Servizi di autenticazione.

Per registrare un'applicazione con la piattaforma Microsoft Identity, seguire le istruzioni di Microsoft all'indirizzo Quickstart: Register a application with the Microsoft Identity platform.

Impostare il tipo di applicazione su Web.

Dovrai fornire l'URL utilizzato dalla piattaforma per rispedire il codice di autorizzazione. Per capire cosa usare per l'URL, vai alla pagina Canali di Digital Assistant e apri qualsiasi canale Facebook o Webhook (se non ne hai, creane uno fittizio). Utilizzare il dominio e la porta dell'URL del webhook del canale (ad esempio, https://<domain>:<port>/connectors/v2/tenants/<tenantId>/listeners/facebook/channels/<channelId>) per creare l'URL di reindirizzamento, che deve essere nel formato https://<domain>:<port>/connectors/v2/callback. Ad esempio, https://example.com:443/connectors/v2/callback.

Dopo aver registrato l'applicazione, è necessario creare un segreto client come descritto nell'argomento Microsoft Creare un nuovo segreto applicazione. Questo segreto verrà utilizzato quando si crea un servizio di autenticazione per l'applicazione.

Per registrare un'applicazione con Google OAuth2, è necessario creare un progetto e abilitare le API necessarie, come illustrato nell'argomento di Google Abilita API per il progetto. Se si prevede di utilizzare i componenti del calendario, assicurarsi di abilitare sia l'API Google Calendar che l'API CalDAV.

Successivamente, ottenere l'ID client e il segreto dell'applicazione come descritto nell'argomento di Google Crea credenziali di autorizzazione.

Nella schermata di consenso OAuth, specificare gli ambiti ai quali l'applicazione dovrà disporre dell'autorizzazione di accesso. Per ulteriori informazioni, vedere l'argomento di Google relativo all'identificazione degli ambiti di accesso.

Di seguito viene descritto come creare un servizio di autenticazione per il codice di autorizzazione del tipo di privilegio per IAM, OAM, Microsoft Identity Platform e Google Identity Platform OCI. Questo tipo di privilegio esegue l'autenticazione in base al nome utente e alla password.

1. Aprire il menu laterale e fare clic su Impostazioni > Servizi di autenticazione.
2. Fare clic su + Servizio.
3. Selezionare il tipo di assegnazione Codice autorizzazione.
4. Immettere i seguenti valori.

   • Provider di identità: il tipo di provider di identità (IDP) utilizzato.

   • Nome: nome per identificare il servizio di autenticazione.

   • URL endpoint token: l'URL del provider di identità per richiedere i token di accesso.

     • IAM OCI: utilizzare https://<IAM-Service-Instance>.identity.oraclecloud.com/oauth2/v1/token.

     • OAM: utilizzare http://<Managed-Server-Host>:<Managed-Server-Port>/oauth2/rest/token.

     • Microsoft Identity Platform: usa https://login.microsoftonline.com/<Azure-Active-Directory-TenantID>/oauth2/v2.0/token.

     • Google Identity Platform: utilizza https://www.googleapis.com/oauth2/v4/token.

   • Endpoint autorizzazione: l'URL del provider di identità per la pagina con cui gli utenti eseguono l'autenticazione immettendo il nome utente e la password.

     • IAM OCI: utilizzare https://<IAM-Service-Instance>.identity.oraclecloud.com/oauth2/v1/authorize.

     • OAM: utilizzare http://<host>:<port>/oauth2/rest/authz.

     • Microsoft Identity Platform: usa https://login.microsoftonline.com/<Azure-Active-Directory-TenantID>/oauth2/v2.0/authorize.

     • Google Identity Platform: utilizza https://accounts.google.com/o/oauth2/v2/auth.

   • URL richiesta codice di autorizzazione breve: (facoltativo) versione abbreviata dell'URL di autorizzazione, che è possibile ottenere da un servizio di abbreviazione URL (che consente di inviare i parametri di query). Questo potrebbe essere necessario perché l'URL di autorizzazione-code-request generato potrebbe essere troppo lungo per SMS e smartphone meno recenti.

     Per impostazione predefinita, gli URL di richiesta del codice di autorizzazione per ciascuna piattaforma sono:

     • IAM e OAM OCI:

       {Authorization Endpoint URL}?client_id={clientId}&response_type=code&scope={scope}&redirect_uri={redirectUri}&state={state}

     • Piattaforma Microsoft Identity:

       {Authorization Endpoint URL}?client_id={clientId}&response_type=code&scope={scope}&redirect_uri={redirectUri}&response_mode=query&state={state}

     • Google Identity Platform:

       {Authorization Endpoint URL}?client_id={clientId}&response_type=code&scope={scope}&redirect_uri={redirectUri}&access_type=offline&prompt=consent&state={state}

     Di seguito è riportato un esempio dell'URL visualizzato in un messaggio di testo.

     
     Descrizione dell'immagine long-url.png

     Ad esempio, è possibile ottenere una versione abbreviata di questo URL:

     {Authorization Endpoint
           URL}?client_id={clientId}&response_type=code&scope={scope}&redirect_uri={redirectUri}&state={state}

     Utilizzando l'URL di richiesta del codice di autorizzazione breve, Oracle Digital Assistant crea l'URL di richiesta del codice di autorizzazione come riportato di seguito.

     {Short Authorization Code Request URL}?state={state}

   • Revoca URL endpoint token: (facoltativo) se si desidera revocare da un flusso di finestre di dialogo tutti i token di aggiornamento e di accesso dell'utente collegato, è necessario l'URL del token di revoca dell'aggiornamento dell'IDP. Se si fornisce questo URL, è possibile utilizzare il componente Reimposta token OAuth 2.0 per revocare i token dell'utente per questo servizio.

     • IAM OCI: utilizzare https://<IAM-Service-Instance>.identity.oraclecloud.com/oauth2/v1/revoke.

     • OAM: utilizzare https://<host>:<port>/ms_oauth/oauth2/endpoints/<OAuth-Service-Name>/tokens.

     • Piattaforma Microsoft Identity: non supportata.

     • Google Identity Platform: utilizza https://oauth2.googleapis.com/revoke.

   • ID client e Segreto client: l'ID e il segreto del client per l'applicazione IDP (client OAuth) registrata come descritto in Registrazione del provider di identità. Con la piattaforma di identità Microsoft, utilizzare l'ID applicazione e il segreto.

   • Scope: lista separata da spazi degli ambiti che devono essere inclusi quando Digital Assistant richiede un token di accesso dal provider. Include tutti gli ambiti necessari per accedere alle risorse. Se i token di aggiornamento sono abilitati, includere l'ambito necessario per ottenere il token di aggiornamento (in genere offline_access).

     • IAM OCI: utilizzare l'ambito urn:opc:idm:__myscopes__ quando è necessario ottenere un token di accesso contenente tutti gli ambiti consentiti. Utilizzare l'ambito urn:opc:idm:role.<roll-name>, ad esempio urn:opc:idm:role.User%20Administrator), quando è necessario ottenere un token di accesso contenente gli ambiti applicabili di un determinato ruolo.

     • Piattaforma Microsoft Identity: è necessario includere openid email profile offline_access. Se si prevede di utilizzare i componenti del calendario, è necessario includere https://graph.microsoft.com/Calendars.ReadWrite. Per altre autorizzazioni, utilizzare il formato https://graph.microsoft.com/<permission>. Sostituire <permission> con un nome di autorizzazione valido dal riferimento alle autorizzazioni di Microsoft Graph.

     • Google Identity Platform: è necessario includere https://www.googleapis.com/auth/userinfo.email, utilizzato per ottenere l'ID di login dell'utente. Se si prevede di utilizzare i componenti del calendario, è necessario includere https://www.googleapis.com/auth/calendar. Per altri ambiti, vedere OAuth 2.0 Scopes for Google APIs.

   • Richiesta di risarcimento oggetto: la richiesta di profilo con token di accesso da utilizzare per identificare l'utente.

     • OCI IAM e OAM: in genere si tratta della richiesta sub (oggetto). Tuttavia, se la richiesta sub contiene un ID utente interno, non è utile per Digital Assistant. In questi casi, specificare una richiesta di profilo che consenta a Digital Assistant di identificare l'utente, ad esempio email o name.

     • Microsoft Identity Platform: usa preferred_username.

     • Google Identity Platform: utilizza email.

   • Aggiorna periodo di conservazione token: il numero di giorni per mantenere il token di aggiornamento nella cache di Digital Assistant. Se si lascia vuoto, il valore predefinito è 7.

   
   Descrizione dell'immagine auth-service-ac.png
5. Fare clic su Crea.

Di seguito viene descritto come creare un servizio di autenticazione per le credenziali del tipo di privilegio. Questo tipo di privilegio esegue l'autenticazione in base all'ID client e al segreto client.

1. Aprire il menu laterale e fare clic su Impostazioni > Servizi di autenticazione.
2. Fare clic su + Servizio.
3. Selezionare il tipo di privilegio Credenziali client.
4. Immettere i seguenti valori.

   • Provider di identità: il tipo di provider di identità (IDP) utilizzato.

   • Nome: nome per identificare il servizio di autenticazione.

   • URL endpoint token: l'URL del provider di identità per richiedere i token di accesso.

   • ID client e Segreto client: l'ID e il segreto del client per l'applicazione IDP (client OAuth) registrata come descritto in Registrazione del provider di identità.

   • Scope: gli ambiti che devono essere inclusi quando Digital Assistant richiede un token di accesso dal provider. Include tutti gli ambiti necessari per accedere alle risorse.

   
   

   
   Descrizione dell'immagine auth-service-cc.png

   
   
5. Fare clic su Crea.

È possibile configurare le competenze per gli identificativi utente unificati con i passi generali riportati di seguito.

1. Abilita collegamento account canale nell'istanza di Digital Assistant.
2. Aggiungere un servizio di codici di autorizzazione nell'istanza di Digital Assistant.
3. Nel flusso della finestra di dialogo dello skill, aggiungere un componente OAuth 2.0 Collegamento account (per la modalità finestra di dialogo Visual) o System.OAuth2AccountLink (per la modalità YAML).
4. Nel componente configurare la gestione del consenso utente per la memorizzazione dei dati di identità utente unificata.

L'ID utente unificato per un determinato utente viene impostato la prima volta che l'utente accede all'assistente digitale e viene autenticato con un'autorizzazione utilizzando il componente OAuth 2.0. Cioè, l'identità autenticata iniziale diventa il "punto di verità". Tutti gli ID account canale per lo stesso utente autenticato OAuth 2.0 sono associati all'ID utente unificato.

È possibile abilitare il collegamento degli account canale per consentire il riconoscimento delle identità utente su più canali di uno skill. Ad esempio, se un utente avvia una conversazione in un canale ed è in attesa di una risposta, potrebbe anche ricevere una notifica di tale risposta nell'altro canale.

Per abilitare il collegamento del canale, effettuare le operazioni riportate di seguito.

1. Fare clic su per aprire il menu laterale e selezionare Impostazioni > Servizi identità unificati.
2. Impostare l'opzione Collegamento account canale su Attiva.

Dopo aver attivato il collegamento dell'account canale, è possibile configurare la modalità di gestione del consenso utente per ogni skill singolarmente, utilizzando la proprietà requiresAssociationConsent nel componente Collegamento account OAuth 2.0 della competenza. Sono disponibili le opzioni riportate di seguito.

• Yes: presenta all'utente le seguenti scelte di consenso per l'associazione dei dati dell'account canale con un ID utente unificato:
  • Conto associato. Conferma che l'utente ha approvato il collegamento dell'identità di canale corrente con l'ID utente unificato centralizzato.
  • Non collegare mai questo account. Indica che questo account canale specifico non deve essere associato all'ID utente unificato. L'utente non viene successivamente chiesto se collegare questo account in futuro. (anche se l'utente può in seguito invertire tale decisione).
  • Non al momento. Non collega gli account per la sessione corrente, ma non impedisce all'utente di ricevere la richiesta di approvazione nelle sessioni successive. La richiesta di consenso viene temporaneamente soppressa dopo che l'utente ha selezionato questa opzione, ma potrebbe riapparire quando l'utente esegue di nuovo l'autenticazione più di 24 ore dopo.
• No . L'account canale utente viene collegato automaticamente all'ID utente unificato senza che all'utente venga richiesto il consenso.
• Notify. L'account canale utente viene collegato automaticamente all'ID utente unificato e l'utente viene informato di tale fatto.

Il valore predefinito della proprietà è Yes.

Esiste un set di prompt e messaggi visualizzati nella conversazione quando a un utente viene notificato che le informazioni sull'identità dell'account canale vengono collegate a un'identità utente unificata o se vengono fornite opzioni di consenso. È possibile modificare la frase di questi prompt nei messaggi nel bundle di risorse dello skill.

Per accedere a questi prompt e messaggi specifici nel bundle di risorse:

1. Nella competenza, fare clic su per aprire il bundle delle risorse.
2. Selezionare la scheda Configurazione.
3. Nel campo Filtro immettere OAuthAccount2Link - consent per visualizzare le voci del bundle correlate al consenso.

Il periodo di tempo in cui vengono memorizzati i dati di identità utente unificata viene impostato a livello di istanza.

Per configurare il periodo di tempo durante il quale tali dati vengono memorizzati:

1. Fare clic su per aprire il menu laterale e selezionare Impostazioni > Servizi identità unificati.
2. Impostare l'opzione Elimina i dati dell'account canale dell'utente dopo il periodo di conservazione specificato su Attiva.

   Se non è attivato, i dati dell'account del canale dell'utente verranno conservati a tempo indeterminato.

3. Nel campo Periodo di conservazione per i dati utente dell'account canale (in giorni), immettere il numero di giorni in cui si desidera memorizzare i dati.

   Il minimo di 7 e il massimo è 1100.

   Nota
   
   I job per la rimozione dei dati vengono eseguiti una sola volta ogni 24-48 ore. Pertanto, a seconda dell'ora del job, i dati potrebbero essere conservati per un massimo di 48 ore in più rispetto al periodo di conservazione designato.