Identity Provider Proxy: differenze tra le versioni

Versione delle 10:47, 11 gen 2025

Versione attuale delle 22:50, 22 gen 2025

(44 versioni intermedie di 10 utenti non mostrate)

Riga 1:

[[File:20241129 OplonSecureAccess IDPProxy WIKI ITA meta.png|thumb|351x351px|IdentitySchema Providerdel Proxyflusso (IdPP)di flowun schemaProxy dell'Identity Provider]]Un '''Identity Provider Proxy''' (abbreviato '''IdPP''' oppure '''IDPP''') è un sistema che si frapponeinterpone tra l'utente e un [[Applicazione web|servizio applicativo web cheapplicativo]] necessita diche avererichiede 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 chiederichiede il servizio si è già autenticato. e nelIn caso noncontrario, si sia ancora autenticato,l'utente viene ridirettoreindirizzato versoal il serivizioservizio dell'[[:en:Identity Provider]] (abbreviato IdP oppure IDP) per eseguirecompletare l'autenticazione.il Unaprocesso voltadi 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.<ref>{{Cita Unapubblicazione|autore=James voltaL|autore2=Fenton|autore3=Michael verificatoE|titolo=Linee permette alla richiesta di oltrepassare l'IdPPguida per proseguire verso il servizio. l'IdPPidentità aggiungedigitale: all'headerrevisione http i dati idetinficativi dell'utente, ricevuti dall'IdP, in modo che il servizio applicativo web possa leggere il profilo dell'utente ed eseguire un login automatico (SSO) con le caratteristiche dell'utente3|url=https://nvlpubs. Il formato che descrive i dati di profilo dell'utente all'interno dell'header http può essere di vari formati ma ormai si preferisce utilizzare il formato JWT ([[JSON Web Token]]) diventato uno standard di fattonist. All'applicazione web resta solamente da interpretare i dati in formato JWT ed eventualmente chiedere conferma dell'autenticità dei dati all'IdPPgov/nistpubs/SpecialPublications/NIST. Questa ultima operazione di verifica del JWT da parte del servizio web proveniente dall'IdPP è facoltativa in dipendenza della sicurezza di comunicazione che esiste tra l'applicazione web e l'IdPPSP.800-63-3.pdf}}</ref>

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

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.

== Note ==

# Firewall

<references/>

# WAF

# LoadBalancing

# IdPP

# Services

== Voci correlate ==

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

* [[:en:JSON Web Token]]

== Standards ==

* [[:en:JSON Web Token]]

* [[:en:SAML 2.0]]

* [[OAuth]]

* [[OpenID]]

* [[Single sign-on]]

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

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

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

* [[:en:Italian electronic identity card]]

* [[SPID]]

{{Portale|informatica}}

== Collegamenti esterni ==

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

* [https://www.semanticscholar.org/paper/IdP-proxy-for-combined-authentication-based-on-IdPs-Kaji-Fujishiro/3e55e1a34d2cf7fd8db67da61cbaffcf6fb133dd 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)]]