Android SDK - Übersicht 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 Anywhere verwenden können. Eine Android-Implementierung besteht aus der AccessEnabler-Schnittstelle, die die Berechtigungs-API definiert, und einem EntitlementDelegate-Protokoll, das die von der Bibliothek Trigger Rückrufe beschreibt. Die Schnittstelle wird zusammen mit dem Protokoll unter einem gemeinsamen Namen genannt: die AccessEnabler Android-Bibliothek.

Android-Anforderungen reqs

Aktuelle technische Anforderungen bezüglich der Android-Plattform und der Adobe Pass-Authentifizierung finden Sie unter Anforderungen an Plattform/Gerät/Tool, oder lesen Sie die Versionshinweise, die im Android SDK-Download enthalten sind.

Grundlegendes zu nativen Client-Workflows native_client_workflows

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

Nachinitialisierungs-Workflow post-init

Alle vom AccessEnabler unterstützten Berechtigungs-Workflows setzen voraus, dass Sie zuvor setRequestor() , um Ihre Identität festzustellen. Sie führen diesen Aufruf aus, um Ihre Anforderer-ID nur einmal bereitzustellen, normalerweise während der Initialisierungs-/Setup-Phase Ihrer Anwendung.

Bei den nativen Clients (z. B. Android) nach dem ersten Aufruf von setRequestor(), können Sie entscheiden, wie Sie vorgehen:

Es liegt an Ihnen, auf die Benachrichtigung über den Erfolg der setRequestor() oder sich auf den Aufruf-Warteschlangenmechanismus von AccessEnabler zu verlassen. Da alle nachfolgenden Autorisierungs- und Authentifizierungsanfragen die Anforderer-ID und die zugehörigen Konfigurationsinformationen benötigen, muss die setRequestor() -Methode blockiert effektiv alle Authentifizierungs- und Autorisierungs-API-Aufrufe, bis die Initialisierung abgeschlossen ist.

Allgemeiner Workflow für die anfängliche Authentifizierung generic

Dieser Workflow dient der Anmeldung eines Benutzers mit seinem MVPD. Nach erfolgreicher Anmeldung gibt der Backend-Server dem Benutzer ein Authentifizierungstoken aus. Während die Authentifizierung in der Regel im Rahmen des Autorisierungsprozesses erfolgt, wird im Folgenden beschrieben, wie die Authentifizierung isoliert funktioniert, und es sind keine Autorisierungsschritte enthalten.

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

Workflow abmelden logout

Bei nativen Clients werden Logouts ähnlich wie der oben beschriebene Authentifizierungsprozess verarbeitet. Nach diesem Muster öffnen AccessEnabler die benutzerdefinierten Chrome-Registerkarten und laden die URL des Abmelde-Endpunkts auf den Backend-Server.

Hinweis: Wenn Sie sich von einer Programmer-/MVPD-Sitzung abmelden, wird der zugrunde liegende Speicher für diesen spezifischen MVPD gelöscht, einschließlich aller anderen Programmierer-Authentifizierungstoken, die über SSO auf diesem Gerät abgerufen werden. Token, die für andere MVPDs oder nicht über SSO erhalten wurden, werden nicht gelöscht.

Token tokens

Definitionen und Verwendung definitions

Die Berechtigungslösung für die Adobe Pass-Authentifizierung umfasst die Generierung bestimmter Datenteile (Token), die die Adobe Pass-Authentifizierung nach erfolgreichem Abschluss der Authentifizierungs- und Autorisierungsarbeitsabläufe generiert. Diese Token werden lokal auf dem Android-Gerät des Kunden gespeichert.

Token haben eine begrenzte Lebensdauer. Nach Ablauf der Gültigkeit müssen Token erneut ausgestellt werden, indem die Authentifizierungs- und/oder Autorisierungs-Workflows neu gestartet werden.

Während der Berechtigungs-Workflows werden drei Typen von Token ausgegeben:

Nach erfolgreicher Authentifizierung und Autorisierung stellt 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.

Caching-Richtlinien caching

Authentifizierungstoken

Autorisierungstoken

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

Medien-Token

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

Persistenz persistence

Token müssen in aufeinander folgenden Ausführungen derselben Anwendung persistent sein. Das bedeutet, dass nach dem Erwerb der Authentifizierungs- und Autorisierungstoken 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. Anders ausgedrückt: Wenn ein Benutzer eine Anwendung verwendet, um sich bei einem bestimmten Identitätsanbieter anzumelden (um Authentifizierungs- und Autorisierungstoken erfolgreich zu erhalten), können dieselben Token über eine andere Anwendung verwendet werden. Der Benutzer wird bei der Anmeldung über denselben Identitätsanbieter nicht mehr zur Eingabe von Anmeldeinformationen aufgefordert.

