Übersicht über (ältere) Android SDK android-sdk-overview

Einführung intro

Android AccessEnabler ist eine Java Android-Bibliothek, mit der Mobile Apps die Adobe Pass-Authentifizierung für die Berechtigungsdienste von TV Everywhere verwenden können. Eine Android-Implementierung besteht aus der AccessEnabler-Schnittstelle, die die Berechtigungs-API definiert, und einem EntitlementDelegate-Protokoll, das die Callbacks beschreibt, die die Bibliothek Trigger. Die Schnittstelle und das Protokoll werden unter einem gemeinsamen Namen genannt: der AccessEnabler Android Library.

Android-Anforderungen reqs

Aktuelle technische Anforderungen an die Android-Plattform und die Adobe Pass-Authentifizierung finden Sie unter Plattform-/Geräte-/Tool-) oder in den Versionshinweisen zum Android SDK-Download.

Grundlegendes zu nativen Client-Workflows native_client_workflows

Native Client-Workflows sind in der Regel mit denen browserbasierter Adobe Pass-Authentifizierungs-Clients identisch oder ihnen sehr ähnlich. Es gibt jedoch einige Ausnahmen, wie unten beschrieben.

Workflow nach der Initialisierung post-init

Bei allen vom AccessEnabler unterstützten Berechtigungs-Workflows wird davon ausgegangen, dass Sie setRequestor() zuvor aufgerufen haben, um Ihre Identität festzulegen. Sie führen diesen Aufruf aus, um Ihre Anforderer-ID nur einmal anzugeben, normalerweise während der Initialisierungs-/Einrichtungsphase Ihrer Anwendung.

Bei den nativen Clients (z. B. Android) haben Sie nach Ihrem ersten Aufruf an setRequestor() die Wahl, wie Sie fortfahren möchten:

Es liegt an Ihnen zu entscheiden, ob Sie auf die Benachrichtigung über den Erfolg von setRequestor() warten oder sich auf den Call Queue-Mechanismus von AccessEnabler verlassen sollen. Da alle nachfolgenden Autorisierungs- und Authentifizierungsanfragen die Anforderer-ID und die zugehörigen Konfigurationsinformationen benötigen, blockiert die setRequestor()-Methode effektiv alle Authentifizierungs- und Autorisierungs-API-Aufrufe, bis die Initialisierung abgeschlossen ist.

Allgemeiner anfänglicher Authentifizierungs-Workflow generic

Dieser Workflow dient der Anmeldung von Benutzenden mit ihrer MVPD. Nach erfolgreicher Anmeldung gibt der Backend-Server dem Benutzer ein Authentifizierungstoken aus. Während die Authentifizierung in der Regel als Teil des Autorisierungsprozesses erfolgt, wird im Folgenden beschrieben, wie die Authentifizierung isoliert funktionieren kann und keine Autorisierungsschritte enthält.

Beachten Sie, dass sich der folgende native Client-Workflow zwar vom typischen browserbasierten Authentifizierungs-Workflow unterscheidet, die Schritte 1 bis 5 jedoch für native Clients und browserbasierte Clients identisch sind:

Abmelde-Workflow logout

Für native Clients werden Logouts ähnlich wie beim oben beschriebenen Authentifizierungsprozess gehandhabt. Nach diesem Muster öffnet AccessEnabler benutzerdefinierte Chrome-Registerkarten und lädt die URL des Abmeldeendpunkts auf den Backend-Server.

Hinweis: Abmelden von einer Programmierer-/MVPD-Sitzung wird gelöscht
Der zugrunde liegende Speicher für diese spezifische MVPD, einschließlich aller
andere Programmierer-Authentifizierungstoken, die über SSO unter abgerufen wurden
Dieses Gerät. Token, die für andere MVPDs oder nicht über SSO erhalten wurden, werden nicht
gelöscht werden.

Token tokens

Definitionen und Verwendung definitions

Die Lösung für die Berechtigung für die Adobe Pass-Authentifizierung umfasst die Generierung bestimmter Datenelemente (Token), die von der Adobe Pass-Authentifizierung nach erfolgreichem Abschluss der Authentifizierungs- und Autorisierungs-Workflows generiert werden. Diese Token werden lokal auf dem Android-Gerät des Clients gespeichert.

Token haben eine begrenzte Lebensdauer. Nach Ablauf müssen Token durch die erneute Initiierung der Authentifizierungs- und/oder Autorisierungs-Workflows erneut ausgestellt werden.

