Startseite Navigation Inhalt Kontakt Sitemap Suche

Collegare le applicazioni a eIAM

Scheda informativa relativa agli acquisti
V1.7 2024-10-09 ▪ Obbligatorio anche per gli sviluppi interni e altre forme di introduzione di nuovo software

La presente scheda informativa deve essere parte integrante dei requisiti da adempiere all’acquisto delle soluzioni TIC in questione; può essere citata tramite l’URL .

La presente scheda informativa non si applica all’utilizzo di AGOV da parte dei Cantoni e dei Comuni. Le applicazioni della Confederazione non vengono collegate direttamente ad AGOV, ma a eIAM come previsto dalla presente scheda informativa; AGOV è automaticamente disponibile nell’ecosistema eIAM.


Per la maggior parte delle applicazioni, comprese le app native per dispositivi mobili, si applica un obbligo di sottoscrizione eIAM in conformità con . Valutare l'obbligo di sottoscrizione per il proprio caso nella Lista di controllo Ⅴ’’’

dispiegare tutto ▼

Ⅰ INTRODUZIONE

La presente scheda informativa tratta il collegamento delle applicazioni a eIAM.

INTRODUZIONE
×

Contesto

Le applicazioni web e le applicazioni mobili native dell’Amministrazione federale (di seguito «applicazioni»), devono ottenere i servizi di autenticazione presso il servizio standard pertinente dell’Amministrazione federale, indipendentemente dal luogo di utilizzo, dal metodo di utilizzo e dalla necessità di protezione (cfr. ). Per le applicazioni delle autorità giudiziarie e dei loro affiliati, è necessario utilizzare il servizio «portale SSO» del DFGP. In tutti gli altri casi, va fatto riferimento al servizio eIAM (il collegamento a eIAM è possibile sia in modo diretto che indiretto; metodi indiretti: tramite ePortal o IAM-DEFR).

Obbligo di acquisto e importanza degli acquisti

In considerazione dell’obbligo di acquisto dei servizi di autenticazione e della conseguente esclusione di altri servizi IAM (proprietari), ad esempio integrati nelle applicazioni o nei loro ambienti operativi (SaaS e altri metodi di utilizzo del cloud), la possibilità di collegamento, se possibile semplice, al servizio standard è un CRITERIO OBBLIGATORIO. Negli acquisti, la presente scheda informativa costituisce un allegato da utilizzare come fonte per la definizione dei CRITERI OBBLIGATORI, nonché dei CRITERI FACOLTATIVI (aspetti della possibilità di collegamento semplice).

Dettagli sull’obbligo di acquisto, delimitazione

L’obbligo di acquisto riguarda le identità elettroniche, le loro credenziali e i conseguenti servizi di autenticazione. Di conseguenza, le applicazioni o i loro ambienti operativi (ad es. SaaS e altri metodi di utilizzo del cloud) possono gestire in autonomia i propri utenti con i dati di autenticazione (diritti come ruoli e attributi), a condizione che i servizi di autenticazione siano ottenuti esclusivamente presso eIAM.

Ⅱ CRITERI

È necessario fare una distinzione fra la possibilità di collegamento di principio e la semplicità della relativa configurazione.

Ⅱ’ CRITERI OBBLIGATORI
×

CRITERIO OBBLIGATORIO 1: possibilità di collegamento di principio

Questo criterio è dato se le applicazioni possono federarsi con eIAM tramite uno dei protocolli seguenti:
  1. OIDC con Authorization Code Flow & PKCE (Proof Key of Code Exchange)
  2. SAML 2.0 con binding per browser POST
  3. SAML 2.0 con binding per browser di reindirizzamento
  4. WS-Federation

CRITERIO OBBLIGATORIO 2: priorità assegnata al fornitore di servizi, compresi dati e trasporto

eIAM lavora, come mostrato nel video a partire dal minuto 7, seguendo il principio della priorità assegnata al fornitore di servizi «Service Provider First». Ciò significa che quando l’utente finale avvia l’applicazione di destinazione, questa riconosce l’utente come non ancora autenticato. Di conseguenza il browser lo reindirizza su eIAM in termini di forma e contenuto in conformità con i protocolli OIDC, SAML 2.0 o WS-Federation.

