Pubblicato il 6 agosto 2026

AGOV nelle architetture cloud, SaaS e Hyperscaler

Interazione con Microsoft Entra ID, Microsoft 365, AWS, Google Cloud e altre piattaforme

1. Contesto

AGOV è il servizio di autenticazione delle autorità svizzere. Le applicazioni target possono essere collegate ad AGOV mediante OpenID Connect, in breve OIDC, oppure SAML 2.0, direttamente o tramite un sistema esistente di gestione delle identità e degli accessi.

AGOV non è vincolato a uno specifico modello operativo. Un’applicazione target può essere gestita in particolare:

in un centro di calcolo dell’autorità competente
presso un fornitore di servizi pubblico o privato
in un cloud privato
come software as a service
su una piattaforma hyperscaler
oppure in un’architettura ibrida o interorganizzativa

È necessario che l’applicazione target stessa o un componente IAM a monte supporti un profilo OIDC o SAML compatibile con AGOV.

AGOV non esclude il collegamento di soluzioni SaaS, cloud o hyperscaler. La possibilità tecnica di collegamento deve tuttavia essere distinta dall’ammissibilità giuridica, di sicurezza e organizzativa del rispettivo modello operativo.

2. Identità, contesto organizzativo e autorizzazione

AGOV autentica persone fisiche. Conferma all’applicazione target collegata quale persona ha effettuato l’accesso e con quale qualità di autenticazione o di verifica dell’identità.

Un conto AGOV rappresenta sempre esattamente una persona fisica. Non rappresenta in particolare:

l’appartenenza a un’autorità o a un’organizzazione
una funzione professionale
un potere di rappresentanza
un ruolo specialistico
una licenza cloud
un’autorizzazione applicativa
oppure un’assegnazione di risorse

Queste informazioni e decisioni rimangono di competenza dell’autorità responsabile, del relativo IAM organizzativo, della piattaforma cloud o dell’applicazione specialistica interessata.

Il modello fondamentale delle responsabilità è il seguente:

AGOV autentica la persona fisica.

L’IAM organizzativo associa la persona a un’organizzazione, a una funzione o a un ruolo.

La piattaforma cloud gestisce i propri conti, licenze, gruppi, ruoli e token specifici.

L’applicazione specialistica decide in merito alla concreta autorizzazione specialistica.

3. Modelli di integrazione

3.1 Collegamento diretto

Un’applicazione target può essere collegata direttamente ad AGOV come OIDC relying party o SAML service provider.

Applicazione ↔ AGOV

Questo modello è indicato in particolare per applicazioni sviluppate dalle autorità, portali di Governo elettronico e soluzioni standard con un collegamento OIDC o SAML liberamente configurabile.

3.2 Collegamento tramite un IAM esistente o un identity broker

Più applicazioni target possono essere collegate ad AGOV mediante un componente IAM comune.

Applicazioni ↔ IAM o identity broker ↔ AGOV

Il livello di intermediazione può in particolare:

armonizzare diversi profili di protocollo
trasformare claim e attributi
integrare identificatori interni delle persone
acquisire le appartenenze organizzative da registri separati
assegnare gruppi e ruoli
riunire più applicazioni in un dominio SSO
isolare da AGOV le particolarità specifiche di un prodotto

Il collegamento tramite un sistema IAM esistente fa parte del modello di integrazione previsto per AGOV.

3.3 Collegamento tramite l’IAM di una piattaforma cloud

L’IAM di una piattaforma cloud può operare nei confronti di AGOV come relying party o come livello di intermediazione delle identità.

Applicazione cloud ↔ IAM cloud ↔ AGOV

In questo modello AGOV autentica la persona fisica. La piattaforma cloud emette successivamente i propri token e gestisce i conti, i ruoli e le decisioni di accesso specifici della piattaforma.

4. Supporto dei protocolli e interoperabilità concreta

Il supporto di OIDC o SAML costituisce la base tecnica per un collegamento. Per la concreta integrazione occorre inoltre verificare che i profili e le procedure utilizzati da AGOV e dalla rispettiva piattaforma target siano compatibili.

Occorre considerare in particolare:

profili OIDC o SAML
issuer, audience ed entity ID
procedure di redirect e callback
identificatori stabili delle persone
claim e attributi
procedure di firma e cifratura
sostituzione di chiavi e certificati
durata delle sessioni e nuova autenticazione
qualità di autenticazione e step-up
single logout
requisiti di browser, applicazioni mobili, client desktop o strumenti a riga di comando

Differenze in singoli punti non escludono in linea di principio un’integrazione. A seconda della situazione possono essere risolte mediante configurazione, un’integrazione del profilo, un ulteriore sviluppo di AGOV oppure l’impiego di un identity broker controllato.