Es gibt drei Arten von Token, die während der Berechtigungs-Workflows ausgegeben werden:

Nach erfolgreicher Authentifizierung und Autorisierung gibt die Adobe Pass-Authentifizierung Authentifizierungs-, Autorisierungs- und kurzlebige Medien-Token aus. Diese Token sollten auf dem Gerät des Benutzers zwischengespeichert und für die Dauer der zugehörigen Lebensdauer verwendet werden.

Richtlinien für das Zwischenspeichern caching

Authentifizierungstoken

Autorisierungs-Token

Es wird immer nur EIN Autorisierungs-Token pro Ressource vom AccessEnabler zwischengespeichert. Es können mehrere Autorisierungs-Token zwischengespeichert werden, sie sind jedoch mit verschiedenen Ressourcen verknüpft. Wenn ein neues Autorisierungs-Token ausgegeben wird und bereits ein altes für dieselbe Ressource vorhanden ist, überschreibt das neue Token den vorhandenen zwischengespeicherten Wert.

Medien-Token

Das kurzlebige Medien-Token sollte ÜBERHAUPT NICHT zwischengespeichert werden. Das Medien-Token sollte jedes Mal vom Server abgerufen werden, wenn eine Autorisierungs-API aufgerufen wird, da es auf die einmalige Verwendung beschränkt ist.

Persistenz persistence

Token müssen über mehrere aufeinander folgende Ausführungen desselben Programms hinweg persistent sein. Das bedeutet, dass nach dem Abrufen der Authentifizierungs- und Autorisierungs-Token und dem Schließen der Anwendung durch den Benutzer dieselben Token für die Anwendung verfügbar sind, wenn der Benutzer die Anwendung erneut öffnet. Darüber hinaus ist es wünschenswert, dass diese Token über mehrere Anwendungen hinweg persistent sind. Mit anderen Worten: Wenn ein Benutzer eine Anwendung verwendet, um sich bei einem bestimmten Identitätsanbieter anzumelden (und Authentifizierungs- und Autorisierungs-Token erfolgreich erhalten hat), können dieselben Token über eine andere Anwendung verwendet werden, und der Benutzer wird bei der Anmeldung über denselben Identitätsanbieter nicht mehr zur Eingabe von Anmeldeinformationen aufgefordert.

Diese Art von nahtlosem Authentifizierungs-/Autorisierungs-Workflow macht die Adobe Pass-Authentifizierungslösung zu einer echten TV-Everywhere-Implementierung. Aus rein technischer Sicht umgeht die Android AccessEnabler-Bibliothek die Probleme der programmübergreifenden Datenfreigabe, indem die Token-Daten in einer Datenbankdatei gespeichert werden, die sich auf einem externen Speicher befindet. Diese freigegebenen Ressourcen auf Systemebene bieten die wichtigsten Bestandteile, die die Implementierung des gewünschten Anwendungsfalls für persistente Token ermöglichen:

Sobald ein bestimmtes Token im Token-Cache platziert ist, wird seine Gültigkeit von der AccessEnabler-Bibliothek zu verschiedenen Zeiten überprüft. Ein gültiges Token wird wie folgt definiert:

Ab AccessEnabler 1.7 kann der Token-Speicher mehrere Programmer-MVPD-Kombinationen unterstützen, wobei eine mehrstufige verschachtelte Zuordnungsstruktur verwendet wird, die mehrere Authentifizierungstoken enthalten kann. Dieser neue Speicher hat keinerlei Auswirkungen auf die öffentliche AccessEnabler-API und erfordert keine Änderungen seitens des Programmierers. Im Folgenden finden Sie ein Beispiel für diese neuere Funktion:

In älteren Versionen von AccessEnabler wurde der Benutzer in Schritt 6 als nicht authentifiziert gerendert, da der Token-Speicher zuvor nur ein Authentifizierungstoken unterstützt hatte.

HINWEIS Wenn Sie sich von einer Programmierer-/MVPD-Sitzung abmelden, wird der zugrunde liegende Speicher gelöscht, einschließlich aller anderen Programmierer-Authentifizierungstoken auf dem Gerät mit SSO. Token, die für andere MVPDs oder nicht über SSO erhalten wurden, werden nicht gelöscht. Das Abbrechen des Authentifizierungsflusses (Aufrufen von setSelectedProvider(null)) löscht NICHT den zugrunde liegenden Speicher, sondern wirkt sich nur auf den aktuellen Authentifizierungsversuch von Programmierer/MVPD aus (durch Löschen der MVPD für den aktuellen Programmierer).

