Configurazione del server di autenticazione centralizzata
Il server di autenticazione centralizzata (CAS) gestisce la relazione di trust tra i prodotti PTC che fanno parte della struttura SSO. Funge da broker tra le applicazioni autorizzando gli accessi utente, dopo che l'utente è stato autenticato, ed emettendo e verificando i token di accesso scambiati tra i provider di servizi e i server delle risorse.
Di seguito sono riportati alcuni suggerimenti generali da tenere in considerazione quando si distribuisce un CAS.
• Esaminare il tempo massimo di validità di una sessione di accesso utente e considerare se gli stessi valori devono essere utilizzati in ciascuna delle applicazioni che fanno parte della soluzione SSO.
• Verificare che i sistemi funzionino entro una tolleranza di deviazione temporale accettabile. Se uno o più orologi di sistema non sono sincronizzati con il CAS e quest'ultimo supera il tempo di tolleranza di deviazione impostato nei sistemi, la configurazione genera errori e impedisce l'autenticazione degli utenti.
I prodotti PTC abilitati per SSO implementano i due seguenti flussi di autenticazione utilizzando la struttura SSO e i protocolli standard:
• Autenticazione federata
• Autorizzazione - Autorizzazione delegata tramite i tipi di concessione OAuth
Autenticazione federata
L'autenticazione federata è il processo di convalida della richiesta di accesso di un utente mediante il confronto con le credenziali memorizzate nel provider di identificativi.
Nell'architettura SSO dei prodotti PTC, il server di autenticazione centralizzata (CAS) deve essere configurato in modo da reindirizzare le richieste di accesso utente all'IdP aziendale. L'IdP verifica l'autenticità delle credenziali di accesso utente e crea un'asserzione per indicare che l'utente è stato autenticato. L'autenticazione viene implementata utilizzando SAML oppure OIDC, a seconda del protocollo supportato per il prodotto PTC (vedere Protocolli SSO supportati per i prodotti PTC) e della configurazione del cliente.
Una volta confermata l'autenticazione, l'asserzione viene inviata all'applicazione richiedente, indicando che l'utente è stato autenticato e autorizza l'accesso utente. Nel corso di questa transazione, il CAS e l'applicazione PTC non dispongono di visibilità sulle credenziali utente, né possono gestirle. Quando il browser viene reindirizzato all'IdP, lo scambio di informazioni sul nome utente e sulla password viene eseguito direttamente tra l'agente client dell'utente (browser) e l'IdP. È necessario creare una connessione del provider di servizi (SP) separata per ogni prodotto PTC all'interno dello stesso ambiente federato che si basa sull'autenticazione dell'utente tramite lo stesso CAS.
Vengono seguiti i flussi di autenticazione SAML e OIDC standard, in base alla configurazione SSO. È necessario esaminare le opzioni supportate per una particolare tecnologia CAS prima di selezionarla per l'utilizzo in una configurazione SSO PTC.
Nel diagramma di sequenza riportato di seguito viene illustrato il flusso di autenticazione. In questo esempio, ThingWorx funge da SP e PingFederate è il CAS. ThingWorx utilizza il protocollo standard SAML 2.0 aperto per lo scambio di autenticazione tra l'SP e l'IdP.
Di seguito viene descritto il processo di autenticazione.
1. L'utente tenta di accedere al provider di servizi.
2. Il provider di servizi genera una richiesta SAML per l'utente e la invia al CAS.
3. Il CAS reindirizza la richiesta SAML all'IdP.
4. L'IdP reindirizza l'utente a una pagina di autenticazione in cui fornire le credenziali, ad esempio il nome utente e la password. Dopo che l'utente ha immesso le proprie credenziali, l'IdP genera una risposta SAML. Se l'utente è stato autenticato con successo, la risposta SAML include un'asserzione SAML che contiene l'autorizzazione dell'utente.
5. L'IdP reindirizza quindi la risposta al CAS.
Per PingFederate, PTC fornisce script di automazione per la configurazione con PingFederate come IdP. Per ulteriori informazioni, vedere Configurazione automatica di PingFederate come server di autenticazione centralizzata.
Per gli IdP di terze parti è necessario configurare il CAS nell'impostazione SSO.
Autorizzazione delegata (OAuth)
L'autorizzazione delegata è un concetto che consente a un provider di servizi (SP) di eseguire azioni o di accedere a risorse da un server delle risorse (RS) per conto di un utente, senza che l'utente condivida le proprie credenziali con il server delle risorse.
Sono richiesti token di accesso OAuth 2 dal CAS che vengono quindi utilizzati nelle richieste di dati dai server delle risorse. I server delle risorse si basano sul CAS per verificare il richiedente come utente autenticato prima di allocare i token di accesso. È necessario creare client OAuth distinti per ognuna delle applicazioni PTC che fanno parte di scenari di autorizzazione delegata.
I prodotti PTC proteggono ulteriormente le risorse che sono protette da OAuth configurando gli ambiti come misura di protezione aggiuntiva. Quando un provider di servizi invia un token di accesso insieme alla richiesta di dati dal server delle risorse, il token di accesso deve avere anche un ambito associato che viene registrato rispetto ai dati nel server delle risorse. Per ulteriori informazioni, vedere Gestione degli ambiti nell'autorizzazione delegata.
I prodotti PTC supportano tipi di concessione OAuth sia per i client interattivi che per quelli non interattivi. È importante comprendere la funzionalità client per determinare il tipo di concessione appropriato da utilizzare.
 |
