(Veraltete) Übersicht über iOS/tvOS SDK iostvos-sdk-overview

Einführung intro

iOS AccessEnabler ist eine Objective C iOS/tvOS-Bibliothek, die es Apps ermöglicht, die Adobe Pass-Authentifizierung für die Berechtigungsdienste von TV Everywhere zu verwenden. Die Implementierung besteht aus der AccessEnabler-Schnittstelle, die die Berechtigungs-API definiert, und den EntitlementDelegate- und EntitlementStatus-Protokollen, die die Callbacks beschreiben, die von der Bibliothek Trigger werden. Die Schnittstelle zusammen mit dem Protokoll wird unter einem gemeinsamen Namen genannt: die AccessEnabler-Bibliothek.

Anforderungen an iOS und tvOS reqs

Aktuelle technische Anforderungen für die iOS- und tvOS-Plattform und die Adobe Pass-Authentifizierung finden Sie unter Plattform-/Geräte-/Tool-Anforderungen und in den Versionshinweisen zum SDK-Download. Im weiteren Verlauf dieser Seite werden Abschnitte angezeigt, in denen Änderungen vermerkt werden, die für bestimmte SDK-Versionen und höher gelten. Im Folgenden finden Sie beispielsweise einen legitimen Hinweis zu SDK 1.7.5:

Grundlegendes zu nativen Client-Workflows flows

Native Client-Workflows sind in der Regel mit denen browserbasierter Adobe Pass-Authentifizierungs-Clients identisch oder diesen 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 einem nativen iOS-Client haben Sie nach Ihrem ersten Aufruf an setRequestor() die Wahl, wie Sie fortfahren:

Sie haben die Wahl, Ihre App entweder auf die Benachrichtigung über den Erfolg von setRequestor() warten zu lassen oder sie auf den Anrufwarteschlangenmechanismus von AccessEnabler zu verlassen. 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 dieser Workflow sich zwar für native Clients vom typischen browserbasierten Authentifizierungs-Workflow unterscheidet, die Schritte 1 bis 5 jedoch für native Clients und browserbasierte Clients gleich sind.

Abmelde-Workflow logout

Bei nativen Clients wird die Abmeldung ähnlich wie bei dem oben beschriebenen Authentifizierungsprozess gehandhabt.

Der Abmeldefluss unterscheidet sich vom Authentifizierungsfluss dadurch, dass der Benutzer in keiner Weise mit dem UIWebView/WKWebView or SFSafariViewController-Controller interagieren muss. Daher empfiehlt Adobe, das Steuerelement während des Abmeldevorgangs unsichtbar (d. h. ausgeblendet) zu machen.

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 iOS-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 Token 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. Dieser nahtlose Authentifizierungs-/Autorisierungs-Workflow macht die Adobe Pass-Authentifizierungslösung zu einem echten TV-Everywhere
-Implementierung.

iOS

Die iOS AccessEnabler-Bibliothek umgeht die Probleme der programmübergreifenden Datenfreigabe, indem die Tokendaten in einer „clipboard-ähnlichen“ Datenstruktur namens "Board“ gespeichert. Diese gemeinsam genutzte Ressource auf Systemebene bietet die wichtigsten Zutaten, 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:

tvOS

Da unter tvOS die Zwischenablage nicht verfügbar ist, verwendet die tvOS AccessEnabler-Bibliothek die NsUserDefaults als Speicheroption. Dies löst das Problem, Authentifizierungs- und Autorisierungs-Token beizubehalten, aber die gespeicherten Informationen können nicht zwischen verschiedenen Programmen freigegeben werden.

Änderungen der iOS 10-Zwischenablage - Beim Upgrade von einer früheren Version von iOS wird die Zwischenablage gelöscht. Das bedeutet, dass alle Anwendungen erneut authentifiziert werden müssen.

Änderungen an iOS 7-Zwischenablage - Aufgrund von Änderungen in der Funktionsweise von Zwischenablagen in iOS 7 ist die Cross-SSO zwischen Anwendungen, die auf iOS 7 ausgeführt werden, begrenzt. Anwendungen mit demselben <Bundle Seed ID> (auch als <Team ID> bezeichnet) teilen Token, d. h. Apps A1 und A2 vom selben Programmierer X teilen Token, während App A1 (Programmierer X) und App A3 (Programmierer Y) Token nicht teilen.