Eine weitere speicherbezogene Funktion, die in AccessEnabler 1.7 enthalten ist, ermöglicht den Import von Authentifizierungs-Token aus älteren Speicherbereichen. Dieser „Token-Importer“ trägt dazu bei, die Kompatibilität zwischen aufeinander folgenden AccessEnabler-Versionen zu erreichen, wobei der SSO-Status auch bei einem Upgrade der Speicherversion erhalten bleibt.

Das Import-Tool wird während des setRequestor() ausgeführt und läuft in den folgenden beiden Szenarien (unter der Annahme, dass im aktuellen Speicher kein gültiges Authentifizierungstoken für den aktuellen Programmierer vorhanden ist):

Der Importvorgang ist für den Programmierer transparent und erfordert keine Codeänderung in der Client-Anwendung.

Format format

Authentifizierungstoken authn_token

In der folgenden Liste ist das Format des Authentifizierungstokens aufgeführt:

    <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>

Autorisierungs-Token authz_token

In der folgenden Liste ist das Format des Autorisierungs-Tokens aufgeführt:

    <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>

Kurzes Medien-Token short_media_token

In der folgenden Liste wird das Format des Kurzwahltokens angezeigt. Dieses Token wird für die Anwendung des Programmierers verfügbar gemacht. Sie wird am Ende eines erfolgreichen Berechtigungsprozesses an das Programm des Programmierers übergeben:

    <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>

Gerätebindung device_binding

Beachten Sie in den obigen XML-Auflistungen das Tag mit dem Titel simpleTokenFingerprint. Der Zweck dieses Tags ist es, native Geräte-ID-Individualisierungsinformationen zu enthalten. Die AccessEnabler-Bibliothek kann diese Personalisierungsinformationen abrufen und während der Berechtigungsaufrufe für die Adobe Pass-Authentifizierungsdienste verfügbar machen. Der Service verwendet diese Informationen und bettet sie in die tatsächlichen Token ein, wodurch die Token effektiv an ein bestimmtes Gerät gebunden werden. Das Endziel besteht darin, die Token nicht geräteübergreifend übertragbar zu machen.

Beachten Sie in den obigen XML-Listen das Tag „simpleTokenFingerprint“. Der Zweck dieses Tags ist es, native Geräte-ID-Individualisierungsinformationen zu enthalten. Die AccessEnabler-Bibliothek kann diese Personalisierungsinformationen abrufen und während der Berechtigungsaufrufe für die Adobe Pass-Authentifizierungsdienste verfügbar machen. Der Service verwendet diese Informationen und bettet sie in die tatsächlichen Token ein, wodurch die Token effektiv an ein bestimmtes Gerät gebunden werden. Das Endziel besteht darin, die Token nicht geräteübergreifend übertragbar zu machen.

Da es sich hierbei offensichtlich um eine sicherheitsbezogene Funktion handelt, sind diese Informationen aus Sicherheitssicht von Natur aus „sensibel“. Daher müssen diese Informationen sowohl vor Manipulationen als auch vor Abhörmaßnahmen geschützt werden. Das Problem des Abhörens wird gelöst, indem die Authentifizierungs-/Autorisierungsanfragen über das HTTPS-Protokoll gesendet werden. Der Manipulationsschutz wird durch eine digitale Signatur der Geräterkennungsinformationen gehandhabt. Die AccessEnabler-Bibliothek berechnet eine Geräte-ID aus den vom Gerät bereitgestellten Informationen und sendet dann die Geräte-ID „im Klartext“ als Abfrageparameter an die Adobe Pass-Authentifizierungsserver. Die Adobe Pass-Authentifizierungsserver signieren die Geräte-ID digital mit dem privaten Adobe-Schlüssel und fügen sie dem Authentifizierungstoken hinzu, das an AccessEnabler zurückgegeben wird. Daher ist die Geräte-ID an das Authentifizierungs-Token gebunden. Während des Autorisierungsflusses sendet der AccessEnabler die Geräte-ID erneut als gelöscht zusammen mit dem Authentifizierungstoken. Ein Fehlschlagen des Validierungsprozesses führt automatisch zum Fehlschlagen der Authentifizierungs-/Autorisierungs-Workflows. Die Adobe Pass-Authentifizierungsserver wenden den privaten Schlüssel auf die Geräte-ID an und vergleichen ihn mit dem Wert im Authentifizierungs-Token. Wenn sie nicht übereinstimmen, schlägt dieser Berechtigungsfluss fehl.