Documentazione Adobe Pass Autenticazione Adobe Pass

(Legacy) Panoramica di iOS/tvOS SDK iostvos-sdk-overview

Last update: Sat Dec 14 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

Argomenti:
Autenticazione

NOTE

Il contenuto di questa pagina viene fornito solo a scopo informativo. L’utilizzo di questa API richiede una licenza corrente da Adobe. Non è consentito alcun uso non autorizzato.

IMPORTANT

Assicurati di essere sempre informato sugli ultimi annunci di prodotto per l'autenticazione di Adobe Pass e sulle timeline di disattivazione aggregate nella pagina Annunci di prodotto.

Introduzione intro

iOS AccessEnabler è una libreria Objective C iOS/tvOS che consente alle app mobili di utilizzare l’autenticazione Adobe Pass per i servizi di adesione di TV Everywhere. L'implementazione è costituita dall'interfaccia AccessEnabler che definisce l'API di adesione e dai protocolli EntitlementDelegate e EntitlementStatus che descrivono i callback attivati dalla libreria. L’interfaccia e il protocollo sono denominati con un nome comune: libreria AccessEnabler.

Requisiti di iOS e tvOS reqs

Per i requisiti tecnici correnti relativi alla piattaforma iOS e tvOS e all'autenticazione di Adobe Pass, consulta Requisiti per piattaforma/dispositivo/strumento e le note sulla versione incluse nel download di SDK. Nel resto di questa pagina, sono disponibili sezioni in cui si notano le modifiche che si applicano a particolari versioni di SDK e successive. Ad esempio, la seguente è una nota legittima relativa alla versione 1.7.5 di SDK:

Flussi di lavoro dei client nativi flows

I flussi di lavoro dei client nativi sono in genere identici o molto simili a quelli dei client di autenticazione Adobe Pass basati su browser. Tuttavia, esistono alcune eccezioni, come descritto di seguito.

Flusso di lavoro di post-inizializzazione
Flusso di lavoro di autenticazione iniziale generico
Flusso di lavoro disconnessione

Flusso di lavoro di post-inizializzazione post-init

Tutti i flussi di lavoro relativi ai diritti supportati da AccessEnabler presuppongono che in precedenza sia stato chiamato setRequestor() per stabilire l'identità. Effettua questa chiamata per fornire l'ID richiedente una sola volta, in genere durante la fase di inizializzazione/configurazione dell'applicazione.

Con un client nativo di iOS, dopo la chiamata iniziale a setRequestor(), puoi scegliere come procedere:

Puoi iniziare a effettuare immediatamente le chiamate di adesione e, se necessario, metterle in coda in modo invisibile all’utente.
È possibile ricevere una conferma dell'esito positivo/negativo di setRequestor() implementando il callback setRequestorComplete().
Puoi eseguire entrambe le operazioni descritte sopra.

È possibile scegliere di fare in modo che l'app attenda la notifica del completamento di setRequestor() oppure di fare affidamento sul meccanismo di coda delle chiamate di AccessEnabler. Poiché tutte le richieste di autorizzazione e autenticazione successive richiedono l'ID richiedente e le informazioni di configurazione associate, il metodo setRequestor() blocca in modo efficace tutte le chiamate API di autenticazione e autorizzazione fino al completamento dell'inizializzazione.

Flusso di lavoro di autenticazione iniziale generico generic

Lo scopo di questo flusso di lavoro è quello di accedere a un utente con il suo MVPD. Dopo aver eseguito correttamente l’accesso, il server backend invia all’utente un token di autenticazione. Sebbene l’autenticazione venga in genere eseguita come parte del processo di autorizzazione, quanto segue descrive come può funzionare in isolamento e non include alcun passaggio di autorizzazione.

Questo flusso di lavoro differisce per i client nativi dal flusso di lavoro tipico di autenticazione basato su browser, ma i passaggi da 1 a 5 sono gli stessi sia per i client nativi che per i client basati su browser.