5. Microsoft Entra ID e Microsoft 365

Microsoft 365 utilizza Microsoft Entra ID come piattaforma di directory, token, licenze e accessi.

Un dominio Microsoft 365 può in linea di principio essere federato con un identity provider SAML esterno. Microsoft utilizza a tal fine uno specifico profilo di integrazione con requisiti definiti per endpoint, identificatori, claim, firme e procedure dei client.

Un possibile modello di integrazione è il seguente:

Microsoft 365 ↔ Microsoft Entra ID ↔ AGOV o identity broker

AGOV autentica la persona fisica. Microsoft Entra ID rimane responsabile in particolare di:

conti utente Microsoft 365
User Principal Name
licenze
gruppi
ruoli
assegnazioni di applicazioni
token Microsoft
Microsoft Graph
regole di accesso specifiche di Microsoft.

Una federazione diretta tra AGOV e Microsoft Entra ID presuppone la compatibilità dei profili e delle procedure utilizzati. Se un requisito specifico del prodotto non è soddisfatto direttamente, può essere utilizzato un adeguato livello di intermediazione oppure può essere presentata ad AGOV una corrispondente richiesta di ulteriore sviluppo.

La federazione di un dominio Microsoft 365 deve essere distinta dagli scenari Microsoft Entra External ID. Questi riguardano in particolare l’accesso di persone esterne a determinate risorse protette da Entra e devono essere valutati separatamente dal punto di vista tecnico e organizzativo.

6. Amazon Web Services

Nel caso di AWS occorre distinguere diversi scenari di utilizzo.

6.1 Accesso al livello di gestione AWS

Per l’accesso personale ai conti AWS e alla AWS Management Console può essere utilizzato AWS IAM Identity Center. IAM Identity Center può delegare l’autenticazione a un identity provider SAML esterno.

AWS Management Console ↔ AWS IAM Identity Center ↔ AGOV o identity broker

AGOV autentica la persona fisica. AWS gestisce in particolare:

conti AWS
permission set
ruoli IAM
gruppi
policy delle risorse
sessioni e token AWS.

La federazione SAML non sostituisce la predisposizione degli utenti, dei gruppi e delle assegnazioni di ruolo necessari in AWS. Questi elementi vengono gestiti separatamente, ad esempio mediante SCIM, amministrazione manuale o un IAM organizzativo a monte.

6.2 Applicazioni specialistiche gestite su AWS

Un’applicazione gestita su AWS può essere collegata direttamente ad AGOV mediante OIDC o SAML.

Applicazione su AWS ↔ AGOV

In alternativa può essere utilizzato Amazon Cognito come livello di intermediazione.

Applicazione su AWS ↔ Amazon Cognito ↔ AGOV

In questo modello Cognito emette i token specifici del prodotto e attribuisce gli attributi all’applicazione.

6.3 Workload tecnici

Processi tecnici, server, container, funzioni e conti di servizio non sono autenticati tramite AGOV. Per tali workload occorre utilizzare le procedure previste per le identità tecniche, le credenziali di breve durata e la workload federation.

7. Google cloud

Google Cloud consente, mediante Workforce Identity Federation, di integrare identity provider OIDC o SAML esterni per le persone fisiche.

Google Cloud ↔ Workforce Identity Federation ↔ AGOV

AGOV autentica la persona fisica. Google Cloud associa l’identità trasmessa e gli attributi ammessi ai propri ruoli IAM e alle proprie autorizzazioni sulle risorse.

Google Cloud rimane responsabile in particolare di:

workforce pool
mappatura degli attributi
principal set
ruoli Google Cloud IAM
policy delle risorse
token Google di breve durata.

Workforce Identity Federation per persone fisiche deve essere distinta da Workload Identity Federation per processi tecnici.

Google Cloud Workforce Identity Federation non deve inoltre essere equiparata a Google Workspace. Il collegamento di Google Workspace costituisce uno scenario di prodotto distinto.

8. Altre piattaforme cloud e SaaS

8.1 Oracle Cloud Infrastructure

OCI IAM Identity Domains può delegare l’autenticazione a un identity provider SAML esterno.

Oracle Cloud ↔ OCI IAM Identity Domain ↔ AGOV o identity broker

Gruppi, ruoli, policy e autorizzazioni cloud rimangono in OCI oppure nell’IAM organizzativo competente.

8.2 SAP Business Technology Platform

A seconda del servizio e dell’architettura, SAP BTP può essere collegata direttamente ad AGOV mediante SAML oppure indirettamente tramite SAP Cloud Identity Services.

Modello diretto:

