Présentation du SDK iOS/tvOS iostvos-sdk-overview

Introduction intro

iOS AccessEnabler est une bibliothèque Objective C iOS/tvOS qui permet aux applications mobiles d’utiliser l’authentification Adobe Pass pour les services de droits de TV Everywhere. L’implémentation consiste à AccessEnabler qui définit l’API de droits et la variable EntitlementDelegate et EntitlementStatus qui décrit les rappels déclenchés par la bibliothèque . L’interface avec le protocole est référencée sous un nom commun : la bibliothèque AccessEnabler.

Configuration requise pour iOS et tvOS reqs

Pour connaître les exigences techniques actuelles relatives à la plateforme iOS et tvOS et à l’authentification Adobe Pass, voir Configuration requise pour la plateforme/périphérique/outilet consulter les notes de mise à jour incluses avec le téléchargement du SDK. Dans le reste de cette page, vous trouverez des sections qui mentionnent les modifications qui s’appliquent à des versions de SDK spécifiques et supérieures. Par exemple, voici une remarque légitime concernant le SDK 1.7.5 :

Présentation des processus client natifs flows

Les workflows clients natifs sont généralement identiques ou très similaires à ceux des clients Adobe Pass Authentication basés sur un navigateur. Il existe toutefois quelques exceptions, comme décrit ci-dessous.

Processus de post-initialisation post-init

Tous les workflows de droits pris en charge par AccessEnabler supposent que vous avez précédemment appelé setRequestor() pour établir votre identité. Vous effectuez cet appel pour ne fournir votre ID de demandeur qu’une seule fois, généralement pendant la phase d’initialisation/de configuration de votre application.

Avec un client natif iOS, après votre appel initial vers setRequestor(), vous avez la possibilité de procéder comme suit :

Vous pouvez demander à votre application d’attendre la notification de la réussite de setRequestor() ou le faire dépendre du mécanisme de file d’attente d’appels d’AccessEnabler. Comme toutes les demandes d’autorisation et d’authentification suivantes ont besoin de l’identifiant du demandeur et des informations de configuration associées, la variable setRequestor() bloque efficacement tous les appels de l’API d’authentification et d’autorisation jusqu’à ce que l’initialisation soit terminée.

Processus d’authentification initiale générique generic

Le but de ce workflow est de se connecter à un utilisateur avec son MVPD. Une fois la connexion établie, le serveur principal émet un jeton d’authentification à l’utilisateur. Bien que l’authentification soit généralement effectuée dans le cadre du processus d’autorisation, la section suivante décrit le fonctionnement de l’authentification en isolation, sans inclure d’étapes d’autorisation.

Notez que, bien que ce processus diffère pour les clients natifs du processus d’authentification type basé sur un navigateur, les étapes 1 à 5 sont les mêmes pour les clients natifs et les clients basés sur un navigateur.

Processus de déconnexion logout

Pour les clients natifs, la déconnexion est gérée de la même manière que le processus d’authentification décrit ci-dessus.

Le flux de déconnexion diffère du flux d’authentification dans la mesure où l’utilisateur n’est pas tenu d’interagir avec la variable UIWebView/WKWebView or SFSafariViewController du contrôleur, de quelque manière que ce soit. Par conséquent, Adobe recommande de rendre le contrôle invisible (c’est-à-dire masqué) pendant le processus de déconnexion.

Jetons tokens

Définitions et utilisation definitions

La solution de droit d’authentification Adobe Pass tourne autour de la génération de données (jetons) spécifiques générées par l’authentification Adobe Pass une fois les workflows d’authentification et d’autorisation terminés avec succès. Ces jetons sont stockés localement sur le périphérique iOS du client.

La durée de vie des jetons est limitée. Lors de l’expiration, les jetons doivent être réémis par le réinitialisation des workflows d’authentification et/ou d’autorisation.

Il existe trois types de jetons émis lors des workflows de droits :

Une fois l’authentification et l’autorisation réussies, l’authentification Adobe Pass émet des jetons d’authentification, d’autorisation et de média de courte durée. Ces jetons doivent être mis en cache sur l’appareil de l’utilisateur et utilisés pendant la durée de vie associée.

Instructions de mise en cache caching

Jeton d’authentification

Jeton d’autorisation

A tout moment, seul un jeton d’autorisation PAR RESSOURCE est mis en cache par AccessEnabler. Plusieurs jetons d’autorisation peuvent être mis en cache, mais ils sont associés à différentes ressources. Chaque fois qu’un nouveau jeton d’autorisation est émis et qu’un ancien existe déjà pour la même ressource ;, le nouveau jeton remplace la valeur mise en cache existante.

Jeton de média

Le jeton multimédia de courte durée ne doit PAS être mis en cache du tout. Le jeton multimédia doit être récupéré à partir du serveur chaque fois qu’une API d’autorisation est appelée, car il est limité à une utilisation unique.

Persistance persistence

