Présentation d’Android SDK (hérité) android-sdk-overview

Introduction intro

Android AccessEnabler est une bibliothèque Android Java qui permet aux applications mobiles d'utiliser l'authentification Adobe Pass pour les services de droits de TV Everywhere. Une implémentation d’Android se compose de l’interface AccessEnabler qui définit l’API de droit et d’un protocole EntitlementDelegate qui décrit 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 Android AccessEnabler.

Conditions requises pour Android reqs

Pour connaître les exigences techniques actuelles relatives à la plateforme Android et à l’authentification Adobe Pass, consultez la section Configuration requise pour la plateforme/l’appareil/l’outil ou consultez les notes de mise à jour accompagnant le téléchargement d’Android SDK.

Présentation des workflows client natifs native_client_workflows

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 les clients natifs (par exemple, Android), après votre appel initial à setRequestor(), vous avez le choix de la manière de procéder :

C’est à vous de décider s’il faut attendre la notification du succès de l’setRequestor() ou compter sur le 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 le workflow du client natif suivant diffère du workflow d’authentification standard basé sur le navigateur, les étapes 1 à 5 sont identiques pour les clients natifs et les clients basés sur le navigateur :

Workflow 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. Selon ce modèle, AccessEnabler ouvre les onglets personnalisés de Chrome et charge l’URL du point d’entrée de déconnexion sur le serveur principal.

Remarque : la déconnexion d’une session de programmation/MVPD sera effacée
le stockage sous-jacent pour ce MVPD spécifique, y compris tous les
autres jetons d’authentification du programmeur obtenus via la connexion unique sur
cet appareil. Les jetons obtenus pour d’autres MVPD ou non par SSO ne le seront pas
être supprimé.

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 Android 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/d’autorisation transparent est ce qui fait de la solution d’authentification Adobe Pass une véritable mise en œuvre de TV-Everywhere. D’un point de vue purement technique, la bibliothèque Android AccessEnabler résout les 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. Ces ressources partagées au niveau du système fournissent 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 :

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

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

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.

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 multimédia court short_media_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.

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