Applicazione SAP BTP ↔ AGOV

Modello intermediato:

Applicazione SAP BTP ↔ SAP Cloud Identity Services ↔ AGOV

Le role collection, i ruoli aziendali e le autorizzazioni specifiche di SAP rimangono al di fuori di AGOV.

8.3 Salesforce

Salesforce può operare come SAML service provider nei confronti di AGOV o di un identity broker.

Salesforce ↔ AGOV o identity broker

Oggetti utente, profili, permission set, licenze e autorizzazioni specialistiche rimangono in Salesforce oppure nell’IAM organizzativo competente.

8.4 ServiceNow e altre soluzioni SaaS

ServiceNow e numerosi altri prodotti SaaS supportano il collegamento di identity provider esterni mediante OIDC o SAML.

Se una soluzione SaaS consente di definire un identity provider OIDC o SAML del cliente, è in linea di principio possibile esaminare e realizzare un collegamento diretto o intermediato ad AGOV.

9. Panoramica

Piattaforma o scenario
Possibile collegamento ad AGOV
Responsabilità rimanente

Applicazione specialistica sviluppata internamente
Direttamente mediante OIDC o SAML
Ruoli specialistici, autorizzazioni, sessioni e dati aziendali

Microsoft 365
Tramite Microsoft Entra ID, direttamente in caso di compatibilità dei profili o tramite broker
Conti, UPN, licenze, gruppi, ruoli e token Microsoft

AWS Management Console
SAML tramite AWS IAM Identity Center
Conti AWS, permission set, ruoli IAM e provisioning

Applicazione specialistica su AWS
Direttamente mediante OIDC o SAML oppure tramite Amazon Cognito
Profili applicativi, risorse AWS e diritti specialistici

Google Cloud
OIDC o SAML tramite Workforce Identity Federation
Mappatura degli attributi, ruoli IAM e policy delle risorse

Oracle Cloud
SAML tramite OCI IAM Identity Domains
Gruppi, ruoli e policy OCI

SAP BTP
Direttamente mediante SAML oppure tramite SAP Cloud Identity Services
Role collection e ruoli aziendali SAP

Salesforce
SAML direttamente o tramite broker
Profili, permission set, licenze e autorizzazioni specialistiche

Altre soluzioni SaaS
OIDC o SAML previa verifica del concreto profilo di integrazione
Conti, ruoli, dati e processi specifici del prodotto

10. Requisiti per AGOV

AGOV è orientato alle esigenze delle autorità svizzere e viene sviluppato di conseguenza.

Se una relying party necessita, per il collegamento di una piattaforma cloud o SaaS, ad esempio di:

un claim aggiuntivo
un determinato attributo
una variante di firma supplementare
un comportamento specifico del protocollo
un’estensione di un profilo di integrazione esistente
oppure un’ulteriore funzione basata su standard

può presentare tale requisito alla Cancelleria federale tramite i canali previsti per il collegamento, lo scambio e la governance.

I requisiti di interoperabilità specifici di determinati prodotti fanno parte del regolare sviluppo di AGOV. Non costituiscono di per sé un motivo di esclusione della piattaforma interessata.

La Cancelleria federale valuta tali requisiti considerando in particolare:

sicurezza
protezione dei dati
conformità agli standard
utilità per più autorità e relying party
effetti sulle integrazioni esistenti
operabilità
costi
prevenzione di dipendenze non necessarie da singoli fornitori.

Un ulteriore sviluppo di AGOV è particolarmente opportuno se un requisito si basa su standard aperti, migliora l’interoperabilità e non comporta il trasferimento in AGOV di ruoli specialistici, appartenenze organizzative o autorizzazioni specifiche di un prodotto.

Se un requisito è rilevante esclusivamente per un singolo prodotto o è fortemente proprietario, può risultare più adeguato l’impiego di un identity broker controllato.

11. Hyperscaler, sovranità digitale e governo elettronico

11.1 Ambito di competenza di AGOV

AGOV disciplina l’autenticazione e le condizioni quadro IAM necessarie a tale scopo.

L’impiego di AGOV non decide se un’applicazione specialistica possa essere gestita localmente, in un cloud privato, come soluzione SaaS oppure su una piattaforma hyperscaler.

Per tale valutazione AGOV non stabilisce ulteriori prescrizioni materiali in materia di cloud o sovranità che vadano oltre il quadro IAM applicabile ad AGOV, in particolare l’ordinanza sui sistemi di gestione delle identità e sui servizi di elenchi della Confederazione, OGIAM.

Un collegamento ad AGOV non equivale pertanto né a un’autorizzazione né all’esclusione di una determinata piattaforma cloud.

11.2 Responsabilità della relying party