Weitere Informationen zur SSO-Konfiguration für iOS 7 und höher finden Sie in dieser technischen Anmerkung (die technische Anmerkung gilt für Access Enabler v1.8 und höher): https://tve.zendesk.com/entries/58233434-Configuring-Pay-TV-pass-SSO-on-iOS

Token-Speicher (AccessEnabler 1.7)

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. Hier ein Beispiel für
veranschaulicht diese neue 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.

Wenn Sie sich von einer Programmierer-/MVPD-Sitzung abmelden, wird der gesamte zugrunde liegende Speicher gelöscht, einschließlich aller anderen Programmierer-/MVPD-Authentifizierungstoken auf dem Gerät. Andererseits wird durch Abbrechen des Authentifizierungsflusses (Aufrufen von setSelectedProvider(null)) DER zugrunde liegende Speicher NICHT gelöscht, sondern es wirkt sich nur auf den aktuellen Authentifizierungsversuch von Programmierer/MVPD aus (durch Löschen der MVPD für den aktuellen Programmierer).

Token Importer (AccessEnabler 1.7)

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.

Token Sanitizer (AccessEnabler 1.7.5)

Ab AccessEnabler 1.7.5 läuft dieser Dienst auf setRequestor(). Er wurde als Ergebnis des Umstiegs von iOS 7 von der WiFi MAC-Adresse auf den IDFA zum Tracking entwickelt. Die Bereinigung stellt sicher, dass der aktuelle Speicher nur gültige Authentifizierungstoken enthält (gültig in Bezug auf die Geräte-ID, die zuvor anhand der MAC-Adresse vor iOS7 berechnet wurde). Die Token-Bereinigung entfernt alle ungültigen Token.

Der Service „Token-Bereinigung“ ist am nützlichsten, wenn eine AccessEnabler 1.7.5-Anwendung auf iOS 6 verwendet wird und die Benutzerin bzw. der Benutzer dann auf iOS 7 aktualisiert. In diesem Fall sind alle Authentifizierungs-Token, die in iOS 6 abgerufen wurden, ungültig (aufgrund der Änderung des Geräte-ID-Algorithmus von der Verwendung der MAC-Adresse zum IDFA). Die Bereinigung löscht alle ungültigen Token, und die Authentifizierung des Benutzers wird dann aufgehoben.

Ohne das Entfernen ungültiger Token durch den Token-Sanitizer kann AccessEnabler aufgrund ungültiger Authentifizierungs-Token keine Autorisierungen abrufen. Dies erweist sich als schwierig für den Endbenutzer, das Problem zu debuggen, da Autorisierungsfehlermeldungen kryptisch sein können und nicht übermäßig hilfreich bei der Bestimmung der Ursache des Problems sind.

Format format

Beachten Sie, dass das Format der AuthN- und AuthZ-Token hier nur zur Hintergrundinformation enthalten ist. Die Struktur dieser Token kann durch die Adobe Pass-Authentifizierung jederzeit geändert werden. Programmierer müssen die genaue Struktur der AuthN- und AuthZ-Token nicht kennen, um ihre Apps zu implementieren, da die AuthN- und AuthZ-Token nicht auf dem lokalen Gerät verfügbar gemacht werden. Das Short Media Token wird Programm des Programmierers verfügbar gemacht.

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_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 den Antrag 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.

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.

Hinweis zur Gerätebindung in AccessEnabler 1.7.5: Ab AccessEnabler 1.7.5 ändert sich die Art und Weise, wie die Geräte-ID berechnet wird, um Personalisierungsinformationen für ein iOS-Gerät bereitzustellen. Diese Änderung spiegelt eine Änderung in iOS 7 wider: Ab iOS 7 bietet Apple die WiFi-MAC-Adresse nicht mehr als Tracking-Option, sondern stattdessen die Kennung für Werbetreibende (IDFA). Da Individualisierungsinformationen für eine App, die auf iOS 7 ausgeführt wird, auf dem IDFA basieren und diese Informationen in die Berechtigungsfluss-Token eingebettet sind, bedeutet dies, dass es eine Reihe verschiedener möglicher Auswirkungen auf das Benutzererlebnis gibt, die aus dieser Änderung resultieren. Die verschiedenen möglichen Auswirkungen hängen davon ab, von welcher Version von iOS der Anwender ein Upgrade durchführt und von welcher Version des AccessEnabler der Programmierer ein Upgrade durchführt. Weitere Informationen zu dieser Änderung finden Sie in den Versionshinweisen zu AccessEnabler SDK 1.7.5.