Identity Provider Proxy: differenze tra le versioni

Versione delle 17:21, 16 gen 2025

Versione attuale delle 22:50, 22 gen 2025

(33 versioni intermedie di 9 utenti non mostrate)

Riga 1:

[[File:20241129 OplonSecureAccess IDPProxy WIKI ITA meta.png|thumb|351x351px|Schema del flusso di un Proxy dell'Identity Provider]]Un '''Identity Provider Proxy''' (abbreviato '''IdPP''' oppure '''IDPP''') è un sistema che si interpone tra l'utente e un [[Applicazione web|servizio web applicativo]] che richiede un'autenticazione federata prima di essere erogato.<ref>{{Cita web|lingua=it-IT|url=https://www.entrust.com/it/resources/learn/what-is-an-identity-provider|titolo=Che cos'è un provider di identità?|sito=www.entrust.com|accesso=2025-01-21}}</ref> L'Identity Provider Proxy verifica se l'utente che richiede il servizio si è già autenticato. In caso contrario, l'utente viene reindirizzato al servizio dell'Identity Provider per completare il processo di autenticazione.<ref>{{Cita pubblicazione|autore=James L|autore2=Fenton|autore3=Michael E|titolo=Linee guida per l'identità digitale: revisione 3|url=https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-3.pdf}}</ref>

{{Bozza|arg=informatica|arg2=|ts=20250113160234|wikidata=Q5988403}}<!-- IMPORTANTE: NON CANCELLARE QUESTA RIGA, SCRIVERE SOTTO -->

[[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 richiede il servizio (punto 1 dello schema) si è già autenticato e nel caso non si sia ancora autenticato, viene ridiretto verso il servizio dell'[[Identity Provider]] (abbreviato IdP oppure IDP) per eseguire l'autenticazione (punto 2 dello schema). Una volta che l'[[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 (punto 3 dello schema). Una volta verificato che l'autenticazione sia avvenuta con successo da parte del'[[Identity Provider]], l'IdPP permette alla richiesta di raggiungere il servizio per essere erogato (punto 4 dello schema). l'IdPP aggiunge all'header http i dati identificativi dell'utente, ricevuti dall'[[Identity Provider]] ed eventualmente li integra 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 o ambiti di gestione. Il formato che descrive i dati di profilo dell'utente all'interno dell'header http può essere variabile in base alle esigenze ma ormai si preferisce utilizzare il formato JWT ([[JSON Web Token]]). 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 dei dati JWT proveniente dall'IdPP da parte del servizio web è facoltativa in dipendenza della sicurezza di comunicazione che esiste tra l'applicazione web nella intranet e l'IdPP.

Una volta che l'Identity Provider ha eseguito l'autenticazione, l'utente viene reindirizzato nuovamente sull'IdPP, che verifica la validità dei dati ricevuti e conferma se l'autenticazione è avvenuta con successo. Dopo questa verifica, l'IdPP consente alla richiesta di raggiungere il servizio web per essere erogato.<ref>{{Cita web|lingua=en-US|url=https://www.imperva.com/learn/data-security/identity-providers-idps/|titolo=What is an Identity Provider (IdP)? {{!}} Types & Examples|accesso=2025-01-21}}</ref>

Durante questo processo, l'IdPP aggiunge all'[[Hypertext Transfer Protocol#Gli header della richiesta|header HTTP]] i dati identificativi dell'utente ricevuti dall'Identity Provider ed eventualmente li arricchisce con ulteriori informazioni. Questo consente al servizio web applicativo di leggere il [[profilo utente]] e di eseguire un [[Single Sign-On]], garantendo un accesso automatico con le caratteristiche o gli ambiti di gestione specifici dell'utente.<ref name=Facchini />

Il formato utilizzato per descrivere i dati del profilo utente all'interno dell'header HTTP può variare in base alle esigenze specifiche, ma è ormai comune adottare il formato [[JSON Web Token|JWT]].<ref>{{Cita web|lingua=en-US|url=https://frontegg.com/guides/jwt-authorization|titolo=JWT Authorization: How It Works & Implementing in Your Application|sito=Frontegg|accesso=2025-01-21}}</ref> L'applicazione web, ricevuti i dati in formato JWT, deve interpretarli ed eventualmente confermarne l'autenticità tramite l'IdPP. Tuttavia, questa operazione di verifica è facoltativa e dipende dal livello di sicurezza nella comunicazione tra l'applicazione web, situata nella [[intranet]], e l'IdPP.<ref name=Facchini />

==Archittetura==

[[File:20241129 OplonSecureAccess IDPProxy Layers WIKI ITA meta.png|miniatura|Architettura per servizi sicuri con IdPP tra cloud e intranet.]]

L'architettura per l'erogazione di servizi si arricchisce con l'integrazione di uno strato Identity Provider Proxy a livello infrastrutturale. Questo livello aggiuntivo consente allo strato applicativo di acquisire il [[profilo utente]] attraverso informazioni inserite nell'header HTTP, permettendo la realizzazione di sistemi robusti di [[Single Sign-On]] infrastrutturale.<ref name=Facchini>{{Cita web|lingua=en|autore=Corrado Facchini|url=https://medium.com/%40corrado.facchini/single-sign-on-sso-46ea458aec30|titolo=Architecture for Single Sign-On (SSO) and Identity Provider}}</ref>

Nei [[Centro elaborazione dati|datacenter]], l'architettura tipica include componenti come [[firewall]], [[Firewall#WAF|Web Application Firewall]]<ref>{{Cita web|url=https://docs.mirantis.com/mcp/q4-18/mcp-security-best-practices/solutions/waf-and-load-balancers.html|titolo=Mirantis Documentation: WAF and load balancer|sito=docs.mirantis.com|accesso=2025-01-21}}</ref>, IdPP, sistemi di [[load balancing]] e i servizi applicativi. I sistemi più avanzati combinano le funzionalità di WAF, load balancing e IdPP in un unico prodotto, semplificando le operazioni e migliorando l'efficienza complessiva della gestione infrastrutturale.

Di seguito l'architettura e la sequenza delle operazioni che intervengono per effettuare una autenticazione federata con un IdPP.

==Vantaggi==

I vantaggi di un IdPPIdentity Provider Proxy si apprezzanomanifestano in modo significativo nelle infrastrutture enterprise, dove il sistema risolveconsente idi problemirisolvere diin maniera centralizzata le problematiche legate all'[[autenticazione]] e all'autorizzazione per molteplici servizi applicativi delpresenti nel [[backend]]. L'infrastrutturaQuesta cosìconfigurazione realizzata permette di avereintroduce un nuovo layerlivello trasversale di autenticazione e autorizzazione trasversaleche ainteressa tutti i servizi posti neldel backend., Questaoffrendo architetturanumerosi sibenefici traducesia in molteplici vantaggi siatermini di sicurezza sia di velocità di implementazione, econ quindiconseguente risparmioriduzione dei costi.<ref>{{Cita web|lingua=en|url=https://optimalidm.com/resources/blog/5-reasons-why-you-need-an-identity-provider/|titolo=5 Reasons Why You Need an Identity Provider|sito=Optimal IdM|data=2023-04-11|accesso=2025-01-21}}</ref>

Un'infrastruttura basata su un IdPP garantisce una maggiore flessibilità nell'imporre un'autenticazione forte per qualsiasi servizio, assicurando al contempo un'uniformità nella gestione delle autenticazioni all'interno del [[datacenter]]. Inoltre, l'evoluzione e l'aggiornamento dei sistemi di autenticazione risultano semplificati, in quanto tali modifiche strutturali non richiedono interventi sui singoli applicativi.<ref>{{Cita web|url=https://help.sap.com/docs/SAP_IDENTITY_MANAGEMENT/7c61245338d0434c91cb587217404b71/d7b115cab48541908eec1ac1b78a5601.html|titolo=Identity Provider Proxy|sito=help.sap.com|accesso=2025-01-21}}</ref>

# Flessibilità nell'imporre una autenticazione forte per qualsiasi servizio

# Uniformità all'interno del datacenter di gestione delle autenticazioni

# Semplicità dell'evoluzione e aggiornamento dei sistemi di autenticazione che essendo strutturali non necessitano di essere aggiornati sui singoli applicativi

# Rispondenza alle norme di legge nel trattamento dei dati personali

# Rispondenza alle norme di legge per le piattaforme governative (CIE - SPID)

# Unificazione del sistema di logging dei servizi che necessitano di autenticazione

# Semplificazione dell'infrastruttura

Questo approccio consente di rispettare le normative in materia di trattamento dei [[dati personali]] e di garantire la conformità alle leggi specifiche per le piattaforme governative, come la [[Carta d'identità elettronica italiana|Carta d'Identità Elettronica]] (CIE) e il sistema [[SPID]]. L'adozione di un IdPP permette, inoltre, di unificare il sistema di [[logging]] per tutti i servizi che richiedono autenticazione, semplificando così l'intera infrastruttura e migliorandone l'efficienza.<ref>{{Cita web|url=https://www.agid.gov.it/sites/default/files/repository_files/mo-spid_v03.pdf|titolo=IdP - Gestore di Identità Digitale|sito=www.agid.gov.it|accesso=2025-01-21|urlarchivio=http://web.archive.org/web/20220122200129/https://www.agid.gov.it/sites/default/files/repository_files/mo-spid_v03.pdf|dataarchivio=2022-01-22}}</ref>

==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.

== Note ==

# Firewall

<references/>

# WAF

# IdPP

# LoadBalancing

# Services

== TecnologieVoci correlate ==

I sistemi più evoluti riuniscono in un unico prodotto le funzionalità WAF, LoadBalancing e IdPP semplificando le operazioni nei datacenter.

== Tecnologie correlate ==

* [[JSON Web Token]]

* [[SAML 2.0]]

* [[OAuth]]

* [[OpenID]]

* [[Single sign-on]] - SSO

* [[Carta d'identità elettronica italiana]]

* [[Shibboleth (Internet2)]] – Sistema di identità federato mirato agli ambienti educativi

* [[National identity cards in the European Economic Area]]

* [[Italian electronic identity card]]

* [[SPID]]

{{Portale|informatica}}

== ReferenzeCollegamenti esterni ==

* [https://ieeexplore.ieee.org/document/5983520 IEEE sul Proxy dell'Identity Provider]

* Pubblicazione IEEE (Institute of Electrical and Electronic Engineers) DOI: 10.1109/ANTS.2010.5983520

* Semantic Scholar DOI:10.1109/ANTS.2010.5983520Corpus ID: 42910497 [https://www.semanticscholar.org/paper/IdP-proxy-for-combined-authentication-based-on-IdPs-Kaji-Fujishiro/3e55e1a34d2cf7fd8db67da61cbaffcf6fb133dd Scholar: IdP Proxy per l'autenticazione combinata]

[https://ieeexplore.ieee.org/document/5983520]

* Semantic Scholar DOI:10.1109/ANTS.2010.5983520Corpus ID: 42910497 [https://www.semanticscholar.org/paper/IdP-proxy-for-combined-authentication-based-on-IdPs-Kaji-Fujishiro/3e55e1a34d2cf7fd8db67da61cbaffcf6fb133dd]

{{Portale|informatica|Sicurezza informatica|Telematica}}

[[Categoria:Tecniche di difesa informatica]]

[[Categoria:Identity_management]]

[[Categoria:Controllo degli accessi (informatica)]]