Identity Provider Proxy: differenze tra le versioni

Versione delle 16:52, 21 gen 2025

Versione delle 10:21, 22 gen 2025

Riga 1:

{{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|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à? {{!}} Entrust|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>

[[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 ([[Single sign-on]]) 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 [[JSON Web Token]] ed eventualmente chiedere conferma dell'autenticità dei dati ricevuti all'IdPP. Questa ultima operazione di verifica dei dati [[JSON Web Token]] 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/#:~:text=Social-based%20identity%20providers%20maintain,a%20Google%20or%20Facebook%20account).|titolo=What is an Identity Provider (IdP)? {{!}} Types & Examples {{!}} Imperva|sito=Learning Center|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>{{Cita web|lingua=en|url=https://www.pomerium.com/docs/capabilities/authentication|titolo=Authentication and Single Sign-On (SSO) {{!}} Pomerium|sito=www.pomerium.com|accesso=2025-01-21}}</ref>

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>{{Cita web|lingua=en|url=https://www.pomerium.com/docs/capabilities/authentication|titolo=Authentication and Single Sign-On (SSO) {{!}} Pomerium|sito=www.pomerium.com|accesso=2025-01-21}}</ref>

==Archittetura==

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>{{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.<ref>{{Cita web|url=https://docs.aws.amazon.com/it_it/elasticloadbalancing/latest/application/load-balancer-integrations.html|titolo=Integrazioni per il tuo Application Load Balancer - Sistema di bilanciamento del carico elastico|sito=docs.aws.amazon.com|accesso=2025-01-21}}</ref> 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.

==Vantaggi==

I vantaggi di un Identity Provider ProxyIdPP si manifestano in modo significativoapprezzano nelle infrastrutture enterprise, dove il sistema consenterisolve dii risolvereproblemi indi maniera centralizzata le problematiche legate all'[[autenticazione]] e all'autorizzazione per molteplici servizi applicativi presentidel nel [[backend]]. QuestaL'infrastruttura configurazionecosì introducerealizzata permette di avere un nuovo livello trasversalelayer di autenticazione e autorizzazione chetrasversale interessaa tutti i servizi delposti nel backend,. offrendoQuesta numerosiarchitettura beneficisi siatraduce in terminimolteplici vantaggi sia di sicurezza sia di velocità di implementazione, cone conseguentequindi riduzione dei costirisparmio.<ref>{{Cita web|lingua=en|autore=optimal|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>

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

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>

# 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

==Architectura==

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>

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

# Firewall

== Note ==

# WAF

<references/>

# IdPP

# LoadBalancing

# Services

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

== Voci 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]]

* [[SPID]]

* [[Load balancing (computing)]]

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

== Collegamenti esterniReferenze ==

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

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

* 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|Semantic Scholar: IdP Proxy per l'autenticazione combinata]

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

[[Categoria:Tecniche di difesa informatica]]

[[Categoria:Identity_management]]

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