Manuale di Android SDK (legacy)
- Argomenti:
- Autenticazione
Introduzione
Questo documento descrive i flussi di lavoro per l'adesione che l'applicazione di livello superiore di un programmatore può implementare tramite le API esposte dalla libreria Android AccessEnabler.
La soluzione di autenticazione Adobe Pass per Android è infine suddivisa in due domini:
-
Dominio dell’interfaccia utente: livello applicativo superiore che implementa l’interfaccia utente e utilizza i servizi forniti dalla libreria AccessEnabler per fornire accesso a contenuti con restrizioni.
-
Dominio AccessEnabler: qui vengono implementati i flussi di lavoro per l’adesione sotto forma di:
- Chiamate di rete effettuate ai server back-end di Adobe
- Regole della logica di business relative ai flussi di lavoro di autenticazione e autorizzazione
- Gestione di varie risorse ed elaborazione dello stato del flusso di lavoro (ad esempio la cache dei token)
L'obiettivo del dominio AccessEnabler è nascondere tutte le complessità dei flussi di lavoro di adesione e fornire all'applicazione di livello superiore (tramite la libreria AccessEnabler) un set di semplici primitive di adesione con cui implementare i flussi di lavoro di adesione:
-
Imposta l'identità del richiedente.
-
Verifica e ottieni l’autenticazione per un determinato provider di identità.
-
Controlla e ottieni l’autorizzazione per una particolare risorsa.
-
Disconnetti.
L'attività di rete di AccessEnabler si svolge in un thread diverso, pertanto il thread dell'interfaccia utente non viene mai bloccato. Di conseguenza, il canale di comunicazione bidirezionale tra i due domini dell’applicazione deve seguire un modello completamente asincrono:
- Il livello applicazione dell’interfaccia utente invia messaggi al dominio AccessEnabler tramite le chiamate API esposte dalla libreria AccessEnabler.
- AccessEnabler risponde al livello dell'interfaccia utente tramite i metodi di callback inclusi nel protocollo AccessEnabler che il livello dell'interfaccia utente registra con la libreria AccessEnabler.
Flussi di diritti
A. Prerequisiti
-
Creare le funzioni di callback:
-
Attivato da
setRequestor()
, restituisce esito positivo o negativo.
Il successo indica che puoi procedere con le chiamate di adesione. -
Attivato da
getAuthentication()
solo se l'utente non ha selezionato un provider (MVPD) e non è ancora autenticato.
Il parametromvpds
è un array di provider disponibili per l'utente. -
"setAuthenticationStatus(status, errorcode)"
Attivato da
checkAuthentication()
ogni volta.
Attivato dagetAuthentication()
solo se l'utente è già autenticato e ha selezionato un provider.Lo stato restituito è success o failure, il codice di errore descrive il tipo di errore.
-
Attivazione eseguita da
getAuthentication()
dopo la selezione di un MVPD da parte dell'utente. Il parametrourl
fornisce il percorso della pagina di accesso di MVPD. -
Attivato da
checkAuthentication(), getAuthentication(), checkAuthorization(), getAuthorization(), setSelectedProvider()
.
Il parametroevent
indica quale evento di adesione si è verificato; il parametrodata
è un elenco di valori relativi all'evento. -
Attivazione eseguita da
checkAuthorization()
egetAuthorization()
dopo un'autorizzazione di visualizzazione di una risorsa completata.
Il parametrotoken
è il token multimediale di breve durata. Il parametroresource
è il contenuto che l'utente è autorizzato a visualizzare. -
"tokenRequestFailed(resource, code, description)"
Attivato da
checkAuthorization()
egetAuthorization()
dopo un'autorizzazione non riuscita.
Il parametroresource
è il contenuto che l'utente stava tentando di visualizzare. Il parametrocode
è il codice di errore che indica il tipo di errore che si è verificato. Il parametrodescription
descrive l'errore associato al codice di errore. -
Attivato da
getSelectedProvider()
.
Il parametromvpd
fornisce informazioni sul provider selezionato dall'utente. -
"setMetadataStatus(metadata, key, arguments)"
Attivato da
getMetadata().
Il parametrometadata
fornisce i dati specifici richiesti; il parametrokey
è la chiave utilizzata nella richiestagetMetadata()
e il parametroarguments
è lo stesso dizionario passato agetMetadata()
. -
"preauthorizedResources(resources)"
Attivato da
checkPreauthorizedResources()
.
Il parametroauthorizedResources
presenta le risorse che l'utente è autorizzato a visualizzare.
-
B. Flusso di avvio
-
Avvia l'applicazione di livello superiore.
-
Avvia autenticazione Adobe Pass
a. Chiamare
getInstance
per creare una singola istanza di Adobe Pass Authentication AccessEnabler.- Dipendenza: Autenticazione Adobe Pass Nativa
Libreria Android (AccessEnabler)
b. Chiamare
setRequestor()
per stabilire l'identità del programmatore; passarerequestorID
del programmatore e (facoltativamente) un array di endpoint di autenticazione Adobe Pass.-
Dipendenza: ID richiedente autenticazione Adobe Pass valido
Per risolvere il problema, rivolgiti al tuo Adobe Pass Authentication Account Manager. -
Trigger: callback setRequestorComplete()
NOTANon è possibile completare alcuna richiesta di adesione finché non viene stabilita l'identità completa del richiedente. Ciò significa che mentre setRequestor() è ancora in esecuzione, tutte le richieste di adesione successive (ad esempio,checkAuthentication()
) sono bloccate.
Sono disponibili due opzioni di implementazione: una volta inviate le informazioni di identificazione del richiedente al server back-end, il livello dell'applicazione dell'interfaccia utente può scegliere uno dei due approcci seguenti:
1. Attendere l'attivazione del callbacksetRequestorComplete()
(parte del delegato AccessEnabler). Questa opzione fornisce la massima certezza chesetRequestor()
è stato completato, quindi è consigliata per la maggior parte delle implementazioni.
2. Continuare senza attendere l'attivazione del callbacksetRequestorComplete()
e iniziare a emettere richieste di adesione. Queste chiamate (checkAuthentication, checkAuthorization, getAuthentication, getAuthorization, checkPreauthorizedResource, getMetadata, logout) sono in coda dalla libreria AccessEnabler, che effettuerà le chiamate di rete effettive doposetRequestor().
Questa opzione può essere interrotta occasionalmente se, ad esempio, la connessione di rete è instabile. - Dipendenza: Autenticazione Adobe Pass Nativa
-
Chiamare checkAuthentication() per verificare la presenza di un'autenticazione esistente senza avviare il flusso di autenticazione completo. Se la chiamata ha esito positivo, puoi passare direttamente al flusso di autorizzazione. In caso contrario, passare al flusso di autenticazione.
-
Dipendenza: Chiamata riuscita a
setRequestor()
(questa dipendenza si applica anche a tutte le chiamate successive). -
Trigger: callback setAuthenticationStatus()
-
C. Flusso di autenticazione
-
Chiamare
getAuthentication()
per avviare il flusso di autenticazione o per ottenere la conferma che l'utente è già autenticato.
Trigger:- Il callback setAuthenticationStatus(), se l'utente è già autenticato. In questo caso, passare direttamente al Flusso di autorizzazione.
- Il callback displayProviderDialog(), se l'utente non è ancora autenticato.
-
Presentare all'utente l'elenco dei provider inviati a
displayProviderDialog()
. -
Dopo che l'utente ha selezionato un provider, ottenere l'URL del MVPD dell'utente dal callback
navigateToUrl()
. Aprire un controllo WebView e indirizzarlo all'URL. -
Tramite il WebView creato nel passaggio precedente, l'utente accede alla pagina di accesso di MVPD e immette le credenziali di accesso. Diverse operazioni di reindirizzamento si verificano all'interno di WebView.
Nota: A questo punto, l'utente ha la possibilità di annullare il flusso di autenticazione. In questo caso, il livello dell'interfaccia utente è responsabile dell'informazione di AccessEnabler su questo evento chiamando
setSelectedProvider()
connull
come parametro. Ciò consente ad AccessEnabler di ripulire il proprio stato interno e reimpostare il flusso di autenticazione. -
Dopo che l'utente ha effettuato l'accesso, il livello dell'applicazione rileva il caricamento di un "URL di reindirizzamento personalizzato" (ovvero
http://adobepass.android.app
). Questo URL personalizzato è in realtà un URL non valido che non deve essere caricato da WebView. È un segnale che indica che il flusso di autenticazione è stato completato e che WebView deve essere chiuso. -
Chiudere il controllo WebView e chiamare
getAuthenticationToken()
, che indica ad AccessEnabler di recuperare il token di autenticazione dal server back-end. -
[Facoltativo] Chiamare
checkPreauthorizedResources(resources)
per verificare quali risorse l'utente è autorizzato a visualizzare. Il parametroresources
è un array di risorse protette associate al token di autenticazione dell'utente.
Trigger:preAuthorizedResources()
callback
Punto di esecuzione: dopo il completamento del flusso di autenticazione -
Se l’autenticazione ha esito positivo, procedi al flusso di autorizzazione.
D. Flusso di autorizzazione
-
Chiama getAuthorization() per avviare l'autorizzazione
flusso.Dipendenza: ID risorsa validi concordati con i MVPD.
Nota: i ResourceID devono essere gli stessi utilizzati su qualsiasi altro dispositivo o piattaforma e saranno gli stessi in tutti gli MVPD.
-
Convalida autenticazione e autorizzazione.
-
Se la chiamata
getAuthorization()
ha esito positivo: l'utente dispone di token AuthN e AuthZ validi (l'utente è autenticato e autorizzato a guardare il contenuto multimediale richiesto). -
Se
getAuthorization()
ha esito negativo: esaminare l'eccezione generata per determinarne il tipo (AuthN, AuthZ o altro):- In caso di errore di autenticazione (AuthN), riavvia il flusso di autenticazione.
- Se si trattava di un errore di autorizzazione (AuthZ), l’utente non è autorizzato a guardare il contenuto multimediale richiesto e deve visualizzare all’utente un qualche tipo di messaggio di errore.
- Se si è verificato un altro tipo di errore (errore di connessione, errore di rete, ecc.), visualizza un messaggio di errore appropriato.
-
-
Convalida il token multimediale breve.
Utilizza la libreria Adobe Pass Authentication Media Token Verifier per verificare il token multimediale di breve durata restituito dalla chiamatagetAuthorization()
precedente:- Se la convalida ha esito positivo: riproduci il file multimediale richiesto per l’utente.
- Se la convalida non riesce: il token AuthZ non è valido, la richiesta di supporto deve essere rifiutata e l’utente deve visualizzare un messaggio di errore.
-
Tornare al normale flusso dell'applicazione.
E. Visualizza flusso multimediale
- L’utente seleziona il file multimediale da visualizzare.
- Il supporto è protetto? L'applicazione verifica se il supporto selezionato è protetto:
- Se il supporto selezionato è protetto, l'applicazione avvia il flusso di autorizzazione.
- Se il supporto selezionato non è protetto, riprodurlo per l'utente.
F. Flusso di disconnessione
-
Chiamare
logout()
per disconnettersi.
AccessEnabler cancella tutti i valori e i token memorizzati nella cache per il MVPD corrente per il richiedente corrente e anche per i richiedenti con Single Sign-On. Dopo aver cancellato la cache, AccessEnabler effettua una chiamata al server per pulire le sessioni lato server. Poiché la chiamata al server potrebbe causare un reindirizzamento SAML all’IdP (consentendo la pulizia della sessione sul lato IdP), questa chiamata deve seguire tutti i reindirizzamenti. Per questo motivo, è necessario gestire questa chiamata all'interno di un controllo WebView.a. Seguendo lo stesso modello del flusso di lavoro di autenticazione, il dominio AccessEnabler invia una richiesta al livello applicazione dell'interfaccia utente (tramite il callback
navigateToUrl()
) per creare un controllo WebView e istruire tale controllo a caricare l'URL dell'endpoint di disconnessione sul server back-end.b. Di nuovo, l'interfaccia utente deve monitorare l'attività del controllo WebView e rilevare il momento in cui il controllo, durante diversi reindirizzamenti, carica l'URL personalizzato dell'applicazione (ovvero
http://adobepass.android.app/
). Una volta eseguito questo evento, il livello dell'applicazione dell'interfaccia utente chiude WebView e il processo di disconnessione viene completato.Nota: il flusso di disconnessione è diverso dal flusso di autenticazione in quanto l'utente non è tenuto a interagire in alcun modo con WebView. Il livello dell’applicazione UI utilizza una visualizzazione web per assicurarsi che tutti i reindirizzamenti siano seguiti. È quindi possibile (e consigliato) rendere il controllo WebView invisibile (ovvero nascosto) durante il processo di logout.
Flussi di utenti per l’accesso con più MVPD e disconnessione
Qui hai un documento che descrive il comportamento quando utilizzi più MVPD e cosa accade quando l'utente si disconnette da un'applicazione.
Il comportamento descritto è disponibile quando si utilizza Android SDK versione >= 2.0.0.