L'applicazione avvia il flusso di lavoro di autenticazione con una chiamata al metodo API getAuthentication() di AccessEnabler, che verifica la presenza di un token di autenticazione nella cache valido.
Se l'utente è attualmente autenticato, AccessEnabler chiama la funzione di callback setAuthenticationStatus(), passando uno stato di autenticazione che indica l'esito positivo e terminando il flusso.
Se l'utente non è attualmente autenticato, AccessEnabler continua il flusso di autenticazione determinando se l'ultimo tentativo di autenticazione dell'utente è stato eseguito correttamente con un determinato MVPD. Se un MVPD ID è memorizzato nella cache E il flag canAuthenticate è true OPPURE è stato selezionato un MVPD utilizzando setSelectedProvider(), all'utente non viene visualizzata la finestra di dialogo di selezione di MVPD. Il flusso di autenticazione continua a utilizzare il valore memorizzato nella cache di MVPD, ovvero lo stesso MVPD utilizzato durante l’ultima autenticazione riuscita. Viene effettuata una chiamata di rete al server backend e l’utente viene reindirizzato alla pagina di accesso di MVPD (passaggio 6 di seguito).
Se non è stato selezionato alcun MVPD ID nella cache E non è stato selezionato alcun MVPD utilizzando setSelectedProvider() OPPURE se il flag canAuthenticate è impostato su false, viene chiamato il callback displayProviderDialog(). Questo callback indica all'applicazione di creare l'interfaccia utente che presenta all'utente un elenco di MVPD tra cui scegliere. Viene fornito un array di oggetti MVPD, contenente le informazioni necessarie per creare il selettore MVPD. Ogni oggetto MVPD descrive un'entità MVPD e contiene informazioni come l'ID del MVPD (ad esempio, XFINITY, AT&T, ecc.) e l'URL in cui è possibile trovare il logo MVPD.
Una volta selezionato un determinato MVPD, l'applicazione deve informare AccessEnabler della scelta dell'utente. Dopo che l'utente ha selezionato il MVPD desiderato, si informa AccessEnabler della selezione dell'utente tramite una chiamata al metodo setSelectedProvider().
IOS AccessEnabler chiama il callback navigateToUrl: o navigateToUrl:useSVC: per reindirizzare l'utente alla pagina di accesso di MVPD. Attivando una delle due, AccessEnabler invia una richiesta all'applicazione per creare un controller UIWebView/WKWebView or SFSafariViewController e caricare l'URL fornito nel parametro url del callback. Questo è l’URL dell’endpoint di autenticazione sul server back-end. Per tvOS AccessEnabler, il callback status() viene chiamato con un parametro statusDictionary e il polling per la seconda autenticazione dello schermo viene avviato immediatamente. statusDictionary contiene registration code che deve essere utilizzato per la seconda autenticazione dello schermo.
Nel caso di iOS AccessEnabler, l'utente accede alla pagina di accesso di MVPD per immettere le credenziali tramite il controller UIWebView/WKWebView or SFSafariViewController dell'applicazione. Durante il trasferimento si verificano diverse operazioni di reindirizzamento e l'applicazione deve monitorare gli URL caricati dal controller durante le operazioni di reindirizzamento multiple.
Nel caso di iOS AccessEnabler, quando il controller UIWebView/WKWebView or SFSafariViewController carica un URL personalizzato specifico, l'applicazione deve chiudere il controller e chiamare il metodo API handleExternalURL:url di AccessEnabler. Questo URL personalizzato specifico non è valido e non è destinato al controller per caricarlo effettivamente. Deve essere interpretato solo dall'applicazione come un segnale del completamento del flusso di autenticazione e della sicurezza della chiusura del controller UIWebView/WKWebView or SFSafariViewController. Nel caso in cui l'applicazione debba utilizzare un controller SFSafariViewController , l'URL personalizzato specifico è definito da application's custom scheme (esempio: adbe.u-XFXJeTSDuJiIQs0HVRAg://adobe.com), altrimenti questo URL personalizzato specifico è definito dalla costante ADOBEPASS_REDIRECT_URL (esempio: adobepass://ios.app).
Dopo che l'applicazione chiude il controller UIWebView/WKWebView or SFSafariViewController e chiama il metodo API handleExternalURL:url di AccessEnabler, AccessEnabler recupera il token di autenticazione dal server back-end e informa l'applicazione che il flusso di autenticazione è completo. AccessEnabler chiama il callback setAuthenticationStatus() con il codice di stato 1, che indica l'esito positivo. Se si verifica un errore durante l'esecuzione di questi passaggi, il callback setAuthenticationStatus() viene attivato con il codice di stato 0, che indica un errore di autenticazione, nonché un codice di errore corrispondente.

