(Legacy) Android SDK-Cookbook android-sdk-cookbook
Einführung intro
In diesem Dokument werden die Berechtigungs-Workflows beschrieben, die ein Programm der höheren Ebene eines Programmierers über die APIs implementieren kann, die von der Android AccessEnabler-Bibliothek bereitgestellt werden.
Die Lösung für die Berechtigung zur Adobe Pass-Authentifizierung für Android ist letztendlich in zwei Domains unterteilt:
-
Die Domain der Benutzeroberfläche : Dies ist die Anwendungsebene der oberen Ebene, die die Benutzeroberfläche implementiert und die von der AccessEnabler-Bibliothek bereitgestellten Services verwendet, um Zugriff auf eingeschränkte Inhalte zu gewähren.
-
Die AccessEnabler-Domain - hier werden die Berechtigungs-Workflows in Form von Folgendem implementiert:
- Netzwerkaufrufe an die Backend-Server von Adobe
- Geschäftslogikregeln in Bezug auf die Authentifizierungs- und Autorisierungs-Workflows
- Verwaltung verschiedener Ressourcen und Verarbeitung des Workflow-Status (z. B. des Token-Cache)
Das Ziel der AccessEnabler-Domain besteht darin, alle Komplexitäten der Berechtigungs-Workflows auszublenden und der Upper-Layer-Anwendung (über die AccessEnabler-Bibliothek) eine Reihe einfacher Berechtigungs-Primitive bereitzustellen, mit denen Sie die Berechtigungs-Workflows implementieren:
-
Legen Sie die Anfordereridentität fest.
-
Authentifizierung mit einem bestimmten Identitätsanbieter überprüfen und abrufen.
-
Überprüfen Sie und rufen Sie die Autorisierung für eine bestimmte Ressource ab.
-
Abmelden.
Die Netzwerkaktivität von AccessEnabler erfolgt in einem anderen Thread, sodass der Benutzeroberflächen-Thread nie blockiert wird. Daher muss der bidirektionale Kommunikationskanal zwischen den beiden Anwendungsdomänen einem vollständig asynchronen Muster folgen:
- Die Anwendungsebene der Benutzeroberfläche sendet Nachrichten über die API-Aufrufe, die von der AccessEnabler-Bibliothek verfügbar gemacht werden, an die AccessEnabler-Domain.
- Der AccessEnabler antwortet auf die Benutzeroberflächenebene über die im AccessEnabler-Protokoll enthaltenen Callback-Methoden, die die Benutzeroberflächenebene bei der AccessEnabler-Bibliothek registriert.
Berechtigungsflüsse entitlement
A. Voraussetzungen prereqs
-
Erstellen Sie Ihre Callback-Funktionen:
-
Wird durch
setRequestor()ausgelöst und gibt „Erfolg“ oder „Fehler“ zurück.
Der Erfolg zeigt an, dass Sie mit Berechtigungsaufrufen fortfahren können. -
Wird nur von
getAuthentication()ausgelöst, wenn der Benutzer keinen Provider (MVPD) ausgewählt hat und noch nicht authentifiziert ist.
DermvpdsParameter ist ein Array von Anbietern, die den Benutzenden zur Verfügung stehen. -
setAuthenticationStatus(status, errorCode)Wird jedes Mal von
checkAuthentication()ausgelöst.
Wird nur vongetAuthentication()ausgelöst, wenn der Benutzer bereits authentifiziert ist und einen Anbieter ausgewählt hat.Als Status wird Erfolg oder Fehler zurückgegeben. Der Fehler-Code beschreibt den Typ des Fehlers.
-
Wird durch
getAuthentication()ausgelöst, nachdem der Benutzer eine MVPD ausgewählt hat. Derurlgibt den Speicherort der Anmeldeseite von MVPD an. -
Ausgelöst durch
checkAuthentication(), getAuthentication(), checkAuthorization(), getAuthorization(), setSelectedProvider().
DereventParameter gibt an, welches Berechtigungsereignis aufgetreten ist. DerdataParameter ist eine Liste von Werten, die sich auf das Ereignis beziehen. -
Wird durch
checkAuthorization()undgetAuthorization()nach erfolgreicher Autorisierung zum Anzeigen einer Ressource ausgelöst.
Dertokenist das kurzlebige Medien-Token. Derresourceist der Inhalt, den die Benutzerin oder der Benutzer anzeigen darf. -
tokenRequestFailed(resource, code, description)Wird durch
checkAuthorization()undgetAuthorization()nach erfolgloser Autorisierung ausgelöst.
Derresourceist der Inhalt, den die Benutzerin oder der Benutzer versucht hat anzuzeigen. Dercodeist der Fehlercode, der angibt, welche Art von Fehler aufgetreten ist. DerdescriptionParameter beschreibt den Fehler, der mit dem Fehlercode verbunden ist. -
Ausgelöst durch
getSelectedProvider().
Der Parametermvpdenthält Informationen zum vom Benutzer ausgewählten Anbieter. -
setMetadataStatus(metadata, key, arguments)Ausgelöst durch
getMetadata().
Dermetadata-Parameter liefert die angeforderten spezifischen Daten, derkey-Parameter ist der in dergetMetadata()-Anfrage verwendete Schlüssel und derargumentsist dasselbe Wörterbuch, das angetMetadata()übergeben wurde. -
preauthorizedResources(resources)Ausgelöst durch
checkPreauthorizedResources().
DerauthorizedResourcesParameter stellt die Ressourcen dar, die der Benutzer anzeigen darf.
-
B. Anlauffluss startup_flow
-
Starten Sie die Anwendung auf höherer Ebene.
-
Adobe Pass-Authentifizierung initiieren
a. Rufen Sie
getInstanceauf, um eine einzelne Instanz von Adobe Pass Authentication AccessEnabler zu erstellen.- Abhängigkeit: Native Adobe Pass-Authentifizierung
Android Library (AccessEnabler)
b. Aufruf
setRequestor()um die Kennung des Programmierers zu ermitteln, dierequestorIDdes Programmierers zu übergeben und (optional) ein Array von Adobe Pass-Authentifizierungsendpunkten.-
Abhängigkeit: gültige Adobe Pass-Authentifizierungs-RequestorID
(Wenden Sie sich an Ihren Adobe Pass Authentication Account Manager, um dies zu arrangieren.) -
Trigger: setRequestorComplete()-Rückruf
table 0-row-2 1-row-2 HINWEIS Berechtigungsanfragen können erst abgeschlossen werden, wenn die Identität des Antragstellers vollständig ermittelt wurde. Dies bedeutet effektiv, dass während der Ausführung von setRequestor() alle nachfolgenden Berechtigungsanfragen (z. B. checkAuthentication()) blockiert werden.
Sie haben zwei Implementierungsoptionen: Sobald die Anfordereridentifizierungsinformationen an den Backend-Server gesendet wurden, kann die Benutzeroberflächen-Anwendungsebene einen der beiden folgenden Ansätze auswählen:
1. Warten Sie, bis dersetRequestorComplete()-Callback ausgelöst wird (Teil des AccessEnabler-Delegaten). Diese Option bietet die größte Sicherheit, dass abgeschlossensetRequestor(). Daher wird sie für die meisten Implementierungen empfohlen.
2. Fahren Sie fort, ohne auf das Auslösen dessetRequestorComplete()-Callbacks zu warten, und beginnen Sie mit der Ausgabe von Berechtigungsanfragen. Diese Aufrufe (checkAuthentication, checkAuthorization, getAuthentication, getAuthorization, checkPreauthorizedResource, getMetadata, logout) werden von der AccessEnabler-Bibliothek in die Warteschlange gestellt, die die eigentlichen Netzwerkaufrufe nach demsetRequestor().ausführt. Diese Option kann gelegentlich unterbrochen werden, wenn z. B. die Netzwerkverbindung instabil ist. - Abhängigkeit: Native Adobe Pass-Authentifizierung
-
Rufen Sie checkAuthentication() auf, um auf eine vorhandene Authentifizierung zu prüfen, ohne den vollständigen Authentifizierungsfluss zu initiieren. Wenn dieser Aufruf erfolgreich ist, können Sie direkt mit dem Autorisierungsfluss fortfahren. Andernfalls fahren Sie mit dem Authentifizierungsfluss fort.
-
Abhängigkeit: Erfolgreicher Aufruf an
setRequestor()(diese Abhängigkeit gilt auch für alle nachfolgenden Aufrufe). -
Trigger: setAuthenticationStatus()-Rückruf
-
C. Authentifizierungsfluss authn_flow
-
Rufen Sie
getAuthentication()auf, um den Authentifizierungsfluss zu initiieren oder um eine Bestätigung zu erhalten, dass der Benutzer bereits authentifiziert ist.
Trigger:- Der Rückruf setAuthenticationStatus() , wenn der Benutzer bereits authentifiziert ist. Fahren Sie in diesem Fall direkt mit dem Autorisierungsfluss“ .
- Der Rückruf displayProviderDialog() , wenn der Benutzer noch nicht authentifiziert ist.
-
Zeigen Sie dem Benutzer die Liste der an
displayProviderDialog()gesendeten Anbieter. -
Nachdem der Benutzer einen Anbieter ausgewählt hat, rufen Sie die URL der MVPD des Benutzers aus dem
navigateToUrl()-Callback ab. Öffnen Sie eine WebView und leiten Sie dieses WebView-Steuerelement an die URL weiter. -
Über die im vorherigen Schritt instanziierte WebView landet der Benutzer auf der Anmeldeseite von MVPD und gibt Anmeldeinformationen ein. Innerhalb der WebView finden mehrere Umleitungsvorgänge statt.
Hinweis: An dieser Stelle hat der Benutzer die Möglichkeit, den Authentifizierungsfluss abzubrechen. In diesem Fall ist Ihre Benutzeroberflächenebene dafür verantwortlich, den AccessEnabler über dieses Ereignis zu informieren, indem
setSelectedProvider()mitnullals Parameter aufgerufen wird. Dadurch kann AccessEnabler seinen internen Status bereinigen und den Authentifizierungsfluss zurücksetzen. -
Nach erfolgreicher Anmeldung durch den Benutzer erkennt Ihre Anwendungsebene das Laden einer „benutzerdefinierten Umleitungs-URL“ (d. h.:
http://adobepass.android.app). Diese benutzerdefinierte URL ist tatsächlich eine ungültige URL, die nicht für das Laden der WebView vorgesehen ist. Dies ist ein Signal, dass der Authentifizierungsfluss abgeschlossen ist und die WebView geschlossen werden muss. -
Schließen Sie das WebView-Steuerelement, und rufen Sie
getAuthenticationToken()auf, das AccessEnabler anweist, das Authentifizierungstoken vom Backend-Server abzurufen. -
[Optional] Rufen Sie
checkPreauthorizedResources(resources)auf, um zu überprüfen, welche Ressourcen der Benutzer anzeigen darf. Derresourcesist ein Array geschützter Ressourcen, das mit dem Authentifizierungstoken des Benutzers verknüpft ist.
Trigger:preAuthorizedResources()Callback
Ausführungspunkt: Nach Abschluss des Authentifizierungsflusses -
Wenn die Authentifizierung erfolgreich war, fahren Sie mit dem Autorisierungsfluss fort.
D. Autorisierungsfluss authz_flow
-
Rufen Sie getAuthorization() auf, um die Autorisierung zu initiieren
Fluss.Abhängigkeit: Gültige ResourceID(s), die mit den MVPD vereinbart wurden.
Hinweis Die Ressourcen-IDs müssen mit den auf anderen Geräten oder Plattformen verwendeten IDs übereinstimmen und für alle MVPDs identisch sein.
-
Authentifizierung und Autorisierung überprüfen.
-
Wenn der
getAuthorization()-Aufruf erfolgreich ist: Der Benutzer verfügt über gültige AuthN- und AuthZ-Token (der Benutzer ist authentifiziert und berechtigt, die angeforderten Medien zu sehen). -
Wenn
getAuthorization()fehlschlägt: Untersuchen Sie die ausgelöste Ausnahme, um ihren Typ (AuthN, AuthZ oder etwas Anderes) zu bestimmen:- Wenn es sich um einen Authentifizierungsfehler (AuthN) handelte, starten Sie den Authentifizierungsfluss erneut.
- Wenn es sich um einen Autorisierungsfehler (AuthZ) handelte, ist der Benutzer nicht berechtigt, die angeforderten Medien anzusehen, und dem Benutzer sollte eine Fehlermeldung angezeigt werden.
- Wenn ein anderer Fehlertyp aufgetreten ist (Verbindungsfehler, Netzwerkfehler usw.), zeigen Sie dem Benutzer eine entsprechende Fehlermeldung an.
-
-
Validieren des Short Media Token.
Verwenden Sie die Media Token Verifier-Bibliothek der Adobe Pass-Authentifizierung, um das vom obigengetAuthorization()-Aufruf zurückgegebene kurzlebige Medien-Token zu überprüfen:- Wenn die Validierung erfolgreich ist: Geben Sie die angeforderten Medien für den Benutzer wieder.
- Wenn die Validierung fehlschlägt: Das AuthZ-Token war ungültig, sollte die Medienanfrage abgelehnt werden und dem Benutzer sollte eine Fehlermeldung angezeigt werden.
-
Kehren Sie zu Ihrem normalen Programmablauf zurück.
E. Anzeigen des Medienflusses media_flow
- Der Benutzer wählt die anzuzeigenden Medien aus.
- Sind die Medien geschützt? Ihre Anwendung prüft, ob das ausgewählte Medium geschützt ist:
- Wenn das ausgewählte Medium geschützt ist, startet Ihre Anwendung den Autorisierungsfluss oben.
- Wenn das ausgewählte Medium nicht geschützt ist, geben Sie das Medium für den Benutzer wieder.
F. Abmeldefluss logout_flow
-
Rufen Sie
logout()auf, um den Benutzer abzumelden.
AccessEnabler löscht alle zwischengespeicherten Werte und Token für den aktuellen MVPD für den aktuellen Anforderer sowie für Anforderer mit Single Sign-On. Nach dem Löschen des Cache führt AccessEnabler einen Server-Aufruf durch, um die Server-seitigen Sitzungen zu bereinigen. Da der Server-Aufruf zu einer SAML-Umleitung an den IdP führen kann (dies ermöglicht die Sitzungsbereinigung auf der IdP-Seite), muss dieser Aufruf allen Umleitungen folgen. Aus diesem Grund muss dieser Aufruf innerhalb eines WebView-Steuerelements verarbeitet werden.a. Nach demselben Muster wie der Authentifizierungs-Workflow fordert die AccessEnabler-Domain die Anwendungsebene der Benutzeroberfläche (über den
navigateToUrl()-Rückruf) an, ein WebView-Steuerelement zu erstellen, und weist dieses Steuerelement an, die URL des Abmeldeendpunkts auf den Backend-Server zu laden.b. Auch hier muss die Benutzeroberfläche die Aktivität des WebView-Steuerelements überwachen und den Zeitpunkt erkennen, zu dem das Steuerelement bei mehreren Weiterleitungen die benutzerdefinierte URL der Anwendung lädt (d. h.:
http://adobepass.android.app/). Sobald dieses Ereignis eintritt, schließt die Benutzeroberflächen-Anwendungsebene die WebView und der Abmeldevorgang ist abgeschlossen.Hinweis: Der Abmeldefluss unterscheidet sich vom Authentifizierungsfluss insofern, als der Benutzer in keiner Weise mit der WebView interagieren muss. Die Anwendungsebene der Benutzeroberfläche verwendet eine WebView, um sicherzustellen, dass alle Weiterleitungen befolgt werden. Daher ist es möglich (und empfohlen), das WebView-Steuerelement während des Abmeldevorgangs unsichtbar (d. h. ausgeblendet) zu machen.
Benutzerflüsse für die Anmeldung mit mehreren MVPDs und die Abmeldung user_flows
Hier Sie ein Dokument, das das Verhalten bei der Verwendung mehrerer MVPDs beschreibt und beschreibt, was passiert, wenn sich der Benutzer von einer Anwendung abmeldet.
Das beschriebene Verhalten ist bei Verwendung der Android SDK-Version >= 2.0.0 verfügbar.