Identity Provider Proxy: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
fix
Mezval (discussione | contributi)
Nessun oggetto della modifica
Riga 1:
[[File:20241129 OplonSecureAccess IDPProxy WIKI ITA meta.png|thumb|351x351px|Identity Provider Proxy (IdPP) flow schema]]Un '''Identity Provider Proxy''' (abbreviato IdPP oppure IDPP) è un sistema che si frappone tra l'utente e un servizio applicativo web che necessita di avere un'autenticazione federata prima di essere erogato. L'Identity Provider Proxy verifica se l'utente che chiederichiede il servizio si è già autenticato e nel caso non si sia ancora autenticato, viene ridiretto verso il serivizioservizio dell'[[:en:Identity Provider]] (abbreviato IdP oppure IDP) per eseguire l'autenticazione. Una volta che l'[[:en:Identity Provider]] ha effettuato l'autenticazione viene ridiretto nuovamente sull'IdPP che verifica se quanto ricevuto è valido e se l'utente ha effettuato l'autenticazione con successo. Una volta verificatoverificata che l'autenticazione è avvenuta con successo, permette alla richiesta di oltrepassare l'IdPP pere proseguiredi versoraggiungere il servizio per essere erogato. l'IdPP aggiunge all'header http i dati idetinficativiidentificativi dell'utente, ricevuti dall'IdP ed eventualmente integrati con altri dati, in modo che il servizio applicativo web possa leggere il profilo dell'utente ed eseguire un login automatico (SSO) con le sue caratteristiche dell'utente. Il formato che descrive i dati di profilo dell'utente all'interno dell'header http può essere divariabile in varibase formatialle esigenze ma ormai si preferisce utilizzare il formato JWT ([[JSON Web Token]]) diventato uno standard di fatto. All'applicazione web resta solamente da interpretare i dati in formato JWT ed eventualmente chiedere conferma dell'autenticità dei dati ricevuti all'IdPP. Questa ultima operazione di verifica deldei dati JWT proveniente dall'IdPP da parte del servizio web proveniente dall'IdPP è facoltativa in dipendenza della sicurezza di comunicazione che esiste tra l'applicazione web nella intranet e l'IdPP.
 
Di seguito l'architettura e la sequenza delle operazioni che intervengono per effettuare una autenticazione federata con un IdPP.
Riga 14:
 
==Architectura==
[[File:20241129 OplonSecureAccess IDPProxy Layers WIKI ITA meta.png|thumb|351x351px|Identity Provider Proxy (IdPP) position in the architectural layers]]L'architettura dell'erogazione di servizi si arricchisce dello strato IdPP a livello infrastrutturale. Lo strato applicativo acquisisce il profilo degli utenti attraverso informazioni aggiuntive nell'Header http realizzando sistemi robusti di SSO infrastrutturali.
L'architettura dell'erogazione di servizi di un IdPP sposta l'autenticazione dal livello di servizio al livello infrastrutturale che apparirà quindi con i seguenti layer.
 
# Firewall
# WAF
# LoadBalancing
# IdPP
# LoadBalancing
# Services
 
Riga 28:
* [[OAuth]]
* [[OpenID]]
* [[Single sign-on]] - SSO
* [[:en:Shibboleth (Internet2)]] – Sistema di identità federato mirato agli ambienti educativi
* [[:en:National identity cards in the European Economic Area]]