WARNING

Durante i passaggi in cui AccessEnabler cede il controllo all'app, ad esempio quando viene visualizzata la finestra di dialogo di selezione del provider o quando viene visualizzato UIWebView/WKWebView o SFSafariViewController, l'utente ha l'opportunità di annullare il flusso di autenticazione. In queste situazioni, l'app è responsabile dell'informazione di AccessEnabler su questo evento e della chiamata al metodo API setSelectedProvider(), passando null come parametro. In questo modo AccessEnabler può ripulire il proprio stato interno e ripristinare il flusso di autenticazione. Su tvOS, puoi utilizzare lo stesso metodo per annullare il polling di autenticazione.

Flusso di lavoro disconnessione logout

Per i client nativi, la disconnessione viene gestita in modo simile al processo di autenticazione descritto in precedenza.

L'applicazione avvia il flusso di lavoro di disconnessione con una chiamata al metodo API logout() di AccessEnabler. La disconnessione è il risultato di una serie di operazioni di reindirizzamento HTTP dovute al fatto che l’utente deve essere disconnesso sia dai server di autenticazione di Adobe Pass che dai server di MVPD. Poiché non è possibile completare il flusso con una semplice richiesta HTTP emessa dalla libreria AccessEnabler, è necessario creare un'istanza di un controller UIWebView/WKWebView or SFSafariViewController per poter seguire le operazioni di reindirizzamento HTTP.
Viene utilizzato un modello simile al flusso di autenticazione. IOS AccessEnabler attiva il callback navigateToUrl: o navigateToUrl:useSVC: per creare un controller UIWebView/WKWebView or SFSafariViewController e caricare l'URL fornito nel parametro url del callback. Questo è l'URL dell'endpoint di disconnessione sul server back-end. Per tvOS AccessEnabler non viene chiamato né il callback navigateToUrl: né quello navigateToUrl:useSVC:.
Durante l'esecuzione di diversi reindirizzamenti, l'applicazione deve monitorare l'attività del controller UIWebView/WKWebView or SFSafariViewController e rilevare il momento in cui carica un URL personalizzato specifico. Questo URL personalizzato specifico non è valido e non è destinato al controller per caricarlo effettivamente. Deve essere interpretato solo dall'applicazione come un segnale che il flusso di logout è stato completato e che è sicuro chiudere il controller. Quando il controller carica questo URL personalizzato specifico, l'applicazione deve chiudere il controller e chiamare il metodo API handleExternalURL:url di AccessEnabler. Nel caso in cui l'applicazione debba utilizzare un controller SFSafariViewController , l'URL personalizzato specifico è definito da application's custom scheme (esempio: adbe.u-XFXJeTSDuJiIQs0HVRAg://adobe.com), altrimenti questo URL personalizzato specifico è definito dalla costante ADOBEPASS_REDIRECT_URL (esempio: adobepass://ios.app).
Alla fine AccessEnabler chiamerà il callback setAuthenticationStatus() con il codice di stato 0, che indica il completamento del flusso di logout.

Il flusso di disconnessione è diverso dal flusso di autenticazione in quanto l'utente non è tenuto a interagire in alcun modo con il controller UIWebView/WKWebView or SFSafariViewController. Pertanto, Adobe consiglia di rendere il controllo invisibile (ovvero nascosto) durante la procedura di disconnessione.

Token tokens

Definizioni e utilizzo
Linee guida per la memorizzazione in cache
Persistenza
Formato
Binding dispositivo

Definizioni e utilizzo definitions

La soluzione di adesione all’autenticazione di Adobe Pass ruota attorno alla generazione di parti specifiche di dati (token) generati dall’autenticazione di Adobe Pass dopo il completamento corretto dei flussi di lavoro di autenticazione e autorizzazione. Questi token vengono memorizzati localmente sul dispositivo iOS del client.

I token hanno una durata limitata; alla scadenza, i token devono essere riemessi tramite la riattivazione dei flussi di lavoro di autenticazione e/o autorizzazione.

Esistono tre tipi di token rilasciati durante i flussi di lavoro di adesione:

Token di autenticazione: Il risultato finale del flusso di lavoro di autenticazione utente sarà un GUID di autenticazione che AccessEnabler può utilizzare per eseguire query di autorizzazione per conto dell'utente. A questo GUID di autenticazione verrà associato un valore TTL (time-to-live) che potrebbe essere diverso dalla sessione di autenticazione dell'utente. Verrà generato un token di autenticazione associando il GUID di autenticazione alla periferica che avvia le richieste di autenticazione.
Token di autorizzazione: consente l'accesso a una risorsa protetta specifica identificata da un resourceID univoco. È costituito da una sovvenzione di autorizzazione rilasciata dalla parte autorizzatrice insieme all’ID risorsa originale. Queste informazioni sono associate al dispositivo che avvia la richiesta.
Token multimediale di breve durata: AccessEnabler concede l'accesso all'applicazione di hosting per una determinata risorsa restituendo un token multimediale di breve durata. Questo token viene generato in base al token di autorizzazione ottenuto in precedenza per quella specifica risorsa. Inoltre, questo token non è associato al dispositivo e la durata associata è significativamente più breve (impostazione predefinita: 5 minuti).

In caso di autenticazione e autorizzazione corrette, l’autenticazione Adobe Pass rilascia l’autenticazione, l’autorizzazione e i token multimediali di breve durata. Questi token devono essere memorizzati nella cache del dispositivo dell’utente e utilizzati per la durata della vita associata.

Linee guida per la memorizzazione in cache caching

Token di autenticazione
Token di autorizzazione
Token multimediale di breve durata

Token di autenticazione

AccessEnabler 1.7: Questo SDK introduce un nuovo metodo di archiviazione dei token, che abilita più bucket Programmer-MVPD e, di conseguenza, più token di autenticazione. Ora viene utilizzato lo stesso layout di archiviazione sia per lo scenario "Autenticazione per richiedente" che per il normale flusso di autenticazione. L'unica differenza tra le due è nel modo in cui viene eseguita l'autenticazione: "Autenticazione per richiedente" contiene un nuovo miglioramento (Autenticazione passiva) che consente ad AccessEnabler di eseguire l'autenticazione back-channel, in base all'esistenza di un token di autenticazione nell'archiviazione (per un programmatore diverso). L'utente deve eseguire l'autenticazione una sola volta e questa sessione verrà utilizzata per ottenere i token di autenticazione in app aggiuntive. Questo flusso back-channel si verifica durante la chiamata setRequestor() ed è per lo più trasparente per il programmatore. Esiste tuttavia un requisito importante: il programmatore DEVE chiamare setRequestor() dal thread dell'interfaccia utente principale.
AccessEnabler 1.6 e versioni precedenti: Il modo in cui i token di autenticazione vengono memorizzati nella cache del dispositivo dipende dal flag "Authentication per Requestor" associato al MVPD corrente:

Se la funzione "Autenticazione per richiedente" è disabilitata, nel tavolo di montaggio globale verrà memorizzato localmente un singolo token di autenticazione, che verrà condiviso tra tutte le applicazioni integrate con il MVPD corrente.
Se la funzione "Autenticazione per richiedente" è abilitata, al programmatore che ha eseguito il flusso di autenticazione verrà associato in modo esplicito un token (il token non verrà memorizzato nel tavolo di montaggio globale, ma in un file privato visibile solo all'applicazione del programmatore). In particolare, il Single Sign-On (SSO) tra diverse applicazioni verrà disattivato; l’utente dovrà eseguire esplicitamente il flusso di autenticazione al passaggio a una nuova app (a condizione che il programmatore della seconda app sia integrato con l’attuale MVPD e che non esista alcun token di autenticazione per tale programmatore nella cache locale).

Token di autorizzazione

In qualsiasi momento viene memorizzato nella cache da AccessEnabler UN solo token di autorizzazione PER RISORSA. Possono essere memorizzati nella cache più token di autorizzazione, ma sono associati a risorse diverse. Ogni volta che viene rilasciato un nuovo token di autorizzazione e ne esiste già uno precedente per la stessa risorsa, il nuovo token sovrascrive il valore memorizzato nella cache esistente.

Token multimediale

Il token multimediale di breve durata NON deve essere memorizzato nella cache. Il token multimediale deve essere recuperato dal server ogni volta che viene chiamata un’API di autorizzazione, perché è limitato all’uso una tantum.

Persistenza persistence

I token devono essere persistenti su esecuzioni consecutive della stessa applicazione. Ciò significa che una volta acquisiti i token di autenticazione e autorizzazione e che l’utente chiude l’applicazione, gli stessi token sono disponibili per l’applicazione quando l’utente riapre l’applicazione. Inoltre, è auspicabile che tali token siano persistenti in più applicazioni. In altre parole, dopo che un utente utilizza un’applicazione per accedere con un provider di identità specifico (ottenendo con successo i token di autenticazione e autorizzazione), gli stessi token possono essere utilizzati tramite un’applicazione diversa e all’utente non vengono più richieste le credenziali quando esegue l’accesso tramite lo stesso provider di identità. Questo tipo di flusso di lavoro di autenticazione/autorizzazione senza soluzione di continuità è ciò che rende la soluzione di autenticazione Adobe Pass una vera TV-Everywhere
implementazione.

iOS

La libreria iOS AccessEnabler risolve i problemi di condivisione dei dati tra più applicazioni memorizzando i dati del token in una struttura di dati "simile agli Appunti" denominata incolla bacheca. Questa risorsa condivisa a livello di sistema fornisce gli ingredienti chiave che consentono l’implementazione del caso di utilizzo dei token persistenti desiderati:

Supporto per l'archiviazione strutturata - La scheda Incolla non è solo una struttura di memoria semplice e lineare simile a un buffer. Fornisce un meccanismo di archiviazione simile al dizionario che consente l’indicizzazione dei dati in base a valori chiave specificati dall’utente.
Supporto per la persistenza dei dati utilizzando il file system sottostante. Il contenuto della struttura della scheda Incolla può essere contrassegnato come persistente. In tal caso i dati vengono salvati nella memoria interna del dispositivo.

Una volta inserito un token specifico nella cache dei token, la sua validità verrà verificata in momenti diversi dalla libreria AccessEnabler. Un token valido è definito come:

Il TTL del token non è scaduto.
L’autorità di certificazione del token è inclusa nell’elenco dei provider di identità consentiti.

tvOS

Poiché su tvOS il tavolo di montaggio non è disponibile, la libreria AccessEnabler di tvOS utilizza NsUserDefaults come opzione di archiviazione. In questo modo è possibile risolvere il problema dei token di autenticazione e autorizzazione persistenti, ma le informazioni archiviate non possono essere condivise tra applicazioni diverse.

Modifiche al tavolo di montaggio di iOS 10 - Quando si esegue l'aggiornamento da una versione precedente di iOS, il tavolo di montaggio verrà cancellato. Ciò significa che tutte le applicazioni devono essere autenticate nuovamente.

Modifiche al tavolo di montaggio di iOS 7 - A causa di modifiche nel funzionamento dei pannelli di montaggio in iOS 7, l'SSO incrociato tra le applicazioni in esecuzione in iOS 7 sarà limitato. Le applicazioni che hanno lo stesso <Bundle Seed ID> (noto anche come <Team ID>) condivideranno i token, il che significa che le app A1 e A2 dello stesso Programmatore X condivideranno i token, mentre le app A1 (Programmatore X) e A3 (Programmatore Y) non condivideranno i token.

L’ID di seed bundle/ID team è lo stesso tra 2 app, se queste sono generate dallo stesso profilo di provisioning. Per ulteriori informazioni, consulta questo collegamento:
http://developer.apple.com/library/ios/#documentation/general/conceptual/DevPedia-CocoaCore/AppID.html
Questa limitazione "Cross SSO" sarà presente in iOS 7 indipendentemente dal SDK di autenticazione di Adobe Pass utilizzato.

Leggere questa nota tecnica per ulteriori informazioni sulla configurazione di SSO in iOS 7 e versione superiore (la nota tecnica si applica per Access Enabler v1.8 e versione successiva): https://tve.zendesk.com/entries/58233434-Configuring-Pay-TV-pass-SSO-on-iOS

Archiviazione token (AccessEnabler 1.7)

A partire da AccessEnabler 1.7, l'archiviazione dei token può supportare più combinazioni Programmatore-MVPD, basandosi su una struttura di mappe nidificate a più livelli in grado di contenere più token di autenticazione. Questa nuova archiviazione non influisce in alcun modo sull'API pubblica di AccessEnabler e non richiede modifiche da parte del programmatore. Ecco un esempio che
illustra questa nuova funzionalità:

Apri App1 (sviluppato da Programmer1).
Autentica con MVPD1 (integrato con Programmer1).
Sospendi/Chiudi l’applicazione corrente e apri App2 (sviluppata da Programmer2).
Supponiamo che Programmer2 non sia integrato con MVPD2; pertanto, l’utente NON sarà autenticato in App2.
Autentica con MVPD2 (integrato con Programmer2) in App2.
Torna all’app1; l’utente sarà ancora autenticato con Programmer1.

Nelle versioni precedenti di AccessEnabler, nel passaggio 6 l'utente non viene autenticato perché in precedenza l'archiviazione dei token supportava un solo token di autenticazione.

La disconnessione da una sessione Programmer/MVPD cancellerà l'intero storage sottostante, inclusi tutti gli altri token di autenticazione Programmer/MVPD sul dispositivo. D'altra parte, l'annullamento del flusso di autenticazione (richiamando setSelectedProvider(null)) NON cancellerà l'archiviazione sottostante, ma influirà solo sul tentativo di autenticazione corrente di Programmatore/MVPD (cancellando il MVPD per il Programmatore corrente).

Importazione token (AccessEnabler 1.7)

Un'altra funzionalità relativa allo storage inclusa in AccessEnabler 1.7 consente di importare token di autenticazione da aree di storage meno recenti. Questo "Token Importer" aiuta a ottenere la compatibilità tra versioni consecutive di AccessEnabler, mantenendo lo stato SSO anche quando la versione di archiviazione viene aggiornata. L'importazione viene eseguita durante il flusso setRequestor() e si verifica nei due scenari seguenti (supponendo che nell'archiviazione corrente non sia presente alcun token di autenticazione valido per il programmatore corrente):

La prima installazione di un'app 1.7 sviluppata da un programmatore specifico
Percorso di aggiornamento a un AccessEnabler futuro che utilizza un nuovo storage

L'operazione di importazione è trasparente per il programmatore e non richiede alcuna modifica del codice nell'applicazione client.

Sanitizzatore token (AccessEnabler 1.7.5)

Da AccessEnabler 1.7.5 in avanti, questo servizio viene eseguito su setRequestor(). È stato sviluppato in seguito al passaggio di iOS 7 dall'indirizzo MAC WiFi all'IDFA per il tracciamento. Lo strumento di pulizia assicura che l’archiviazione corrente contenga solo token di autenticazione validi (validi in termini di ID dispositivo, precedentemente calcolati utilizzando l’indirizzo MAC, prima di iOS7). Token Sanitizer rimuove tutti i token non validi.

Il servizio Token Sanitizer è più utile quando si utilizza un’applicazione AccessEnabler 1.7.5 in iOS 6 e successivamente l’utente si aggiorna a iOS 7. In questo caso, tutti i token di autenticazione ottenuti su iOS 6 non saranno più validi (a causa del passaggio dell’algoritmo Device ID dall’utilizzo dell’indirizzo MAC all’IDFA). Lo strumento di pulizia eliminerà tutti i token non validi e l’utente verrà quindi non autenticato.

Se Token Sanitizer non rimuove i token non validi, AccessEnabler non riuscirà a ottenere le autorizzazioni a causa della presenza di token di autenticazione non validi. Questo potrebbe rivelarsi difficile da eseguire per l’utente finale, in quanto i messaggi di errore di autorizzazione possono essere criptici e non eccessivamente utili per determinare la causa del problema.

Tieni presente che il formato dei token AuthN e AuthZ è incluso qui solo per informazioni di base. La struttura di questi token può essere modificata dall’autenticazione di Adobe Pass in qualsiasi momento. I programmatori non devono conoscere la struttura esatta dei token AuthN e AuthZ per implementare le loro app, in quanto i token AuthN e AuthZ non sono esposti sul dispositivo locale. Il token per contenuti multimediali brevi è esposto all'applicazione del programmatore.

Token di autenticazione authn_token

L’elenco seguente presenta il formato del token di autenticazione:

  <signatureInfo>base64(...)<signatureInfo>
  <simpleAuthenticationToken>
      <simpleTokenAuthenticationGuid>71C69B91-F327-F185-F29E-2CE20DC560F5</simpleTokenAuthenticationGuid>
      <simpleTokenRequestorID>TEST_REQUESTOR</simpleTokenRequestorID>
      <simpleTokenDomainName>adobe.com</simpleTokenDomainName>
      <simpleTokenExpires>2011/03/19 02:29:34 GMT +0200</simpleTokenExpires>
      <simpleTokenMsoID>Adobe</simpleTokenMsoID>
      <simpleTokenDeviceID>
          <simpleTokenFingerprint>
              HASH(true device identification info)
          </simpleTokenFingerprint>
      </simpleTokenDeviceID>
  </simpleAuthenticationToken>

Token di autorizzazione authz_token

L’elenco seguente presenta il formato del token di autorizzazione:

  <signatureInfo>base64(...)<signatureInfo>
  <simpleAuthorizationToken>
      <simpleTokenRequestorID>TEST_REQUESTOR</simpleTokenRequestorID>
      <simpleTokenResourceID>TEST_RESOURCE</simpleTokenResourceID>
      <simpleTokenTTL>2011/03/17 14:40:08 GMT +0200</simpleTokenTTL>
      <simpleTokenMsoID>Adobe</simpleTokenMsoID>
      <simpleTokenDeviceID>
          <simpleTokenFingerprint>
              HASH(true device identification info)
          </simpleTokenFingerprint>
      </simpleTokenDeviceID>
  </simpleAuthorizationToken>

Token file multimediali brevi short_token

L’elenco seguente presenta il formato del token multimediale breve. Questo token viene esposto nell’applicazione del programmatore. Viene inviato all’applicazione del programmatore al termine di un processo di adesione riuscito:

  <signatureInfo>signature<signatureInfo>
  <shortAuthorizationToken>
    <sessionGUID>session_guid</sessionGUID>
    <requestorID>requestor_id</requestorID>
    <resourceID>resource_id</resourceID>
    <ttl>ttl_in_ms</ttl>
    <issueTime>issue_time</issueTime>
    <mvpdId>mvpd_id</mvpdId>
    <proxyMvpdId>proxy_mvpd_id</proxyMvpdId>
  </shortAuthorizationToken>

Binding dispositivo device_binding

Negli elenchi XML riportati sopra, prendere nota del tag con titolo simpleTokenFingerprint. Lo scopo di questo tag è quello di contenere le informazioni di personalizzazione degli ID dispositivo nativi. La libreria AccessEnabler è in grado di ottenere tali informazioni di personalizzazione e di renderle disponibili ai servizi di autenticazione di Adobe Pass durante le chiamate di adesione. Il servizio utilizzerà queste informazioni e le incorporerà nei token effettivi, associando quindi in modo efficace i token a un dispositivo specifico. L’obiettivo finale è quello di rendere i token non trasferibili tra i dispositivi.

Poiché si tratta ovviamente di una funzione correlata alla sicurezza, queste informazioni sono intrinsecamente "sensibili" dal punto di vista della sicurezza. Di conseguenza, queste informazioni devono essere protette sia dalle manomissioni che dalle intercettazioni. Il problema dell’intercettazione viene risolto inviando le richieste di autenticazione/autorizzazione tramite il protocollo HTTPS. La protezione contro le manomissioni viene gestita firmando digitalmente le informazioni di identificazione del dispositivo. La libreria AccessEnabler calcola un ID dispositivo in base alle informazioni fornite dal dispositivo, quindi invia l’ID dispositivo "in chiaro" ai server di autenticazione di Adobe Pass come parametro della richiesta. I server di autenticazione di Adobe Pass firmano digitalmente l’ID dispositivo con la chiave privata di Adobe e lo aggiungono al token di autenticazione restituito ad AccessEnabler. Pertanto, l’ID dispositivo è associato al token di autenticazione. Durante il flusso di autorizzazione, AccessEnabler invia nuovamente l'ID dispositivo in chiaro, insieme al token di autenticazione. Il fallimento del processo di convalida causerà automaticamente il fallimento dei flussi di lavoro di autenticazione/autorizzazione. I server di autenticazione di Adobe Pass applicano la chiave privata all’ID del dispositivo e la confrontano con il valore nel token di autenticazione. Se non corrispondono, il flusso di adesione non riesce.

Nota sull'associazione dei dispositivi in AccessEnabler 1.7.5: A partire da AccessEnabler 1.7.5, viene modificata la modalità di calcolo dell'ID dispositivo per fornire informazioni di personalizzazione per un dispositivo iOS. Questa modifica riflette un cambiamento in iOS 7: da iOS 7, Apple non fornisce più l'indirizzo MAC WiFi come opzione di tracciamento, a favore del suo identificatore per gli inserzionisti (IDFA). Poiché le informazioni di personalizzazione per un’app in esecuzione su iOS 7 si basano sull’identificatore IDFA e sono incorporate nei token del flusso di adesione, ciò significa che questa modifica può avere diversi effetti sull’esperienza utente. I diversi effetti possibili si basano sulla versione di iOS da cui l’utente esegue l’aggiornamento e sulla versione di AccessEnabler da cui il programmatore esegue l’aggiornamento. Per informazioni dettagliate su questa modifica, consulta le note sulla versione incluse in AccessEnabler SDK 1.7.5.

recommendation-more-help

3f5e655c-af63-48cc-9769-2b6803cc5f4b