Configurazione del server di autenticazione centralizzata - PingFederate
PTC supporta PingFederate come server di autenticazione centralizzata (CAS). Il 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.
I prodotti PTC implementano gli elementi riportati di seguito nella struttura SSO.
1. Utilizzare le asserzioni SAML per autenticare gli utenti con l'IdP.
2. Dopo l'autenticazione, PingFederate visualizza all'utente una pagina di approvazione delle concessioni in cui gli chiede se desidera che i dati del server delle risorse siano condivisi con l'applicazione in uso.
Quando si utilizza PingFederate, è consigliabile esaminare la documentazione di PingFederate. Di seguito sono riportati alcuni suggerimenti generali da tenere in considerazione quando si distribuisce PingFederate.
• 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.
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, PingFederate non esegue direttamente l'autenticazione degli accessi utente. Al contrario PingFederate deve essere configurato in modo che le richieste di accesso utente siano reindirizzate all'IdP aziendale. L'IdP verifica l'autenticità delle credenziali di accesso utente e invia un'asserzione a PingFederate per indicare che l'utente è stato autenticato. Successivamente PingFederate invia un'asserzione di avvenuta autenticazione dell'utente all'applicazione richiedente e autorizza l'accesso utente. In tutta questa transazione, PingFederate non gestisce le credenziali dell'utente. 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 separata per ogni prodotto PTC che instrada l'autenticazione dell'utente attraverso PingFederate.
Nell'esempio riportato di seguito, ThingWorx è il provider di servizi e PingFederate è il CAS. ThingWorx utilizza il protocollo standard SAML 2.0 aperto per lo scambio di autenticazione tra il provider di servizi e il provider di identificativi.
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.
PTC fornisce script di automazione per la configurazione di PingFederate 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 PingFederate nell'impostazione SSO. Per ulteriori informazioni, vedere Configurazione manuale dell'autenticazione per gli IdP di terze parti.
Autorizzazione delegata
L'autorizzazione delegata è un concetto che consente a un provider di servizi 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.
PingFederate genera token di accesso OAuth 2 che i prodotti PTC includono nelle richieste di dati provenienti dai server delle risorse. I server delle risorse si basano sul CAS per verificare l'autenticità dei 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.
Nell'esempio riportato di seguito, ThingWorx è il provider di servizi, PingFederate è il CAS e Windchill è il server delle risorse. ThingWorx utilizza il protocollo OAuth2 standard aperto per autorizzare un provider di servizi ad accedere alle risorse in modo sicuro, affidabile ed efficiente.
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.
L'architettura SSO può essere implementata anche con più server delle risorse. Nell'esempio, ThingWorx Navigate è il provider di servizi e Windchill e SAP sono i server delle risorse.
