Adobe Admin Console offre agli utenti enterprise un metodo per eseguire l’autenticazione con le offerte Adobe Enterprise utilizzando i sistemi di gestione dell’identità esistenti tramite l’integrazione con sistemi di gestione dell’identità abilitati SSO (Single Sign-On). Single Sign-On viene abilitato utilizzando SAML, un protocollo standard del settore che collega sistemi di gestione dell’identità aziendale a fornitori di servizi cloud come Adobe. SSO consente di scambiare in modo sicuro informazioni di autenticazione tra due parti: il fornitore di servizi (Adobe) e il provider di identità (IdP). Il fornitore di servizi invia una richiesta all’IdP, che tenta di autenticare l’utente. Dopo l’autenticazione, l’IdP invia un messaggio di risposta per consentire all’utente di accedere. Per istruzioni dettagliate, consulta Configurare Single Sign-On.

Piano

Adobe offre tre diversi tipi di identità:

  • Enterprise ID: l’organizzazione crea e possiede l’account. Adobe gestisce le credenziali ed elabora l’accesso.
  • Federated ID: l’organizzazione crea e possiede l’account, si collega alla directory enterprise tramite federazione, l’azienda o l’istituto gestisce le credenziali ed elabora gli accessi tramite Single Sign-On.
  • Adobe ID: l’utente crea e possiede l’account. Adobe gestisce le credenziali ed elabora l’accesso.

Al fine di controllare gli account e la proprietà dei dati, Adobe consiglia alle organizzazioni di scegliere gli Enterprise ID o i Federated ID. Per ulteriori informazioni, accedi qui.

Sì, puoi avere una combinazione di Enterprise ID, Federated ID e Adobe ID, ma non all’interno dello stesso dominio registrato.

Enterprise ID e Federated ID sono esclusivi a livello di dominio. Pertanto, puoi scegliere solo uno di essi. Puoi utilizzare Adobe ID insieme a Federated ID o Enterprise ID.

Ad esempio, se un’organizzazione richiede un solo dominio, l’amministratore IT può scegliere Enterprise ID o Federated ID. Se un’organizzazione richiede più domini all’interno di un Enterprise, l’amministratore IT può utilizzare un dominio con Adobe ID ed Enterprise ID e un altro dominio con Adobe ID e Federated ID, e così via. Ciò significa che, per ciascun dominio, puoi avere Enterprise ID o Federated ID insieme ad Adobe ID.

La gestione delle licenze Adobe sotto Federated ID è più veloce, semplice e sicura.

  • Gli amministratori IT controllano l’autenticazione e il ciclo di vita dell’utente.
  • Quando viene rimosso dalla directory enterprise, l’utente non dispone più dei privilegi per accedere alle app desktop, ai servizi o alle app per dispositivi mobili.
  • I Federated ID consentono alle organizzazioni di sfruttare i sistemi di gestione dell’identità utente già presenti.
  • Poiché gli utenti finali utilizzano il sistema di identità standard dell’organizzazione, il reparto IT non deve gestire un processo di gestione delle password separato.

Durante l’accesso, gli utenti finali vengono reindirizzati all’esperienza Single Sign-On standard dell’organizzazione.

La possibilità di cambiare tipi di identità su un dominio già richiesto non è ancora disponibile. Se hai richiesto uno o più domini da configurare come Enterprise ID e desideri che lo stesso dominio o gli stessi domini siano riconfigurati come Federated ID, invia una richiesta di assistenza online da Adobe Admin Console. Riceverai una notifica quando la funzionalità diventa disponibile.

Sì, puoi eseguire la federazione della tua directory enterprise e della relativa infrastruttura di accesso e autenticazione con Adobe utilizzando il tuo provider di identità compatibile SAML 2.0.

Adobe svolge un ruolo attivo nel collegamento tra il provider di identità dell’azienda e ciò a cui si fa riferimento come tenant di Okta. Adobe non si interfaccia direttamente con le directory enterprise, ma con i provider di identità.

