Flux de droits du programmeur prog-entitlement-flow

Vue d’ensemble overview

Ce document décrit le flux de droits de base du point de vue du programmeur. Pour plus d’informations sur les fonctionnalités et les cas d’utilisation au-delà de l’intégration de base de TVE, voir Cas d’utilisation de programmeur.

L’authentification Adobe Pass facilite le flux de droits entre les programmeurs et les MVPD en fournissant des interfaces sécurisées et cohérentes pour les deux parties. Du côté du programmeur, l’authentification Adobe Pass fournit deux types généraux d’interface de droits :

Outre la présentation sans plateforme présentée ici, vous trouverez une présentation spécifique à l’API sans client ici : Documentation sur l’API sans client. AccessEnabler s’exécute en mode natif sur les plateformes prises en charge (AS/JS sur le Web, Objective-C sur iOS et Java sur Android). Les API AccessEnabler sont cohérentes entre les plateformes prises en charge. Toutes les plateformes qui ne prennent pas en charge AccessEnabler utilisent la même API sans client.

Pour les deux types d’interface, l’authentification Adobe Pass permet de arbitrer en toute sécurité le flux de droits entre l’application du programmeur et le MVPD de l’utilisateur :

Figure : Écosystème d’authentification Adobe Pass

Flux de droits entitlement-flow

Quatre sous-flux distincts constituent les droits de base.
flow :

Lors de la première visite d’un utilisateur sur le site d’un programmeur, le flux de droits se poursuit dans l’ordre ci-dessus. Cependant, lors de visites ultérieures, selon que les jetons d’authentification et d’autorisation ont expiré ou non, ou selon les stratégies d’affichage, un utilisateur peut uniquement passer par un ou deux des sous-flux.

Flux de démarrage startup

Établit l’identité du programmeur et de l’appareil, effectue des tâches d’initialisation. Il s’agit d’une condition préalable à tous les appels de droits suivants.

AccessEnabler

API sans client

Flux d’authentification authentication

Une authentification réussie génère un jeton AuthN lié à l’appareil et au demandeur. Une authentification réussie est un prérequis pour l’autorisation.

AccessEnabler

API sans client

Un jeton AuthN est considéré comme valide si les deux points suivants sont vrais :

Processus d’authentification initiale d’AccessEnabler générique generic-ae-initial-authn-flow

Flux d’autorisation authorization

L’autorisation est un prérequis pour l’affichage de contenu protégé. Une autorisation réussie génère un jeton AuthZ, ainsi qu’un jeton multimédia de courte durée fourni à l’application du programmeur à des fins de sécurité. Notez que, pour prendre en charge le workflow d’autorisation, vous devez avoir préalablement effectué la configuration du demandeur nécessaire et avoir intégré le Vérificateur de jeton multimédia. Une fois ces tâches terminées, vous pouvez lancer l’autorisation.

Votre application lance une autorisation lorsqu’un utilisateur demande l’accès à une ressource protégée. Vous transmettez un ID de ressource spécifiant la ressource demandée (par exemple, un canal, un épisode, etc.). Votre application commence par rechercher un jeton d’authentification stocké. Si l’un d’eux est introuvable, vous lancez le processus d’authentification.

AccessEnabler

Vous fournissez les fonctions de rappel suivantes pour gérer les résultats de
l’appel d’autorisation :

API sans client

Workflow d’autorisation d’AccessEnabler générique generic-ae-authr-wf

Flux de connexion logout

Efface les jetons et autres données associés au flux de droits de l’utilisateur actuel.

AccessEnabler

API sans client

Comprendre le comportement d’AccessEnabler ae-behavior

Tous les appels de l’API AccessEnabler sont asynchrones (à une exception près, indiqués dans les références de l’API). Vous pouvez appeler une API un nombre arbitraire de fois, mais il n’existe aucune garantie forte que les actions déclenchées
par les appels seront effectués dans l’ordre dans lequel les appels ont été effectués. (Une exception à cette règle est l’exécution du Flash Player en cours ; si le mode multithread n’est pas activé, les appels do sont terminés dans l’ordre.
ils sont appelés.)

Afin de faire la distinction entre les réponses et de pouvoir associer des réponses à des appels, tous les rappels reviennent sur leurs paramètres d’entrée. Cela inclut setToken() et tokenRequestFailed(), qui sont déclenchés en fin de compte par checkAuthorization(). (Pour les rappels checkAuthorization(), la ressource utilisée fait écho.) En tirant parti de cette fonctionnalité, vous pouvez distinguer la réponse qui correspond à l’appel . Pour utiliser cette fonctionnalité, vous pouvez coder quelque chose comme ceci :

    for each (resource in ["TNT", "CNN", "TBS", "AdultSwim"] ) {
         ae.checkAuthorization(resource);
    }

    // Success callback
    function setToken(resource, token) {
         // Use "resource" to figure
         // out which checkAuthorization
         // call triggered this response
    }

    // Old error callback
    function tokenRequestFailed(resource, error, details) {
         // use "resource" to figure
         // out in response to which
         // checkAuthorization call
         // this was triggered
    }

    // Error callback using new error api
    ae.bind("errorEvent',"errorHandler");

    function errorHandler(error) {
         if(error.resource) {
              // Use error.resource to figure
              // which checkAuthorization call
              // triggered this response
         }
    }

FAQ sur le comportement d’AEM ae-beh-faq

Question. Que se passe-t-il si je lance un deuxième appel AccessEnabler avant que le premier appel ne se termine ?

Le premier appel continue de s’exécuter pendant l’exécution du second appel (communications asynchrones).

Question. Y a-t-il un nombre maximum d'appels simultanés qu'AccessEnabler peut prendre en charge ?

Aucune limite n’est explicitement définie dans le code AccessEnabler. Par conséquent, vous êtes limité uniquement par vos ressources système disponibles, ainsi que par la capacité du MVPD.