Questo criterio comprende gli aspetti concernenti i dati e il trasporto elencati di seguito.

  • L’applicazione DEVE* essere in grado di avviare Single Logout tramite il protocollo di federazione
  • L’applicazione DEVE essere in grado di firmare la richiesta di autenticazione (criterio facoltativo; soltanto se non è disponibile alcun URL fisso dell’Assertion Consumer Service)
  • L’applicazione DEVE* accettare i token di accesso
  • eIAM riceve e trasmette le notifiche della federazione soltanto tramite le connessioni sicure del livello di trasporto (Transport Layer, TLS)
* Anche se non è possibile adempiere il criterio, il collegamento a eIAM rimane comunque possibile.

Ⅱ’’ CRITERI FACOLTATIVI (Aspetti della connettività semplice)
×

Siccome il punto di contatto con eIAM non deve per forza trovarsi direttamente sull’applicazione, può essere anche una facciata del gestore. Qui di seguito si parla di punto di contatto tra eIAM e l’obiettivo, anziché tra eIAM e l’applicazione.

CRITERIO FACOLTATIVO 1: utilizzo dei token dei protocolli OIDC, SAML 2.0 o WS-Federation in base allo standard eIAM

eIAM scrive nei token dati specifici in campi specifici. Effettuare il collegamento a eIAM risulta più semplice se l’obiettivo è in grado di gestirlo(al riguardo, cfr. la documentazione su ).

Se il CRITERIO FACOLTATIVO 1 non è adempiuto e se l’obiettivo necessita di altri campi, eIAM offre una certa flessibilità (descrizione / mapping) che genera eventualmente costi. Le modifiche dei token eIAM specifiche per le applicazioni di destinazione (protocolli OIDC, SAML 2.0, WS-Federation) devono essere richieste tramite il processo P035 ().

CRITERIO FACOLTATIVO 2: OIDC, SAML 2.0 o WS-Federation come unico punto di contatto (senza interfacce)

Effettuare il collegamento risulta più semplice se uno dei suddetti protocolli è l’unico punto di contatto tra eIAM e l’obiettivo. In altre parole, tra eIAM e l’obiettivo non devono sussistere interfacce che a) necessitano di leggere i dati di eIAM dell’utente; b) devono essere registrate secondo eIAM; o c) in cui eIAM deve inviare (provisioning) all’obiettivo i token risultanti tramite un canale diverso da quello derivante dai protocolli OIDC, SAML 2.0 o WS-Federation.
Ai fini dell’obiettivo, ciò significa che i token risultanti di OIDC, SAML 2.0 o WS-Federation sono le uniche fonti esterne contenenti le informazioni dell’utente. Inoltre, se è necessario che l’obiettivo salvi dati dell’utente, l’operazione deve essere eseguita appena in tempo dai token.

Se il CRITERIO FACOLTATIVO 2 non è adempiuto e se l’obiettivo necessita di interfacce ai sensi dei punti a), b) e/o c), si prega di consultare il prossimo capitolo.