No. Quando un dominio viene richiesto per Federated ID, gli Adobe ID esistenti con indirizzi e-mail in tale dominio non cambiano. Gli Adobe ID esistenti in Admin Console vengono mantenuti.

La procedura di migrazione delle risorse è automatizzata. Quando dai inizio a questa procedura, tutto il contenuto supportato archiviato nel tuo account Adobe ID è migrato al tuo account Enterprise ID/Federated ID. Per ulteriori informazioni, consulta Migrazione automatica delle risorse.

L’implementazione Federated ID di Adobe supporta l’autorizzazione; l’autenticazione viene gestita dal provider di identità (IdP).

In un’organizzazione Enterprise, puoi creare un collegamento tra i servizi di autenticazione (utilizzando una struttura ID aziendale come Active Directory) e Adobe. Ciò consente all’organizzazione Enterprise di ospitare l’autenticazione. Adobe non memorizza mai le password e gli amministratori IT non possono reimpostare le password o modificare i nomi utente per i Federated ID tramite Adobe Admin Console.

Sì, tramite la funzionalità Importa utenti disponibile all’interno di Adobe Admin Console. Per ulteriori informazioni, consulta Aggiunta di più utenti.

No. Adobe si interfaccia con il provider di identità e non direttamente alla directory enterprise. Tuttavia, viene offerto il supporto per importare informazioni su utenti e gruppi dalla directory enterprise in Adobe Admin Console. Per ulteriori informazioni, consulta Aggiunta di più utenti.

Adobe consiglia a tutti gli amministratori aziendali di convertire gli utenti Adobe ID in Federated ID. Puoi effettuare la migrazione da Adobe ID a Federated ID seguendo questi passaggi.

Adobe utilizza lo standard del settore sicuro e ampiamente diffuso Security Assertion Markup Language (SAML). Questo significa che l’implementazione di SSO si integra facilmente con qualsiasi provider di identità che supporta SAML 2.0.

Di seguito è riportato un elenco di alcuni IdP che sono compatibili con SAML 2.0:

  • Okta
  • Oracle Identity Federation
  • Microsoft ADFS
  • Microsoft Azure AD#
  • Federazione Google # 
  • Ping Federate
  • Salesforce IdP con certificato firmato esternamente
  • CA Federation
  • ForgeRock OpenAM
  • Shibboleth
  • NetIQ Access Manager
  • OneLogin
  • Novell Access Manager

Nota:

#Se il provider di identità è Microsoft Azure AD o Google, è possibile saltare il metodo basato su SAML e utilizzare il Connettore di Azure AD o l'SSO di Federazione Google per configurare l'SSO rispettivamente con Adobe Admin Console. Queste impostazioni vengono stabilite e gestite mediante Adobe Admin Console e utilizzano un meccanismo di sincronizzazione per gestire le identità e le autorizzazioni degli utenti.

Sì, purché segua il protocollo SAML 2.0.

Sì e il provider di identità deve essere compatibile con SAML 2.0.

Il provider di identità SAML deve disporre almeno di:

  1. Un certificato IDP
  2. Un URL di accesso IDP
  3. Un’associazione IDP: HTTP-POST o HTTP-Redirect
  4. L’URL ACS (Assertion Consumer Service) dell’IDP e deve essere in grado di accettare richieste SAML e RelayState.

Contatta il provider di identità se hai altre domande.

No, la violazione di un certificato a 2048 bit non è mai avvenuta. Inoltre, le uniche persone che hanno violato con successo anche solo un certificato a 768 bit (il gruppo Lenstra), ha stimato che la violazione di un certificato a 1024, effettuata con lo stesso hardware, richiederebbe 1000 anni (un’impresa 32.000.000 di volte più semplice che violare un certificato a 2048 bit).

Se ti interessano i dati tecnici più recenti sulle stime relative alla violazione di certificati di varie lunghezze, visita questo sito Web. Per una visione d’insieme divertente (accurata ma orientata al marketing) sulla sicurezza di questi certificati, visita questo sito Web (o il relativo sito Web con la matematica di supporto).