Les jetons doivent être persistants sur plusieurs exécutions consécutives de la même application. Cela signifie qu’une fois que les jetons d’authentification et d’autorisation ont été acquis et que l’utilisateur ferme l’application, les mêmes jetons sont disponibles pour l’application lorsque l’utilisateur rouvre l’application. En outre, il est souhaitable que ces jetons soient persistants dans plusieurs applications. En d’autres termes, lorsqu’un utilisateur utilise une application pour se connecter à un fournisseur d’identité spécifique (obtention réussie des jetons d’authentification et d’autorisation), les mêmes jetons peuvent être utilisés par le biais d’une autre application et l’utilisateur n’est plus invité à saisir les informations d’identification lors de sa connexion via le même fournisseur d’identité. Ce type de workflow d’authentification/d’autorisation transparent fait de la solution d’authentification Adobe Pass une véritable implémentation de TV-partout.

iOS

La bibliothèque iOS AccessEnabler traite des problèmes de partage de données entre applications en stockant les données de jeton dans une structure de données "de type Presse-papiers" appelée coller le panorama. Cette ressource partagée au niveau du système fournit les ingrédients clés qui permettent la mise en oeuvre du cas d’utilisation de jetons persistants souhaité :

Une fois qu’un jeton particulier est placé dans le cache de jetons, sa validité est vérifiée à différents moments par la bibliothèque AccessEnabler. Un jeton valide est défini comme suit :

tvOS

Comme le tableau de bord n’est pas disponible sur tvOS, la bibliothèque tvOS AccessEnabler utilise NsUserDefaults comme option de stockage. Cela résout le problème de la persistance des jetons d’authentification et d’autorisation, mais les informations stockées ne peuvent pas être partagées entre différentes applications.

Modifications du tableau de bord iOS 10 - Lors de la mise à niveau à partir d’une version précédente d’iOS, le tableau de bord est effacé. Cela signifie que toutes les applications doivent être réauthentifiées.

Modifications du tableau de bord iOS 7 - En raison de changements dans le fonctionnement des tableaux de bord sur iOS 7, il y aura une limitation de l’authentification unique croisée entre les applications s’exécutant sur iOS 7. Applications ayant le même <Bundle Seed ID>(également appelé <Team ID>) partagera des jetons, ce qui signifie que les applications A1 et A2 du même programmeur X partageront des jetons, tandis que l’application A1 (programmeur X) et l’application A3 (programmeur Y) ne partageront pas de jetons.

Veuillez lire cette note technique pour plus d’informations sur la configuration de la connexion unique sur iOS 7 et versions ultérieures (la note technique s’applique à Access Enabler v1.8 et versions ultérieures) : https://tve.zendesk.com/entries/58233434-Configuring-Pay-TV-pass-SSO-on-iOS

Stockage des jetons (AccessEnabler 1.7)

À partir de la version 1.7 d’AccessEnabler, le stockage des jetons peut prendre en charge plusieurs combinaisons Programmer-MVPD, en s’appuyant sur une structure de mappage imbriquée à plusieurs niveaux pouvant contenir plusieurs jetons d’authentification. Ce nouveau stockage n’affecte en aucune manière l’API publique AccessEnabler et ne nécessite aucune modification du côté du programmeur. Voici un exemple qui illustre cette nouvelle fonctionnalité :

Dans les anciennes versions d’AccessEnabler, l’étape 6 affichait l’utilisateur comme non authentifié, car le stockage des jetons ne prenait auparavant en charge qu’un seul jeton d’authentification.

La déconnexion d’une session Programmer/MVPD effacera l’ensemble du stockage sous-jacent, y compris tous les autres jetons d’authentification Programmer/MVPD sur l’appareil. En revanche, annuler le flux d’authentification (appel setSelectedProvider(null)) N’effacera PAS le stockage sous-jacent, mais cela affectera uniquement la tentative d’authentification programmeur/MVPD actuelle (en effaçant le MVPD pour le programmeur actuel).

Importateur de jetons (AccessEnabler 1.7)

Une autre fonctionnalité de stockage incluse dans AccessEnabler 1.7 permet d’importer des jetons d’authentification à partir d’anciennes zones de stockage. Cet "Importateur de jetons" permet d’assurer la compatibilité entre les versions consécutives d’AccessEnabler, en conservant l’état SSO même lorsque la version de stockage est mise à niveau. L’importateur est exécuté au cours de la setRequestor() flux et s’exécute dans les deux scénarios suivants (en supposant qu’aucun jeton d’authentification valide pour le programmeur actuel ne soit présent dans le stockage actuel) :

L’opération d’importation est transparente pour le programmeur et ne nécessite aucun changement de code dans l’application cliente.

Correcteur de jeton (AccessEnabler 1.7.5)

À partir de AccessEnabler 1.7.5, ce service s’exécute sur setRequestor(). Il a été développé suite au basculement d’iOS 7 de l’adresse WiFi MAC vers l’IDFA pour le suivi. L’analyseur assure que le stockage actuel contient uniquement des jetons d’authentification valides (valides en termes d’identifiant de l’appareil, anciennement calculé à l’aide de l’adresse MAC, avant iOS7). Le programme Token Sanitizer supprime tous les jetons non valides.