Ⅱ’’’ MANCATO RISPETTO DEI CRITERI (Risoluzione dell'incompatibilità eIAM risultante)
×

Se vengono acquisite soluzioni ICT, comprese soluzioni cloud come SaaS, che non possono essere collegate a eIAM secondo lo standard eIAM, il proprietario dell'applicazione è obbligato a far sviluppare e gestire un ponte di autenticazione sotto forma di adattatore. Vedere .

Ⅲ INTERFACCE

Le interfacce di eIAM non sono adattate al target, ma viceversa.

INTERFACCE
×

Se è necessario utilizzare le interfacce elencate di seguito, si prega di contattare quanto prima il settore TDT della CaF e l’UFIT.

Se le interfacce menzionate in precedenza o in seguito risultano necessarie, il collegamento a eIAM rimane possibile, però occorre seguire la procedura per le interfacce di eIAM. Non sono queste ultime ad adattarsi all’obiettivo, bensì il contrario.

Se questa operazione dovesse portare a un’incompatibilità tra l’obiettivo ed eIAM e se l’obiettivo non può essere adattato (gli offerenti SaaS non garantiscono sempre la loro disponibilità), il collegamento a eIAM è compromesso. Tali applicazioni non dovrebbero essere acquistate. Se l’acquisto fosse comunque necessario, il cliente deve far sviluppare o far gestire un adattatore come applicazione specializzata intermediaria dall’UFIT o da chi per esso a spese proprie (cfr. ). Una siffatta incompatibilità non comporta automaticamente un’autorizzazione di deroga per l’esercizio senza eIAM.

Occorre osservare che le sole indicazioni del produttore come «compatibile con SAML 2.0», «compatibile con OIDC» o «compatibile con WS-Federation» non sono sufficienti. Ad esempio: SaaS X. è compatibile con SAML 2.0, ma necessita di un provisioning dell’utente sulla sua API proprietaria. È escluso che, quale parte di un servizio standard, eIAM fornisca questo provisioning proprietario (principio di riutilizzabilità). Per il SaaS X. è quindi stato sviluppato un adattatore come applicazione specializzata intermediaria (cfr. ).

Interfaccia eIAM-RDM

eIAM-RDM permette di invitare gli utenti in remoto in eIAM tramite un REST (Representational State Transfer) API. RDM è l’acronimo di «Remote Delegated Management», ossia gestione delegata in remoto. In linea di principio, con «gestione delegata» si intende che non è il responsabile delle autorizzazioni di un ufficio a rilasciare le autorizzazioni BVA, bensì qualcun altro (cfr. servizio 6 e video di eIAM al minuto 11). Quando si utilizza RDM, l’invito in eIAM non viene emesso da una persona, ma da una macchina. In entrambi i casi, eIAM spedisce un’e-mail alla persona invitata che contiene un messaggio di benvenuto e un codice di registrazione. Utilizzando una sola volta un’identità digitale adeguata scelta liberamente, è possibile inserire il codice di registrazione. L’identità digitale viene quindi collegata all’applicazione di destinazione tramite eIAM.
Osservazione riguardante l’utilizzo: per decidere se utilizzare la gestione delegata di eIAM in generale e, se del caso, tramite RDM, è consigliabile basarsi sulla modellazione dei processi di registrazione, cioè sul modo in cui gli utenti accedono per la prima volta all’applicazione di destinazione (v. la sezione più in basso PROCEDURE DI REGISTRAZIONE).

Interfaccia eIAM-AMW

eIAM-AMW offre un SOAP (Simple Object Access Protocol) API che permette di leggere e modificare i dati degli utenti e le strutture organizzative in eIAM. In altre parole, eIAM-AMW è l’interfaccia con i mandanti di accesso eIAM.
Osservazione riguardante l’utilizzo: l’utilizzo di quest’interfaccia è l’antitesi del summenzionato CRITERIO FACOLTATIVO 2. Si raccomanda di riflettere su come il CRITERIO FACOLTATIVO 2 possa essere adempiuto seguendo il principio di semplicità.

Interfaccia eIAM-LDS

eIAM-LDS permette di leggere i dati degli utenti tramite il protocollo Lightweight Directory Access (LDAP). L’interfaccia LDAP è disponibile solo per le applicazioni gestibili nelle reti dell’Amministrazione federale. A questo scopo, eIAM mette a disposizione le informazioni degli utenti di un’applicazione nel rispettivo registro.
Osservazione riguardante l’utilizzo: l’utilizzo di quest’interfaccia è l’antitesi del summenzionato CRITERIO FACOLTATIVO 2. Si raccomanda di riflettere su come il CRITERIO FACOLTATIVO 2 possa essere adempiuto seguendo il principio di semplicità.

Ⅳ ALTRI ASPETTI DA CONSIDERARE

ALTRI ASPETTI DA CONSIDERARE
×

SENZA O CON GESTIONE DEGLI ACCESSI

Senza gestione degli accessi (Authentication Only): avviene quando l’applicazione di destinazione deve ottenere da eIAM esclusivamente l’identità di chi effettua l’accesso (per poterlo riconoscere). In altre parole, in eIAM non vengono gestiti dati di autorizzazione (ruoli, diritti ecc.) e non si svolge alcuna procedura di registrazione. Siccome tale gestione degli accessi è interamente circoscritta all’interno dell’applicazione di destinazione, l’intervento dei mandanti di accesso eIAM non è quindi necessario. Viene indicato un collegamento diretto dell’applicazione al trustbroker della Confederazione (BTB) come procedura di collegamento semplice.

Con gestione degli accessi: Avviene quando i dati di autorizzazione (diritti, ruoli ecc.) dovrebbero essere gestiti interamente o in parte in eIAM (per poterli trasmettere alla procedura d’accesso dell’applicazione di destinazione) e/o quando eIAM deve svolgere la procedura di registrazione per l’applicazione di destinazione (rispondere alle richieste d’accesso degli utenti o viceversa, invitare gli utenti via e-mail o tramite lettera, inclusa la gestione delegata), l’utilizzo di un mandante d’accesso eIAM è obbligatorio.Per i ruoli, diritti ecc. da copiare nei mandanti d’accesso eIAM vale quanto segue: in primo luogo, il numero non deve essere elevato (non deve raggiungere il centinaio); in secondo luogo, le modifiche (aggiungere, rimuovere, rinominare ruoli, diritti ecc.) non devono essere frequenti (mandato all’UFIT sempre necessario); in terzo luogo, il caricamento dinamico di ruoli, diritti ecc. da fonti esterne non è necessario.

PROCEDURE DI REGISTRAZIONE

Si raccomanda di indicare le possibili procedure di registrazione, incluse le proprie preferite, nella documentazione del bando. Il termine «registrazione» descrive il processo che porta l’utente a poter utilizzare un’applicazione di destinazione con la propria identità digitale. La descrizione delle procedure di registrazione è disponibile su → Servizio 5. Gli offerenti devono rispondere a tali procedure e descrivere come queste possono funzionare con la loro soluzione. A tale scopo, le autorità che indicono i bandi come gli offerenti possono consultare l’UFIT e il settore TDT della CaF.

BISOGNO DI PROTEZIONE ELEVATO

eIAM applica le policy delle zone alle zone di rete SZ+ e alla rete dell’Amministrazione federale. Permette di accedervi solo tramite un’autenticazione precedente con una QoA di almeno 50.

SERVIZIO eIAM DELLE SOLUZIONI CLOUD

L’approvvigionamento delle applicazioni in AWS, Azure e di altri cloud viene applicato con successo. In particolare, Azure definisce numerose premesse. Pertanto si raccomanda di coinvolgere quanto prima l’UFIT e il settore TDT della CaF nell’acquisto di soluzioni cloud. SaaS e altre configurazioni cloud sono soggetti all’obbligo di acquisto .

Ⅴ LISTE DI CONTROLLO

Ⅴ’ LISTA DI CONTROLLO: CRITERI E ASPETTI
×

Scaricare liste di controllo V' (WORD DOCX)

 Ⅴ’ LISTA DI CONTROLLO: CRITERI E ASPETTI

CRITERIO OBBLIGATORIO 1: possibilità di collegamento di principio
☐ adempiuto, segnatamente tramite il protocollo ____________

CRITERIO OBBLIGATORIO 2: priorità assegnata al fornitore di servizi, compresi dati e trasporto
☐ adempiuto, compresi dati e trasporto

CRITERIO FACOLTATIVO 1: utilizzo dei token dei protocolli OIDC, SAML 2.0 o WS-Federation in base allo standard eIAM
☐ sì, adempiuto
☐ no, l’obiettivo necessita di altri campi / dati
      (si richiede una descrizione precisa da parte dell’offerente; si raccomanda una verifica delle offerte da parte del settore TDT della CaF e dell’UFIT)

CRITERIO FACOLTATIVO 2: OIDC, SAML 2.0 o WS-Federation come unico punto di contatto (senza interfacce)
☐ sì, adempiuto
☐ no, l’obiettivo necessita delle interfacce per collegarsi a eIAM
      (si richiede una descrizione precisa da parte dell’offerente; si raccomanda una verifica delle offerte da parte del settore TDT della CaF e dell’UFIT)

GESTIONE DEGLI ACCESSI
☐ Senza gestione degli accessi eIAM (Authentication Only),
      ossia nessun diritto, ruolo ecc. in eIAM, ma nell’applicazione di destinazione
☐ Con gestione degli accessi eIAM, perché quest’ultimo gestisce
☐ ☐tutti o ☐alcuni diritti e ruoli (numero: ______ )
      e/o ☐effettua procedure di registrazione / ☐garantisce la gestione delegata
☐ Gli offerenti hanno descritto questa procedura

PROCEDURA DI REGISTRAZIONE
☐ Obsoleta poiché Authentication Only
☐ La preferenza e lo scenario degli acquirenti sono definiti
☐ Gli offerenti hanno descritto questa procedura

TIPO DI ESERCIZIO
Presso l’UFIT (Atlantica, VM ...), all’esterno, con SaaS, con una soluzione cloud ecc.

☐ __________________________________________


Ⅴ’’ LISTA DI CONTROLLO: PROCEDURE DI ACCESSO E QUALITÀ
×

Scaricare liste di controllo V'' (WORD DOCX)

 Ⅴ’’ LISTA DI CONTROLLO: PROCEDURE DI ACCESSO E QUALITÀ


Nelle sezioni b) e c) sottostanti è possibile rispondere «sì» solo una volta per domanda.

