Übersicht über das 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 Anywhere zu verwenden. Die Implementierung besteht aus der AccessEnabler -Schnittstelle, die die Berechtigungs-API und die entityDelegate und EntitlementStatus -Protokolle, die die von der Bibliothek Trigger Rückrufe beschreiben. Die Schnittstelle wird zusammen mit dem Protokoll unter einem gemeinsamen Namen genannt: die AccessEnabler-Bibliothek.

Anforderungen für iOS und tvOS reqs

Aktuelle technische Anforderungen bezüglich der iOS- und tvOS-Plattform und der Adobe Pass-Authentifizierung finden Sie unter Anforderungen an Plattform/Gerät/Toolund lesen Sie die Versionshinweise, die im SDK-Download enthalten sind. Im Rest dieser Seite finden Sie Abschnitte, in denen Sie Änderungen feststellen, die für bestimmte SDK-Versionen und höher gelten. Beispielsweise ist Folgendes ein legitimer Hinweis zum SDK 1.7.5:

Grundlegendes zu nativen Client-Workflows flows

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.

Mit einem nativen iOS-Client nach dem ersten Aufruf von setRequestor(), können Sie entscheiden, wie Sie vorgehen:

Sie können entweder Ihre App auf die Benachrichtigung über den Erfolg von warten lassen setRequestor() oder auf den Aufruf-Warteschlangenmechanismus von AccessEnabler zurückgreifen. 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 dieser Workflow 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.

Workflow abmelden logout

Bei nativen Clients wird die Abmeldung ähnlich wie der oben beschriebene Authentifizierungsprozess durchgeführt.

Der Abmeldefluss unterscheidet sich vom Authentifizierungsfluss insofern, als der Benutzer nicht mit der UIWebView/WKWebView or SFSafariViewController Controller in irgendeiner Weise. Daher empfiehlt Adobe, das Steuerelement während des Abmeldevorgangs unsichtbar (d. h. ausgeblendet) zu machen.

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 iOS-Gerät des Clients 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

Es wird zu jedem Zeitpunkt nur ein Autorisierungstoken pro RESOURCE vom AccessEnabler zwischengespeichert. Es können mehrere Autorisierungstoken zwischengespeichert werden, sie sind jedoch mit verschiedenen Ressourcen verknüpft. Wenn ein neues Autorisierungstoken ausgestellt wird und bereits ein altes für dieselbe Ressource, ü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.

iOS

Die iOS AccessEnabler-Bibliothek umgeht die Probleme der anwendungsübergreifenden Datenfreigabe, indem die Token-Daten in einer "clipboard-ähnlichen"Datenstruktur gespeichert werden, die als Pinnwand einfügen. Diese freigegebene Ressource auf Systemebene bietet 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:

tvOS

Da auf tvOS die Zwischenablage nicht verfügbar ist, verwendet die tvOS AccessEnabler-Bibliothek die NsUserDefaults als Speicheroption. Dadurch wird das Problem behoben, dass Authentifizierungs- und Autorisierungstoken beibehalten werden, die gespeicherten Informationen können jedoch nicht von verschiedenen Anwendungen gemeinsam genutzt werden.

Änderungen an der Zwischenablage in iOS 10 - 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 der iOS 7-Zwischenablage - Aufgrund von Änderungen in der Funktionsweise von Pasteboards in iOS 7 ist die Cross-SSO zwischen Anwendungen, die auf iOS 7 ausgeführt werden, eingeschränkt. Anwendungen, die dieselbe <Bundle Seed ID>(auch bekannt als <Team ID>) Token gemeinsam verwenden, d. h., dass Apps A1 und A2 aus demselben Programmierer X Token gemeinsam nutzen, während App A1 (Programmierer X) und App A3 (Programmierer Y) Token nicht gemeinsam nutzen.

Weitere Informationen zum Konfigurieren von SSO auf iOS 7 und höher finden Sie in diesem technischen Hinweis (der Technote 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, 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 neue 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.

Durch Abmelden von einer Programmer-/MVPD-Sitzung wird der gesamte zugrunde liegende Speicher gelöscht, einschließlich aller anderen Programmierer-/MVPD-Authentifizierungstoken auf dem Gerät. Auf der anderen Seite Abbrechen des Authentifizierungsflusses (Aufrufen von setSelectedProvider(null)) den zugrunde liegenden Speicher NICHT löschen, sondern nur den aktuellen Programmierer/MVPD-Authentifizierungsversuch beeinflussen (durch Löschen des 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 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ßt und wird in den folgenden beiden Szenarien ausgeführt (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.

Token Sanitizer (AccessEnabler 1.7.5)

Ab AccessEnabler 1.7.5 läuft dieser Dienst auf setRequestor(). Sie wurde durch den Wechsel von der WiFi MAC-Adresse zur IDFA-Verfolgung von iOS 7 entwickelt. Der Bereiniger stellt sicher, dass der aktuelle Speicher nur gültige Authentifizierungstoken enthält (gültig für die Geräte-ID, die zuvor unter Verwendung der MAC-Adresse vor iOS7 berechnet wurde). Der Token-Bereiniger entfernt alle ungültigen Token.

Der Token Sanitizer-Dienst ist am nützlichsten, wenn eine AccessEnabler 1.7.5-Anwendung auf iOS 6 verwendet wird und der Benutzer dann auf iOS 7 aktualisiert. In diesem Fall sind alle Authentifizierungstoken, die in iOS 6 abgerufen wurden, ungültig (aufgrund des Geräte-ID-Algorithmus ändert sich die Verwendung der MAC-Adresse in den IDFA). Der Bereiniger löscht alle ungültigen Token, und der Benutzer wird dann nicht authentifiziert.

Ohne das Entfernen ungültiger Token durch den Token-Berater würde AccessEnabler aufgrund ungültiger Authentifizierungstoken keine Berechtigungen erlangen. Dies wäre für den Endbenutzer schwierig zu debuggen, da Autorisierungsfehlermeldungen verschlüsselt sein können und nicht allzu hilfreich bei der Ermittlung der Ursache des Problems sein können.

Format format

Beachten Sie, dass das Format der AuthN- und AuthZ-Token hier nur für Hintergrundinformationen enthalten ist. Die Struktur dieser Token kann von der Adobe Pass-Authentifizierung jederzeit geändert werden. Programmierer müssen nicht die genaue Struktur der AuthN- und AuthZ-Token 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 is der Anwendung des Programmierers ausgesetzt sind.

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_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 weitergeleitet:

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

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.

Hinweis zur Gerätebindung in AccessEnabler 1.7.5: Ab AccessEnabler 1.7.5 ändert sich die Berechnung der Geräte-ID, um Individualisierungsinformationen für ein iOS-Gerät bereitzustellen. Diese Änderung spiegelt eine Änderung in iOS 7 wider: Ab iOS 7 stellt Apple die WLAN-MAC-Adresse nicht mehr als Tracking-Option zugunsten der ID für Advertiser (IDFA) bereit. Da die 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 diese Änderung eine Reihe verschiedener möglicher Auswirkungen auf das Benutzererlebnis hat. Die verschiedenen möglichen Auswirkungen basieren darauf, von welcher Version von iOS der Benutzer aktualisiert, kombiniert mit welcher Version von AccessEnabler, von der der Programmierer ein Upgrade durchführt. Weitere Informationen zu dieser Änderung finden Sie in den Versionshinweisen des AccessEnabler SDK 1.7.5.