Dieser nahtlose Authentifizierungs-/Autorisierungs-Workflow macht die Adobe Pass-Authentifizierungslösung zu einer echten TV-Überall-Implementierung. Aus rein technischer Sicht umgeht die Android AccessEnabler-Bibliothek die Probleme der anwendungsübergreifenden Datenfreigabe, indem sie die Token-Daten in einer Datenbankdatei speichert, die sich im externen Speicher befindet. Diese freigegebenen Ressourcen auf Systemebene bieten die wichtigsten Komponenten, die die Implementierung des gewünschten Anwendungsfalls für beständige Token ermöglichen:

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

Ab AccessEnabler 1.7 kann der Token-Speicher mehrere Programmer-MVPD-Kombinationen unterstützen, die auf einer mehrstufigen verschachtelten Kartenstruktur basieren, die mehrere Authentifizierungstoken enthalten kann. Dieser neue Speicher wirkt sich in keiner Weise auf die öffentliche AccessEnabler-API aus und erfordert keine Änderungen auf der Seite des Programmierers. Im Folgenden finden Sie ein Beispiel, das diese neuere Funktion veranschaulicht:

In älteren Versionen von AccessEnabler würde Schritt 6 den Benutzer als nicht authentifiziert rendern, da der Token-Speicher zuvor nur ein Authentifizierungstoken unterstützte.

NOTE: Durch Abmelden von einer Programmer-/MVPD-Sitzung 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. Abbrechen des Authentifizierungsflusses (Aufrufen von setSelectedProvider(null)) wird NICHT den zugrunde liegenden Speicher löschen, sondern nur den aktuellen Programmierer/MVPD-Authentifizierungsversuch beeinflussen (durch Löschen des MVPD für den aktuellen Programmierer).

Eine weitere speicherbezogene Funktion, die in AccessEnabler 1.7 enthalten ist, ermöglicht den Import von Authentifizierungstoken aus älteren Speicherbereichen. Dieser "Token Importer"trägt dazu bei, die Kompatibilität zwischen aufeinander folgenden AccessEnabler-Versionen zu erreichen, wodurch der SSO-Status auch bei Aktualisierung der Speicherversion beibehalten wird.

Der Importeur wird während der setRequestor() fließen und in den folgenden beiden Szenarien ausgeführt werden (vorausgesetzt, 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änderungen in der Clientanwendung.

Format format

Authentifizierungstoken authn_token

Die folgende Liste zeigt das Format des Authentifizierungstokens:

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

Autorisierungstoken authz_token

Die folgende Liste zeigt das Format des Autorisierungstokens:

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

Short Media Token short_media_token

Die folgende Liste zeigt das Format des Short-Media-Tokens. Dieses Token wird der Anwendung des Programmierers zur Verfügung gestellt. Er wird am Ende eines erfolgreichen Berechtigungsprozesses an die Anwendung 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 oben aufgeführten XML-Listen das Tag mit dem Namen simpleTokenFingerprint. Der Zweck dieses Tags besteht darin, native ID-Individualisierungsinformationen für Geräte zu speichern. Die AccessEnabler-Bibliothek kann diese Individualisierungsinformationen abrufen und den Adobe Pass-Authentifizierungsdiensten während der Berechtigungsaufrufe zur Verfügung stellen. Der Dienst 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 geräteübergreifend nicht übertragbar zu machen.

Notieren Sie sich in den oben aufgeführten XML-Listen das Tag simpleTokenFingerprint. Der Zweck dieses Tags besteht darin, native ID-Individualisierungsinformationen für Geräte zu speichern. Die AccessEnabler-Bibliothek kann diese Individualisierungsinformationen abrufen und den Adobe Pass-Authentifizierungsdiensten während der Berechtigungsaufrufe zur Verfügung stellen. Der Dienst 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 geräteübergreifend nicht übertragbar zu machen.

Da dies offensichtlich eine sicherheitsrelevante Funktion ist, ist diese Information von Natur aus "sensibel" aus sicherheitspolitischer Sicht. Daher müssen diese Informationen sowohl vor Manipulation als auch vor Abhören geschützt werden. Das Abhörproblem wird gelöst, indem die Authentifizierungs-/Autorisierungsanfragen über das HTTPS-Protokoll gesendet werden. Der Manipulationsschutz wird durch digitale Signatur der Identifizierungsinformationen des Geräts erreicht. Die AccessEnabler-Bibliothek berechnet eine Geräte-ID aus den vom Gerät bereitgestellten Informationen und sendet dann die Geräte-ID "in the clear"als Anfrageparameter 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 den AccessEnabler zurückgegeben wird. Daher ist die Geräte-ID mit dem Authentifizierungstoken verknüpft. Während des Autorisierungsflusses sendet der AccessEnabler erneut die Geräte-ID in der -Datei zusammen mit dem Authentifizierungstoken. Wenn der Validierungsprozess fehlschlägt, schlagen die Authentifizierungs-/Autorisierungs-Workflows automatisch fehl. Die Adobe Pass-Authentifizierungsserver wenden den privaten Schlüssel auf die Geräte-ID an und vergleichen ihn mit dem Wert im Authentifizierungstoken. Wenn sie nicht übereinstimmen, schlägt dieser Berechtigungsfluss fehl.