Identity Provider Proxy: differenze tra le versioni

Versione delle 17:02, 13 gen 2025

Versione attuale delle 22:50, 22 gen 2025

(38 versioni intermedie di 10 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=|arg2=|ts=20250113160234|wikidata=}}<!-- 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 si è già autenticato e nel caso non si sia ancora autenticato, viene ridiretto verso il servizio 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 verificata che l'autenticazione è avvenuta con successo, permette alla richiesta di oltrepassare l'IdPP e di raggiungere il servizio per essere erogato. l'IdPP aggiunge all'header http i dati identificativi 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. 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 aggiormaneto 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.

* [[:en:JSON Web Token]]

== Tecnologie correlate ==

* [[:en:JSON Web Token]]

* [[:en:SAML 2.0]]

* [[OAuth]]

* [[OpenID]]

* [[Single sign-on]] - SSO

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

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

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

* [[:en: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}}

== Soluzioni commerciali ==

[[Categoria:Tecniche di difesa informatica]]

* Oplon Secure Access IdPP OpenID SAML2 Shibboleth [https://archive.oplon.net/it/docs/identity-provider-proxy/api] CIE [https://archive.oplon.net/it/docs/identity-provider-proxy/cie]

[[Categoria:Identity_management]]

* Github SPID Shibboleth Proxy [https://github.com/italia/spid-idp-proxy-shibboleth]

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

* Oracle Chapter 7 Implementing a SAMLv2 Identity Provider Proxy [https://docs.oracle.com/cd/E19316-01/820-3746/6nf8qcv96/index.html]

* Microsoft Identity Provider Proxy [https://learn.microsoft.com/en-us/azure/bot-service/bot-builder-concept-identity-providers-proxy?view=azure-bot-service-4.0]

* SAP Configuring Identity Providers as Proxies [https://help.sap.com/docs/SAP_SINGLE_SIGN-ON/27aa32ff2f5f4e7ebf59a9560205eca2/414a626ff1c04594a95706c8f6567904.html]