Présentation d’iOS/tvOS SDK (hérité) 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 se compose de l’interface AccessEnabler qui définit l’API de droits et des protocoles EntitlementDelegate et EntitlementStatus qui décrivent les rappels déclenchés par la bibliothèque. L’interface et le protocole sont référencés 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, consultez la section Configuration requise pour la plateforme/l’appareil/l’outil et consultez les notes de mise à jour accompagnant le téléchargement de SDK. Tout au long du reste de cette page, vous trouverez des sections qui notent les modifications qui s’appliquent à des versions de SDK particulières et à des versions ultérieures. Par exemple, voici une note légitime concernant le SDK 1.7.5 :

Présentation des workflows client natifs flows

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

Workflow 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 passez cet appel pour fournir votre ID de demandeur une seule fois, généralement au cours de la phase d’initialisation/configuration de votre application.

Avec un client natif iOS, après votre appel initial à setRequestor(), vous avez le choix de la manière de procéder :

Vous pouvez choisir d’attendre que votre application soit informée du succès de l’setRequestor() ou de faire appel au mécanisme de file d’attente d’appels d’AccessEnabler. Comme toutes les demandes d’authentification et d’autorisation suivantes nécessitent l’ID du demandeur et les informations de configuration associées, la méthode setRequestor() bloque efficacement tous les appels d’API d’authentification et d’autorisation jusqu’à ce que l’initialisation soit terminée.

Workflow d’authentification initiale générique generic

L’objectif de ce workflow est de 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, ce qui suit décrit comment l’authentification peut fonctionner de manière isolée et n’inclut aucune étape d’autorisation.

Notez que bien que ce workflow diffère pour les clients natifs du workflow d’authentification standard basé sur un navigateur, les étapes 1 à 5 sont identiques pour les clients natifs et les clients basés sur un navigateur.

Workflow 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 de quelque manière que ce soit avec le contrôleur de UIWebView/WKWebView or SFSafariViewController. Par conséquent, Adobe vous 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 Droits d’authentification Adobe Pass tourne autour de la génération de données spécifiques (jetons) que l’authentification Adobe Pass génère une fois les workflows d’authentification et d’autorisation terminés. Ces jetons sont stockés localement sur l’appareil iOS du client.

Les jetons ont une durée de vie limitée. À leur expiration, les jetons doivent être émis à nouveau par le biais du redémarrage des workflows d’authentification et/ou d’autorisation.

Il existe trois types de jetons émis pendant les 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 qui leur est associée.

Instructions de mise en cache caching

Jeton d’authentification

Jeton d’autorisation

À un moment donné, un seul 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 jeton existe déjà pour la même ressource, le nouveau jeton remplace la valeur mise en cache existante.

Jeton multimédia

Le jeton de mé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 son utilisation est limitée à 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 les jetons d’authentification et d’autorisation acquis et que l’utilisateur ferme l’application, les mêmes jetons sont disponibles pour l’application lorsque l’utilisateur ouvre à nouveau l’application. En outre, il est souhaitable que ces jetons soient persistants dans plusieurs applications. En d’autres termes, une fois qu’un utilisateur ou une utilisatrice utilise une application pour se connecter avec 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. En outre, l’utilisateur ou l’utilisatrice n’est plus invité à fournir des informations d’identification lors de la connexion via le même fournisseur d’identité. Ce type de workflow d’authentification/autorisation transparent est ce qui fait de la solution d’authentification Adobe Pass une véritable solution TV-Everywhere
mise en œuvre.

iOS

La bibliothèque iOS AccessEnabler résout les 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 tableau de collage. Cette ressource partagée au niveau du système fournit les ingrédients clés qui permettent la mise en œuvre 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

Étant donné que sur tvOS, la table de montage n’est pas disponible, 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 de la table de montage iOS 10 - Lors de la mise à niveau à partir d’une version précédente d’iOS, la table de montage sera effacée. Cela signifie que toutes les applications doivent être réauthentifiées.

