Présentation du SDK Android android-sdk-overview

Introduction intro

Android AccessEnabler est une bibliothèque Java Android qui permet aux applications mobiles d’utiliser l’authentification Adobe Pass pour les services de droits de TV Everywhere. Une implémentation Android se compose de l’interface AccessEnabler qui définit l’API de droits, ainsi que d’un protocole EntitlementDelegate qui décrit les rappels déclenchés par la bibliothèque. L’interface avec le protocole est désignée sous un nom commun : la bibliothèque Android AccessEnabler.

Conditions requises pour Android reqs

Pour connaître les exigences techniques actuelles relatives à la plateforme Android et à l’authentification Adobe Pass, voir Configuration requise pour la plateforme/périphérique/outilou consulter les notes de mise à jour incluses avec le téléchargement du SDK Android.

Présentation des processus client natifs native_client_workflows

Les workflows clients natifs sont généralement identiques à ceux des clients Adobe Pass Authentication basés sur un navigateur, ou très similaires. 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 les clients natifs (Android, par exemple), après votre premier appel à setRequestor(), vous avez la possibilité de procéder comme suit :

C’est à vous de décider d’attendre ou non la notification du succès de setRequestor() ou de 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 le processus client natif suivant diffère 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, les déconnexions sont gérées de la même manière que le processus d’authentification décrit ci-dessus. Suivant ce modèle, AccessEnabler ouvre les onglets personnalisés de Chrome et charge l’URL du point de terminaison de fermeture de session sur le serveur principal.

Remarque : La déconnexion d’une session Programmer/MVPD effacera le stockage sous-jacent pour ce MVPD spécifique, y compris tous les autres jetons d’authentification du programmeur obtenus par SSO sur cet appareil. Les jetons obtenus pour d’autres MVPD ou non par SSO ne seront pas supprimés.

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 l’appareil Android du client.

La durée de vie des jetons est limitée. Lors de l’expiration, les jetons doivent être réémis en réinitialisant les 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. D’un point de vue purement ingénieur, la bibliothèque Android AccessEnabler traite des problèmes de partage de données entre applications en stockant les données de jeton dans un fichier de base de données situé sur un stockage externe. 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 :

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

REMARQUE : La déconnexion d’une session Programmer/MVPD effacera le stockage sous-jacent, y compris tous les autres jetons d’authentification Programmer sur l’appareil avec SSO. Les jetons obtenus pour d’autres MVPD ou non par SSO ne seront pas supprimés. Annuler le flux d’authentification (appel setSelectedProvider(null)) N’effacera PAS le stockage sous-jacent, mais affectera uniquement la tentative d’authentification programmeur/MVPD actuelle (en effaçant le MVPD pour le programmeur actuel).

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.

Format format

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

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.