All’interno delle sezioni b) e c) i requisiti sono indicati partendo dal livello più basso a quello più elevato. I requisiti elevati possono derivare da requisiti aziendali. Non è tuttavia necessario un livellamento verso l’alto, basta «soltanto» rispettare le direttive TIC della Confederazione, in particolare la direttiva Si001.

a) Procedura di accesso:

☐sì / ☐no
I titolari di un account FED-LOGIN (collaboratori dell’Amministrazione federale e affiliati che possiedono un account come alcuni collaboratori presso i Cantoni) possono effettuare l’accesso tramite FED-LOGIN.

☐sì / ☐no
(Anche) le persone sprovviste di un account FED-LOGIN devono poter effettuare l’accesso (partner, privati ecc. tramite AGOV, CH-LOGIN e fornitori d’identità terzi affiliati)

b) Qualità dell’autenticazione, verifica (o accertamento) dell’identità:

☐sì / ☐no
È sufficiente che l’utente stesso dichiari i propri dati durante la procedura di accesso (aprendo un relativo account). Non sono necessarie ulteriori verifiche.
Motivazione: _____________________________________________________

☐sì / ☐no
È sufficiente che l’utente stesso dichiari i propri dati durante la procedura di accesso (aprendo un relativo account), ma le informazioni devono corrispondere ai dati di registro (ad es. banca dati degli indirizzi de La Posta, banca dati RU).
Motivazione: _____________________________________________________