Accertarsi di consultare la documentazione specifica del prodotto PTC per verificare i tipi di concessione OAuth supportati per il prodotto in uso.
|
◦ Interattivo: l'utente esegue l'autenticazione nel client, il client richiede risorse per conto dello stesso utente. L'autorizzazione per consentire l'accesso alla risorsa si basa sull'autorizzazione dell'utente finale.
◦ Non interattivo: noto anche come interazione machine-to-machine (M2M). Il client è un'applicazione e deve identificarsi nel CAS quando richiede un token OAuth. L'identificativo nel token OAuth è l'identificativo del computer (client o entità servizio) e non può essere un utente umano.
Nel diagramma di sequenza riportato di seguito è illustrato il flusso del codice di autorizzazione OAuth. ThingWorx è l'SP, PingFederate è il CAS e Windchill è l'RS. ThingWorx è un client interattivo configurato per l'utilizzo del flusso del codice di autorizzazione del protocollo OAuth2 standard aperto per autorizzare un SP ad accedere alle risorse in modo sicuro, affidabile ed efficiente, utilizzando l'ID utente dell'utente finale per l'autorizzazione a recuperare la risorsa.
Di seguito viene descritto il processo di autorizzazione.
1. Dopo aver ricevuto la risposta SAML dall'IdP, il CAS invia una pagina di richiesta di autorizzazione di concessione che l'utente deve approvare. Il CAS utilizza questa pagina per ottenere l'autorizzazione per la generazione di un codice OAuth.
2. Dopo aver concesso l'accesso all'utente, il CAS genera un codice di autorizzazione OAuth. Il CAS reindirizza quindi la risposta SAML e il codice di autorizzazione al provider di servizi.
3. Dopo aver ricevuto il codice di autorizzazione OAuth, il provider di servizi richiede un token di accesso e aggiorna il token dal CAS, utilizzando il codice di autorizzazione.
4. Il CAS convalida il codice di autorizzazione e genera un token di accesso OAuth e un token di aggiornamento. Il CAS invia quindi entrambi i token al provider di servizi.
5. Il proprietario della risorsa (in genere l'utente) richiede il contenuto dal provider di servizi che deve ottenere i dati del server delle risorse.
6. Il provider di servizi richiede il contenuto dal server delle risorse per conto del proprietario della risorsa utilizzando il token di accesso.
7. Il server delle risorse verifica il token di accesso con il CAS.
8. Il server delle risorse ottiene quindi il contenuto richiesto e lo invia al provider di servizi.
9. Dopo aver ricevuto il contenuto, il provider di servizi lo invia al proprietario della risorsa.
È possibile configurare tecnologie CAS alternative utilizzando lo stesso flusso. Potrebbe essere necessario considerare impostazioni e passi di configurazione specifici.
Nel caso non interattivo, il flusso di credenziali del client viene utilizzato per passare un ID client e un segreto al CAS per recuperare un token OAuth. Il token OAuth viene quindi passato all'RS per recuperare la risorsa richiesta. L'RS deve essere configurato per supportare il tipo di concessione delle credenziali del client per poter gestire il token OAuth e convalidare la richiesta. Nel diagramma di sequenza riportato di seguito, il flusso delle credenziali del client viene raffigurato con un client non interattivo che richiede una risorsa da Windchill come RS.
È inoltre possibile configurare l'architettura SSO come ambiente federato con più provider di servizi e più server delle risorse. Le configurazioni di SP e RS sono gestite da un singolo CAS. In questo modo, tutti gli identificativi utente vengono condivisi nell'ambiente federato. Nell'esempio riportato di seguito, Windchill Navigate è il provider di servizi e Windchill e SAP sono i server delle risorse.