No, quel limite è riferito ai certificati utilizzati per codificare il canale di comunicazione tra il browser e il server. Questi certificati IdP/Okta sono invece utilizzati per firmare (non codificare) i dati trasmessi attraverso un canale codificato. Questi certificati non sono visibili dal browser, dato che sono utilizzati solo tra Adobe/Okta e l’IdP del cliente.

Puoi ottenere ottimi certificati, di livello commerciale a 2048 bit per circa $10/anno di durata. Inoltre, i certificati utilizzati dagli IdP possono essere autofirmati; questo significa che possono essere generati gratuitamente con software open-source.

No, perché sono presenti due livelli di cifratura avanzata che verificano l’identità dell’IdP, che devono essere violati prima che qualcuno possa impersonare l’IdP. Inoltre, entrambi questi livelli non sono autofirmati. Questo significa che sarebbe necessario violare non solo il certificato che impone la cifratura, ma anche il certificato del firmatario che ha generato quel certificato.

Per il numero di telefono e l’indirizzo e-mail dell’Assistenza clienti premium, consulta l’email di benvenuto e l’allegato PDF inviati all’amministratore dell’account.

Lo stesso endpoint URL può essere utilizzato per più directory. Tuttavia, i metadati della federazione saranno gestiti separatamente per ciascun IdP. Pertanto, l’endpoint dell’IdP comune dovrà gestire le richieste il cui contenuto è diverso.

Sì, se l’integrazione SAML della directory utilizza il formato username e i nomi utente in Admin Console sono identici agli ID persistenti forniti. Tuttavia, ciò richiederebbe che gli ID persistenti siano disponibili quando gli utenti sono sincronizzati in Admin Console. Questo non è uno scenario comune e quindi, nella pratica, il formato persistente per l’elemento NameID non sarebbe supportato.

No. Il valore dell’elemento NameID è usato come username in Admin Console; NameQualifier è ignorato.

L’asserzione per nome, cognome ed e-mail per ciascun utente e obbligatoria. Tuttavia, possono non corrispondere ai dati nella directory, ma l’e-mail deve essere univoca per ciascun utente.

Solo come eccezione. Tuttavia, questa soluzione non è consigliata in quanto comporta un incremento del carico di lavoro amministrativo richiesto per aggiornare qualsiasi parte della configurazione.

No. Questa funzione non è attualmente supportata.

Per impostazione predefinita, i certificati Okta sono autofirmati. Come eccezione (e probabilmente a pagamento) è possibile avere invece i certificati firmati da una CA pubblica.

Procedure

Per istruzioni dettagliate, consulta Configurare Single Sign-On per impostare SSO con app desktop, servizi e app per dispositivi mobili Adobe.

No. L’invio di notifiche agli utenti finali tramite Admin Console non è supportato. In qualità di cliente enterprise, devi distribuire i tuoi annunci dopo che gli utenti sono pronti a utilizzare SSO con il software e i servizi Adobe.

No. Se rimuovi o disattivi un utente o un ID dalla tua directory enterprise, l’utente o l’ID non verrà rimosso o disattivato automaticamente da Adobe Admin Console. Tuttavia, l’utente non dispone più dei diritti e non può effettuare l’accesso alle app desktop, ai servizi, alle app per dispositivi mobili Adobe Creative Cloud o alle app Acrobat DC. Dovrai rimuovere manualmente l’utente o l’ID da Admin Console.

Sì, devi utilizzare Adobe Admin Console per gestire utenti, gruppi e diritti. Notare, tuttavia, che dopo aver creato gruppi in Admin Console, puoi caricare un file CSV che include le informazioni di utenti e gruppi. Questo crea l’account utente e lo inserisce nel gruppo designato.

No, non è possibile reimpostare le password per i Federated ID utilizzando Adobe Admin Console. Adobe non memorizza le credenziali utente. Utilizza il provider di identità per la gestione utenti.

Questo prodotto è concesso in licenza in base alla licenza di Attribuzione-Non commerciale-Condividi allo stesso modo 3.0 Unported di Creative Commons.  I post su Twitter™ e Facebook non sono coperti dai termini di Creative Commons.

Note legali   |   Informativa sulla privacy online