Le service Token Sanitizer est particulièrement utile lorsqu’une application AccessEnabler 1.7.5 est utilisée sur iOS 6, puis que l’utilisateur effectue la mise à jour vers iOS 7. Dans ce cas, tous les jetons d’authentification obtenus sur iOS 6 seront désormais non valides (en raison du changement de l’algorithme d’identifiant de périphérique de l’utilisation de l’adresse MAC à l’IDFA). L’analyseur efface tous les jetons non valides et l’utilisateur n’est alors pas authentifié.

Si l’outil de nettoyage des jetons ne supprimait pas les jetons non valides, AccessEnabler ne parvenait pas à obtenir les autorisations en raison de la présence de jetons d’authentification non valides. Cela s’avérerait difficile à déboguer pour l’utilisateur final, car les messages d’erreur d’autorisation peuvent être énigmatiques et ne sont pas trop utiles pour déterminer la cause du problème.

Format format

Notez que le format des jetons AuthN et AuthZ est inclus ici uniquement pour des informations de fond. La structure de ces jetons peut être modifiée par l’authentification Adobe Pass à tout moment. Les programmeurs n’ont pas besoin de connaître la structure exacte des jetons AuthN et AuthZ pour mettre en oeuvre leurs applications, car les jetons AuthN et AuthZ ne sont pas exposés sur l’appareil local. Jeton de média court is exposé à l’application du programmeur.

Jeton d’authentification authn_token

La liste ci-dessous présente le format du jeton d’authentification :

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

Jeton d’autorisation authz_token

La liste ci-dessous présente le format du jeton d’autorisation :

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

Jeton de média court short_token

La liste ci-dessous présente le format du jeton multimédia court. Ce jeton est exposé à l’application du programmeur. Il est transmis à l’application du programmeur à la fin d’un processus de droit réussi :

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

Liaison de périphérique device_binding

Dans les listes XML ci-dessus, notez la balise intitulée simpleTokenFingerprint. L’objectif de cette balise est de contenir des informations d’individualisation des identifiants d’appareil natifs. La bibliothèque AccessEnabler peut obtenir ces informations d’individualisation et les mettre à la disposition des services d’authentification Adobe Pass lors des appels de droits. Le service utilisera ces informations et les incorporera dans les jetons réels, liant ainsi efficacement les jetons à un appareil spécifique. L’objectif final est de rendre les jetons non transférables sur plusieurs appareils.

Puisqu’il s’agit évidemment d’une fonctionnalité liée à la sécurité, ces informations sont intrinsèquement "sensibles" du point de vue de la sécurité. Par conséquent, ces informations doivent être protégées contre l’altération et l’écoutes. Le problème d’écoute est résolu en envoyant les demandes d’authentification/d’autorisation via le protocole HTTPS. La protection de l’altération est gérée par la signature numérique des informations d’identification de l’appareil. La bibliothèque AccessEnabler calcule un ID d’appareil à partir des informations fournies par l’appareil, puis envoie l’ID d’appareil "en clair" aux serveurs d’authentification Adobe Pass en tant que paramètre de requête. Les serveurs d’authentification Adobe Pass signent numériquement l’identifiant de l’appareil avec la clé privée de l’Adobe et l’ajoutent au jeton d’authentification renvoyé à AccessEnabler. Par conséquent, l’identifiant de l’appareil est lié au jeton d’authentification. Pendant le flux d’autorisation, AccessEnabler envoie à nouveau l’identifiant de l’appareil en clair, avec le jeton d’authentification. L’échec du processus de validation entraînera automatiquement l’échec des workflows d’authentification/d’autorisation. Les serveurs d’authentification Adobe Pass appliquent la clé privée à l’identifiant de l’appareil et la comparent à la valeur du jeton d’authentification. S’ils ne correspondent pas, ce flux de droits échoue.

Remarque sur la liaison de périphériques dans AccessEnabler 1.7.5 : À partir de la version 1.7.5 d’AccessEnabler, le mode de calcul de l’identifiant d’appareil a été modifié afin de fournir des informations d’individualisation à un appareil iOS. Cette modification reflète un changement dans iOS 7 : depuis iOS 7, Apple ne fournit plus l’adresse MAC WiFi comme option de suivi, au profit de son identifiant pour les annonceurs (IDFA). Étant donné que les informations d’individualisation d’une application s’exécutant sur iOS 7 sont basées sur l’IDFA et que ces informations sont incorporées dans les jetons de flux de droits, cela signifie qu’il existe un certain nombre d’effets possibles sur l’expérience utilisateur résultant de cette modification. Les différents effets possibles sont basés sur la version d’iOS mise à niveau de l’utilisateur associée à la version d’AccessEnabler à partir de laquelle le programmeur effectue une mise à niveau. Pour plus d’informations sur cette modification, voir les Notes de mise à jour incluses dans le SDK AccessEnabler 1.7.5.