Modifications de la table de montage d’iOS 7 - En raison de modifications dans le fonctionnement des tables de montage sur iOS 7, l’authentification unique (Cross-SSO) entre les applications s’exécutant sur iOS 7 sera limitée. Les applications ayant le même <Bundle Seed ID> (également appelées <Team ID>) partagent des jetons, ce qui signifie que les applications A1 et A2 du même programmeur X partagent des jetons, tandis que l’application A1 (programmeur X) et l’application A3 (programmeur Y) ne partagent 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 version 1.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 d’AccessEnabler 1.7, le stockage des jetons peut prendre en charge plusieurs combinaisons Programmeur-MVPD, en s’appuyant sur une structure de mappage imbriqué à plusieurs niveaux qui peut contenir plusieurs jetons d’authentification. Ce nouveau stockage n’affecte en rien 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 rendait 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 de l’appareil. D’un autre côté, l’annulation du flux d’authentification (en invoquant setSelectedProvider(null)) n’effacera PAS le stockage sous-jacent, mais elle n’affectera que la tentative d’authentification actuelle du programmeur/MVPD (en effaçant le MVPD pour le programmeur actuel).

Importateur de jetons (AccessEnabler 1.7)

Une autre fonctionnalité liée au stockage incluse dans AccessEnabler 1.7 permet d’importer des jetons d’authentification à partir de zones de stockage plus anciennes. Cet « importateur de jetons » permet d’obtenir la compatibilité entre les versions consécutives d’AccessEnabler, en maintenant l’état SSO même lorsque la version de stockage est mise à niveau. L’importateur est exécuté pendant le flux de setRequestor() 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 aucune modification du code dans l’application cliente.

Assainisseur de jetons (AccessEnabler 1.7.5)

À partir de la version 1.7.5 d’AccessEnabler, ce service s’exécute sur setRequestor(). . Il a été développé à la suite du changement d’iOS 7, qui fait passer l’adresse WiFi MAC à l’IDFA pour le suivi. L’assainisseur garantit que le stockage actuel contient uniquement des jetons d’authentification valides (valides en termes d’ID d’appareil, précédemment calculé à l’aide de l’adresse MAC, avant iOS7). L’assainisseur de jetons supprime tous les jetons non valides.

Le service Assainisseur de jetons est particulièrement utile lorsqu’une application AccessEnabler 1.7.5 est utilisée sur iOS 6, puis que l’utilisateur ou l’utilisatrice effectue une mise à jour vers iOS 7. Dans ce cas, tous les jetons d’authentification obtenus sur iOS 6 ne sont plus valides (en raison du changement d’algorithme de l’ID d’appareil, qui passe de l’utilisation de l’adresse MAC à l’IDFA). L’assainisseur efface tous les jetons non valides et l’utilisateur n’est alors pas authentifié.

Si l’assainisseur de jetons ne supprime pas les jetons non valides, AccessEnabler ne parviendra 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 pas trop aider à déterminer ce qui a provoqué le problème.

Format format

Notez que le format des jetons AuthN et AuthZ est inclus ici à titre d’information uniquement. La structure de ces jetons peut être modifiée à tout moment par l’authentification Adobe Pass. Les programmeurs n’ont pas besoin de connaître la structure exacte des jetons AuthN et AuthZ pour implémenter leurs applications, car les jetons AuthN et AuthZ ne sont pas exposés sur l’appareil local. Le jeton de média court is est 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 multimédia court short_token

La liste ci-dessous présente le format du jeton de média court. Ce jeton est exposé à l’application du programmeur. Il est transmis à l’application du programmeur à la fin d’un processus d’octroi de droits 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 l’appareil device_binding

Dans les listes XML ci-dessus, notez la balise intitulée simpleTokenFingerprint. Cette balise est destinée à contenir des informations d’individualisation de l’identifiant de l’appareil natif. 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 tous les appareils.

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

Remarque sur la liaison d’appareil dans AccessEnabler 1.7.5: À partir d’AccessEnabler 1.7.5, la façon dont l’ID d’appareil est calculé pour fournir des informations d’individualisation pour un appareil iOS a changé. Cette modification reflète un changement dans iOS 7 : à partir d’iOS 7, Apple ne fournit plus l’adresse MAC WiFi comme option de tracking, 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 reposent sur l’IDFA et que ces informations sont intégrées aux jetons de flux de droits, cela signifie que cette modification peut avoir plusieurs effets différents sur l’expérience utilisateur. Les différents effets possibles dépendent de la version d’iOS à partir de laquelle l’utilisateur effectue la mise à niveau, associée à la version d’AccessEnabler à partir de laquelle le programmeur effectue la mise à niveau. Pour plus d’informations sur cette modification, consultez les notes de mise à jour incluses dans AccessEnabler SDK 1.7.5.