☐sì / ☐no
I dati relativi alla persona titolare di un accesso devono essere affidabili e quindi basati su un documento d’identità ufficiale depositato e munito di foto. Viene effettuato un confronto tra la foto e il viso della persona.
Motivazione: _____________________________________________________

c) Qualità dell’autenticazione, «hardening» dei fattori di login:

☐sì / ☐no
I fattori di login senza «hardening», come le password e i codici mTAN inviati per SMS, possono essere utilizzati. Per quanto concerne l’Amministrazione federale, anche Kerberos è considerato senza «hardening».
Motivazione: _____________________________________________________

☐sì / ☐no
È possibile utilizzare esclusivamente i fattori di accesso con «hardening» (ad es. Access App basata su FIDO, chiavette FIDO, smartcard).
Motivazione: _____________________________________________________


Il settore TDT della CaF e l’UFIT offrono una consulenza sui tipi di esercizio che non generano costi.


Ⅴ’’’ LISTA DI CONTROLLO IAM FORNITURA AMMIN. FEDERALE, CAPITOLATO, OBBLIGO DI FORNITURA
unorthodoxesprungmarke
×

Scaricare liste di controllo V''' (WORD DOCX)

 Ⅴ’’’ LISTA DI CONTROLLO PER L’OTTENIMENTO DI SERVIZI DI GESTIONE DELLE IDENTITÀ E DEGLI ACCESSI (SERVIZI IAM) DELL’AMMINISTRAZIONE FEDERALE, DIRETTIVE, OBBLIGO DI ACQUISTO

In sintesi
×

Nell’Amministrazione federale, con «servizi IAM» si intendono tutte le procedure che utilizzano un’identità digitale per l’autenticazione di chi effettua l’accesso (identity), seguita eventualmente da dati di autorizzazione aggiuntivi (access).

L’obiettivo di questa lista di controllo è chiarire la differenza tra le due domande seguenti:

  1. Quale sistema IAM si può/deve utilizzare?
  2. Quale livello di qualità deve raggiungere il servizio di autenticazione?

Le due domande si basano su fonti d’informazione diverse difficili da riassumere:

Per quanto riguarda il punto 1, in primo luogo è importante l’obbligo di acquisto del rispettivo servizio standard, che offre due servizi e, in secondo luogo, i casi dedicati non sottostanno all’obbligo di acquisto.

Nel punto 2, i risultati dell’analisi del bisogno di protezione sono determinanti, ma sono comunque completati da varie considerazioni aggiuntive.

Nella maggior parte dei casi, la presente lista di controllo risponde a entrambe le domande in modo diretto.

Lista di controllo

Questa lista di controllo non è specifica di eIAM e può quindi essere applicata a ogni tipo di contesto all’interno dell’Amministrazione federale. Si prega di rispondere a ogni domanda con "sì" o "no". Le domande si riferiscono nel concreto a un’applicazione di destinazione oppure a un portale con più applicazioni di destinazione.

Nome dell’applicazione o del portale: _________________________________
(Di seguito «destinazione». Anche i sistemi IAM intermedi (ad es. PAMS dell’ePortal), che comprendono più applicazioni, possono essere considerati «destinazioni».)


    A. SOGGETTI
  1. ☐sì / ☐no: L’accesso (login) per poter usare la destinazione deve essere effettuato da persone fisiche?


  2. ☐sì / ☐no: L’accesso (login) per poter usare la destinazione deve essere effettuato da macchine informatiche?
    3. Se è stato risposto due volte «no», non è necessario alcun servizio IAM. Non si applica la presente lista di controllo.
    Se alla domanda 2 è stato risposto «sì» , si prega di contattare il settore Trasformazione digitale e governance delle TIC della Cancelleria federale (CaF TDT).


    B. OGGETTO DI DESTINAZIONE (APPLICAZIONE DI DESTINAZIONE)
  3. ☐sì / ☐no: La destinazione è un’applicazione web (che si apre nel browser)?
    4. Se è stato risposto «sì», è necessario un obbligo di acquisto (L’obbligo di acquisto si applica per l’Amministrazione federale centrale. Quella decentralizzata può acquistare a determinate condizioni). Si applica indipendentemente dall’host o dalla sua zona. Anche i SaaS come Atlassian Cloud ecc. necessitano dell’obbligo di acquisto.


  4. ☐sì / ☐no: La destinazione è un’app mobile (che si usa sullo smartphone o sul tablet)?
    5. Se è stato risposto «sì», è necessario un obbligo di acquisto (L’obbligo di acquisto si applica per l’Amministrazione federale centrale. Quella decentralizzata può acquistare a determinate condizioni).


  5. ☐sì / ☐no: La destinazione è un’applicazione client da installare sul dispositivo (ad es. Fat Client o Rich Client)?
    Tecnologia indesiderata, contattare il CaF TDT


  6. ☐sì / ☐no: La destinazione è un’applicazione client su un server (ad es. gestita in remoto tramite emulazione di terminale come Citrix)?
    Tecnologia indesiderata, contattare il CaF TDT


  7. ☐sì / ☐no: La destinazione è un’entità IOT (ad es. motore per le tapparelle, apriporte, tornello che legge documenti (ad es. negli aeroporti), robot/automi incl. robot software su client BAB o altri ecc.)?
    Per quanto concerne IAM per l’IOT si prega di contattare il CaF TDT. L’obbligo di acquisto è applicabile, la progettazione della prassi è in corso.


  8. ☐sì / ☐no: È stato risposto «no» a tutte le precedenti domande della sezione B.?
    In tal caso, contattare il CaF TDT.


    C. RESPONSABILITÀ DELLA DESTINAZIONE (responsabile specialistico delle applicazioni RA)
  9. ☐sì / ☐no: Il committente dell’utilizzo della destinazione appartiene all’Amministrazione federale centrale o è assoggettato all’Ordinanza sulla digitalizzazione (ODigi)?
    10. Se è stato risposto «no», l’obbligo di acquisto della sezione A. è obsoleto. Per chi non appartiene all’Amministrazione federale centrale (cerchie esterne), l’acquisto volontario a determinate condizioni è possibile e spesso consigliato.


    D. BISOGNO DI PROTEZIONE
    Importante: il bisogno di protezione NON ha alcun influsso su quanto affermato sull’obbligo di acquisto nelle sezioni dalla A. alla C. !
  10. ☐sì / ☐no: Il risultato dell’analisi del bisogno di protezione è «Protezione di base»?
    11. Se è stato risposto «sì», in conformità allo standard Si001 il servizio di autenticazione deve raggiungere il livello «medio» e secondo www.eiam.admin.ch/qoa almeno QoA30. In altre parole, è richiesta un’autenticazione a due fattori senza necessità di verifica dell’identità del soggetto.


  11. ☐sì / ☐no: Il risultato dell’analisi del bisogno di protezione è «Bisogno di protezione elevato»?
    12. Se è stato risposto «sì», in conformità allo standard Si001, il servizio di autenticazione deve raggiungere il livello «elevato» e secondo www.eiam.admin.ch/qoa almeno QoA50. In altre parole, è richiesta un’autenticazione a due fattori con «hardening» per il secondo fattore e verifica sostanziale dell’identità (accertamento) del soggetto.


    E. HOSTING DELLA DESTINAZIONE
    Importante: il bisogno di protezione esclude gli hosting che non soddisfano i suoi requisiti!
  12. ☐sì / ☐no: La destinazione è gestita in una zona server con elevato bisogno di protezione, ad esempio Server Zone+ (SZ+) dell’Amministrazione federale?
    13. Un’eventuale situazione contraria non è applicabile. Se è stato risposto «sì», in conformità allo standard Si001, il servizio di autenticazione deve raggiungere il livello «elevato» e secondo www.eiam.admin.ch/qoa almeno QoA50. In altre parole, è richiesta un’autenticazione a due fattori con «hardening» per il secondo fattore e verifica sostanziale dell’identità (accertamento) del soggetto.


  13. ☐sì / ☐no: La destinazione è gestita in un’altra zona server dell’Amministrazione federale?
    14. Nessun influsso su quanto affermato sull’obbligo di acquisto nelle sezioni dalla A. alla C.


  14. ☐sì / ☐no: La destinazione è gestita al di fuori dell’Amministrazione federale da un gestore esterno, che si occupa anche di tutte le soluzioni cloud (ad es. Abraxas, Azure, AWS, Google ecc.)?
    15. Nessun influsso su quanto affermato sull’obbligo di acquisto nelle sezioni dalla A. alla C.


    F. TIPO DI UTENZA
  15. ☐sì / ☐no: I collaboratori dell’Amministrazione federale (interni, esterni, affiliati registrati (ad es. Cantoni)) devono poter accedere alla destinazione?
    16. Se è stato risposto «sì»: questo tipo di utenza deve utilizzare la procedura di accesso di eIAM «FED-LOGIN» (si prega di notare che FED-LOGIN può essere utilizzato anche senza smartcard, cfr. «totally smartcardless» ). IMPORTANTE: il tipo di utenza NON ha alcun influsso su quanto affermato sull’obbligo di acquisto nelle sezioni dalla A. alla C.; ciò vale anche per i SaaS a noleggio (ad es. soluzioni Atlassian Cloud, lavagne Miro, Power BI ecc.)!


  16. ☐sì / ☐no: Anche altre persone devono poter accedere alla destinazione, oltre a quelle indicate alla domanda 15? Si tratta ad esempio di cittadini, partner non registrati in FED-LOGIN (incl. Cantoni) ecc.
    17. Se è stato risposto «sì»: questo tipo di utenza deve utilizzare la procedura di accesso di eIAM «AGOV» (incl. IdP terzi associati come eduID, eID cantonali, CH-LOGIN in fase di eliminazione). IMPORTANTE: il tipo di utenza NON ha alcun influsso su quanto affermato sull’obbligo di acquisto nelle sezioni dalla A. alla C.; ciò vale anche per i SaaS a noleggio (ad es. soluzioni Atlassian Cloud, lavagne Miro ecc.)!


  17. ☐sì / ☐no: I titolari dell'e-ID dello Stato svizzero devono potersi autenticare direttamente con l'e-ID?
    La risposta a questa domanda non ha alcuna influenza sull'obbligo di acquisto; l'autenticazione dell'e-ID deve essere ottenuta tramite il servizio standard IAM, ovvero tramite la componente AGOV del servizio standard IAM. Non è consentito il collegamento diretto dell'e-ID all'applicazione di destinazione ai fini dell'autenticazione (login).


  18. ☐sì / ☐no: Anche persone con fornitori di identità speciali (i cosiddetti IdP di settore secondo il ) devono poter accedere alla destinazione (ad es. collaboratori del settore sanitario con il fornitore di identità HIN)?
    19. Se è stato risposto «sì»: è possibile fare richiesta al settore TDT della CaF. IMPORTANTE: l’obbligo di acquisto di eIAM si applica anche in questo caso. Gli IdP di settore devono essere acquistati tramite eIAM e non possono essere collegati ad alcun altro sistema (sistemi di destinazione, sistemi IAM intermedi) all’infuori di eIAM. Il tipo di utenza NON ha alcun influsso su quanto affermato sull’obbligo di acquisto nelle sezioni dalla A. alla C.; ciò vale anche per i SaaS a noleggio (ad es. soluzioni Atlassian Cloud, lavagne Miro ecc.)!


    G. GESTIONE DEGLI ACCESSI
  19. ☐yes / ☐no: le persone devono essere invitate via e-mail a utilizzare l'applicazione target tramite eIAM (e-mail con codice di onboarding)?
    La risposta a questa domanda non ha alcuna influenza sull'obbligo di sottoscrizione. In caso affermativo, è necessario utilizzare la gestione delegata di eIAM e la risposta alla domanda successiva deve essere “sì”. Tuttavia, l'applicazione di destinazione può gestire autonomamente le e-mail di invito.

  20. ☐yes / ☐no: le persone devono essere assegnati ruoli e diritti in eIAM?
    La risposta a questa domanda non ha alcuna influenza sull'obbligo di acquisto (l'obbligo di acquisto si applica alle identità e all'autenticazione, ma non alla gestione degli accessi). I ruoli e i diritti possono essere mantenuti in eIAM o nell'applicazione di destinazione, quindi anche in forma mista. Versioni estreme: nulla per quanto riguarda la gestione degli accessi in eIAM, tutto nell'applicazione di destinazione (eIAM = Authentication Only) contro nulla per quanto riguarda la gestione degli accessi nell'applicazione di destinazione, tutto in eIAM (eIAM = with Access Mandant), cioè l'applicazione segue le istruzioni del token di autenticazione eIAM.


    H. DIFFERENZIAZIONE DELL’OBBLIGO DI ACQUISTO
  21. ☐sì / ☐no: In base alle sezioni dalla A. alla C. risulta l’obbligo di acquisto del servizio standard e la destinazione è insediata nel settore della giustizia/polizia?
    22. Se è stato risposto «sì»: per il servizio standard «Gestione delle identità e degli accessi» dell’Amministrazione federale () va utilizzato il servizio «Portale SSO» del DFGP, anziché eIAM.
    Entrambi i servizi sono gestiti dal settore TDT della CaF.


    I. INFORMAZIONI PER LE APPLICAZIONI NEI PORTALI
  22. Per le applicazioni nei portali come Easygov, ePortal, eGov del DATEC ecc., si applica l’obbligo di acquisto , in base al quale il portale può rinunciare alla transizione delle singole applicazioni su eIAM, così che non siano esse a dover essere collegate a eIAM, bensì il portale stesso. Le procedure di accesso proprie del portale o le connessioni dirette dei fornitori di identità non sono ammesse.


    J. INFORMAZIONI DETTAGLIATE SU KERBEROS
  23. Le applicazioni web e le app mobili native possono utilizzare direttamente Kerberos solo tramite autorizzazione di deroga. Devono passare attraverso eIAM.

  24. Le altre applicazioni e la burotica possono utilizzare direttamente Kerberos a date condizioni (consultare il settore TDT della CaF).

  25. Kerberos NON raggiunge il livello «elevato» secondo lo standard Si001, fatta eccezione se, in primo luogo, la risorsa è integrata direttamente in una foresta di utenti dell’Amministrazione federale (necessaria approvazione del settore CaF TDT) e se, in secondo luogo, è dimostrabile che l’autenticazione sul client in uso ha forzato l’utilizzo della smartcard (ad es. non adempiuto su Mobile VDI).


    K. INFORMAZIONI DETTAGLIATE SU AGOV
  26. L’amministrazione federale centrale utilizza AGOV "direct only"* solo in rarissimi casi eccezionali soggetti ad autorizzazione; altrimenti, utilizza AGOV tramite il "full"* eIAM. Sono tuttavia previste eccezioni, in caso di domande: .

  27. L’Amministrazione federale decentrale può acquistare AGOV tramite eIAM (sussistono condizioni speciali) o AGOV «direct only»*.

  28. Altre autorità svizzere (Cantoni, Comuni, aziende miste) acquistano AGOV «direct only»* e non AGOV tramite «full»* eIAM, se sussiste la compatibilità con la LMeCA.
*
Schema «full» eIAM: Fornitore di identità AGOV ➤ Sistema IAM eIAM ➤ Applicazione di destinazione (o sistema IAM intermedio)
Schema AGOV «direct only»: Fornitore di identità AGOV ➤ Applicazione di destinazione (o sistema IAM intermedio)