L’autorità responsabile del processo specialistico, rispettivamente la relying party, valuta l’ammissibilità del modello operativo scelto.

Essa rimane responsabile in particolare di:

base legale del processo specialistico
finalità e proporzionalità del trattamento dei dati
scelta della soluzione cloud, SaaS o di piattaforma
classificazione e necessità di protezione dei dati
assegnazione di ruoli e diritti di accesso
sicurezza delle informazioni
protezione dei dati
trattamento dei dati su mandato
eventuali subresponsabili
comunicazioni di dati all’estero
conservazione e cancellazione
registrazione e tracciabilità
business continuity
capacità di uscita e migrazione
informazione delle persone interessate

L’impiego di AGOV non trasferisce tale responsabilità alla Cancelleria federale o al servizio di autenticazione.

11.3 Dati dei cittadini

Le applicazioni di Governo elettronico trattano spesso dati personali di cittadine e cittadini. A seconda del processo specialistico possono comprendere dati degni di particolare protezione, dati fiscali, sanitari, sociali, procedurali o altre informazioni con un elevato bisogno di protezione.

Prima di un trattamento su una piattaforma SaaS o hyperscaler, l’autorità competente deve esaminare in particolare:

l’esistenza di una base legale sufficiente
i dati necessari per il relativo scopo
le conseguenze di una violazione della riservatezza, integrità, disponibilità o tracciabilità
i luoghi di trattamento di dati, backup, log e dati di telemetria
le possibilità di accesso amministrativo e tecnico del fornitore
i subresponsabili coinvolti
i possibili accessi dall’estero
il controllo delle chiavi crittografiche
la possibilità di esportare e cancellare completamente i dati
la possibilità di migrare verso un’altra piattaforma
la continuità operativa in caso di guasto, cessazione del contratto o cambiamenti geopolitici

11.4 Sovranità digitale

La sovranità digitale non è uno stato binario. Designa la capacità di controllo e di azione necessaria a un’autorità nello spazio digitale.

Nell’impiego di un hyperscaler occorre considerare in particolare:

controllo giuridico e tecnico
dipendenza da un singolo fornitore
capacità di cambiamento e rientro
controllo dei dati e delle chiavi crittografiche
disponibilità di alternative
padronanza dell’architettura complessiva
competenze proprie di esercizio e gestione
capacità di far valere gli accordi contrattuali
rischi di concentrazione e a cascata
resilienza rispetto a crisi e cambiamenti geopolitici

Un fornitore internazionale non è escluso per il solo fatto di essere internazionale. Analogamente, una soluzione non è digitalmente sovrana per il solo fatto che i dati sono memorizzati in un centro di calcolo in Svizzera.

È determinante l’effettiva capacità di controllo e di azione dell’autorità competente.

11.5 Contributo di AGOV

AGOV può rafforzare la sovranità digitale di un’architettura cloud evitando che l’autenticazione primaria della persona fisica debba essere trasferita integralmente al fornitore cloud.

In tal modo possono essere ridotte in particolare le seguenti dipendenze:

password supplementari presso il fornitore cloud
procedure proprietarie di autenticazione
trasferimento completo dell’identità primaria della persona in una directory cloud commerciale
verifiche dell’identità differenti per singole piattaforme
dipendenza permanente dell’autenticazione statale da un unico ecosistema di fornitori

L’impiego di AGOV non elimina tuttavia le altre dipendenze di una piattaforma cloud. Memorizzazione dei dati, logica applicativa, amministrazione, gestione delle autorizzazioni, disponibilità e capacità di uscita devono continuare a essere valutate separatamente.

12. Conclusione

AGOV può essere utilizzato per applicazioni gestite localmente, prodotti SaaS e applicazioni su piattaforme hyperscaler.

Il collegamento avviene direttamente oppure tramite un IAM esistente o un identity broker, mediante OIDC o SAML.

I requisiti di interoperabilità specifici dei prodotti possono essere presentati regolarmente alla Cancelleria federale. Essi fanno parte della gestione del prodotto AGOV e dell’ulteriore sviluppo del servizio.

AGOV autentica la persona fisica. Non decide in merito all’ammissibilità di una piattaforma cloud, al trattamento dei dati dei cittadini o ai diritti di accesso specialistici.

L’autorità responsabile, rispettivamente la relying party, valuta la base legale, il bisogno di protezione, la sicurezza delle informazioni, la protezione dei dati, la sovranità digitale e le necessarie misure tecniche, organizzative e contrattuali.

In questo modo un’autenticazione gestita dalle autorità può essere combinata con moderne tecnologie cloud senza confondere le responsabilità tra AGOV, relying party e fornitore cloud.