ドキュメントAdobe PassAdobe Pass 認証

プログラマー向けの概要 programmers-overview

Last update: Wed Sep 27 2023 00:00:00 GMT+0000 (Coordinated Universal Time)
NOTE
このページのコンテンツは、情報提供の目的でのみ提供されます。 この API を使用するには、Adobeの現在のライセンスが必要です。 不正な使用は許可されていません。

はじめに introduction

この概要は、Adobe® Pass を Web サイトやアプリケーションに統合する予定のコンテンツプロバイダー（プログラマー）向けです。 キックスタートおよび統合ガイドを含む追加のドキュメントについては、以下の関連情報を参照してください。

今日、視聴者はいつでもどこでもインターネットを利用でき、保護されたコンテンツへのアクセスを、あなた、プログラマーから直接要求できます。 1 回限りのイベントを見たいと思ったり、テレビシリーズ全体に対して視聴権を求めていたりする場合もあります。

ただし、保護されたコンテンツへのアクセスを許可する前に、お客様がそのコンテンツを表示する権利があるかどうかを判断する必要があります。 マルチチャネルビデオプログラミングディストリビュータ (MVPD) のサブスクリプションを持っていますか？ その場合、そのサブスクリプションにあなたのプログラミングが含まれていますか。

ビューアの使用権限の決定は、プログラマーにとって必ずしも簡単ではありません。 MVPD は、顧客の識別データとアクセス権限を保持します。 保護されたコンテンツにアクセスしようとする視聴者は、それぞれ異なるシステムを持つ様々な MVPD に登録するので、保護されたコンテンツに対する閲覧者の資格を決定すると、すぐに複雑で技術的に困難になる可能性があります。

図：プログラマーが直接決定したユーザーエンタイトルメント

Adobe Pass Authentication for TV Everywhere は、Programmers と MVPDs の間のこれらの権利付与トランザクションを安全に仲介します。 Adobe Pass認証を使用すると、プログラマーが保護されたコンテンツを有効なお客様に提供するのを、簡単、迅速、安全におこなうことができます。

図：Adobe Pass Authentication を介したユーザーエンタイトルメント

Adobe Pass認証は、参加している MVPD との交換の代わりに機能するので、一貫したクロスサイトインターフェイスを使用してビューアを表示できます。 また、Adobe Pass認証を使用すると、シングルサインオン (SSO) の認証と承認を閲覧者に提供することもできます。 認証と承認は、参加しているすべてのサービスに対して追跡されるので、加入者は、自身のシステムで最初の認証を行った後に再度ログインする必要はありません。

  • 認証 — 特定のユーザーが既知の顧客であることを MVPD で確認するプロセス。
  • 認証 — 認証済みユーザーが指定されたリソースに対して有効なサブスクリプションを持っていることを MVPD で確認するプロセス。

Adobe Pass認証の仕組み HowItWorks

プログラマのコンテンツ表示アプリケーションは、Access Enabler クライアントコンポーネントまたは Clientless API の RESTful Web サービス（スマート TV、ゲームコンソール、セットトップボックスなどの非 Web 対応デバイス用）を使用してAdobe Pass認証とやり取りします。 Access Enabler は、ユーザーのシステム上で実行され、すべての権限付与ワークフローを容易にします。 Access Enabler コンポーネントは、お客様がサイトにアクセスし、保護されたコンテンツを要求したときに、Adobeのホスティングサイトからダウンロードされます。 Adobe Pass認証サーバーは、クライアントレスソリューションで使用される RESTful Web サービスをホストします。

Adobe Pass認証は、実際の権限付与ワークフローを処理しながら、次の目的で使用するプリミティブを提供します。

  • ID を設定します。 ( プログラマーは、Adobe Pass Authentication エンタイトルメントフローの「要求者」です )。
  • 特定の MVPD でユーザーを認証します。 (MVPD は、Adobe Pass Authentication エンタイトルメントフローの「ID プロバイダー」または「IdP」です )。
  • 特定のリソースに対して MVPD を使用してユーザーを認証します。
  • ユーザーをログアウトします。

プログラマーは、次の処理を行う上位レベルの Web ページまたはプレーヤーアプリケーションを担当します。

  • ユーザーインターフェイスを実装します
  • Access Enabler またはクライアントレス API Web サービスとやり取りする

Adobe Pass Authentication の目的は、権利付与の検証を処理するための、プログラマーと MVPD の両方のためのシンプルなモジュラー方法を作成することです。

トークンについて understanding-tokens

Adobe Pass Authentication Entitlement Solution では、認証および承認ワークフローが正常に完了すると作成される特定のデータの生成が中心となります。 これらのデータはトークンと呼ばれます。 トークンの有効期限は限られています。トークンが期限切れになったら、認証および承認ワークフローの再開を通じてトークンを再発行する必要があります。

トークンについて詳しくは、次の節を参照してください。

トークンのタイプ token-types

認証および承認ワークフローでは、3 種類のトークンが発行されます。 AuthN および AuthZ トークンは「長期間有効」で、ユーザーの表示エクスペリエンスの継続性を提供します。 メディアトークンは、ストリームリッピングを通じた不正を防ぐための業界のベストプラクティスのサポートを提供する、短時間有効なトークンです。 プログラマは、MVPDs との合意に基づいて、トークンの各タイプの有効期間 (TTL) 値を指定します。 プログラマーは、自社のビジネスと顧客に最適な TTL 値を決定します。

  • AuthN トークン （「長期間有効」）：認証が成功すると、Adobe Pass認証は、リクエストデバイスとグローバル一意識別子 (GUID) の両方に関連付けられた AuthN トークンを作成します。

    • Adobe Pass認証は、AuthN トークンを Access Enabler に送信し、AuthN トークンをクライアントのシステム上で安全にキャッシュします。 AuthN トークンは存在し期限切れではありませんが、Adobe Pass認証を使用するすべてのアプリケーションで使用できます。 Access Enabler は、認証フローに AuthN トークンを使用します。
    • いつでも 1 つの AuthN トークンのみがキャッシュされます。 新しい AuthN トークンが発行され、古い AuthN トークンが既に存在する場合は常に、Adobe Pass Authentication はキャッシュされたトークンを上書きします。

  • AuthZ トークン （「長期間有効」）：認証が成功すると、Adobe Pass認証は、リクエストデバイスと特定の保護されたリソースに関連付けられた AuthZ トークンを作成します。 保護されたリソースは、一意のリソース ID で識別されます。

    • Adobe Pass認証は、AuthZ トークンを Access Enabler に送信し、AuthZ トークンをローカルシステム上に安全にキャッシュします。 次に、Access Enabler は AuthZ トークンを使用して、実際の表示アクセスに使用される短時間のみ有効なメディアトークンを作成します。
    • いつでも、1 つのリソースにつき 1 つの AuthZ トークンのみがキャッシュされます。 Adobe Pass認証では、異なるリソースに関連付けられている限り、複数の AuthZ トークンをキャッシュできます。 新しい AuthZ トークンが発行され、同じリソースに対して既に古い AuthZ トークンが存在する場合は常に、Adobe Pass Authentication はキャッシュされたトークンを上書きします。

  • メディアトークン ("Short-Lived"):Access Enabler は、AuthZ トークンを使用して、短時間有効（デフォルト：7 分）のメディアトークンを生成します。 これは、再生リクエストが成功したと見なされるポイントです。

    • 保護されたリソースへのアクセスを提供する前に、メディアサーバーは、Adobe Pass認証コンポーネントであるメディアトークン検証ツールを使用して、メディアトークンを検証する必要があります。
    • メディアトークンはデバイスにバインドされていないので、その寿命は、長期間有効な AuthN および AuthZ トークンよりも大幅に短くなります（デフォルトは 7 分）。
    • 短時間のみ有効なメディアトークンは、1 回限りの使用に制限され、キャッシュされません。 認証 API は、認証 API が呼び出されるたびに、Adobe Pass Authentication サーバーから取得されます。

トークンストレージ token-storage

Access Enabler は、環境に固有の場所に、長期間有効なトークン（AuthN と AuthZ）を保存します。

  • FLASH10.1 （またはそれ以降）：長期間有効なトークンは、ローカル共有オブジェクトとして保存されます。
  • HTML5：長期間有効なトークンは、HTML5 ブラウザーのローカルストアに安全に保持されます。
  • iOS：長期間有効なトークンは、永続的なペーストボードに保存され、他のAdobe Pass Authentication クライアントアプリケーションからアクセスできます。
  • Android：長期間有効なトークンは共有データベースファイルに保存され、他のAdobe Pass Authentication クライアントアプリケーションからアクセスできます。
  • クライアントレス API デバイス：トークンはAdobe Pass Authentication サーバーに保存されます。

トークンセキュリティ token-security

Adobe Pass Authentication Server は、（デバイスのハードウェア特性から派生した）デバイス ID を使用して、長期間有効なすべてのトークンにデジタル署名を行います。 電子署名は、環境に応じて、生成、保護、検証の方法が異なります。

  • FLASH10.1 （またはそれ以上） — デバイス ID は、デバイスの資格情報に依存します。これは、デバイスの個別化サーバーから発行された一意のAdobeです。 このセキュリティは、FAXS DRM テクノロジーと同等です。 このサーバー側の検証では、トークン内の一意のデバイス ID とデバイスの資格情報 (Flash PlayerからAdobe Pass認証に安全に通信 ) を比較します。 また、デバイスの秘密鍵証明書は、FAXS クライアントのバージョンと、その発行先のFlash Player( またはAIR) のバージョンも識別します。 HTMLのバインディングはデバイス 5 よりも強いので、トークンの有効期間 (TTL) は通常、Flashの方が長くなります。
  • HTML5 — デバイスはクライアント側で個別化されます。 JavaScript で使用可能な特性を使用して、ブラウザーと OS のバージョン、IP アドレス、ブラウザーの Cookie GUID（グローバルに一意の識別子）を含む擬似デバイス ID を作成します。 このトークンデバイス ID を、デバイスの現在の擬似デバイス ID と比較する。 IP アドレスは同じセッションでも通常の使用中に変更される可能性があるので、Adobe Pass認証では、localStorage と sessionStorage の 2 つの場所にHTML5 トークンを保存します。 IP が変更され、sessionStorage トークンが有効でない場合、セッションは維持されます。 HTML5 では、デバイスのバインディングがそれほど強くないので、トークンの TTL は通常、Flashの TTL よりも短くなります。
  • ネイティブクライアント (iOSおよび Android) — 長期間有効なトークンは、ネイティブデバイス ID の個別化情報を保持するので、要求元のデバイスに結び付けられます。 認証要求と認証要求は HTTPS 経由で送信され、デバイス ID 情報は、バックエンドサーバに送信する前に Access Enabler ライブラリによってデジタル署名されます。 サーバー側では、デバイス ID 情報は、関連するデジタル署名に対して検証されます。
  • クライアントレス API クライアント — クライアントレス API ソリューションは、すべての API 呼び出しにデジタル署名を含む一連のセキュリティプロトコルを備えています。 権限付与フロー中に生成されたトークンは、Adobe Pass Authentication Server に安全に保存されます。

Adobe Pass認証では、長時間有効な各トークンが検証され、コンテンツにアクセスするデバイスがトークンの発行元と同じであることが確認されます。 すべてのトークンについて、クライアント側の検証では、デジタル署名が損なわれず、トークンの整合性が維持されていることを確認します。 デバイス ID の検証が失敗すると、認証セッションは無効になり、再度ログインするよう求められ、トークンがリセットされます。

トークン共有 token-sharing

異なるプラットフォーム上のアプリケーションはトークンを共有しません。 これには、次のような様々な理由があります。

  • 詳しくは、 トークンストレージの場合、トークンの保存方法はプラットフォーム (Flash用のローカル共有オブジェクト、JavaScript 版の WebStorage など ) によって異なります。
  • トークンのセキュリティの程度は、プラットフォームによって異なります。 たとえば、Flashトークンは、FAXS を使用するデバイスに強く結び付けられます。 純粋な JavaScript 環境のトークンは、Flashと同じレベルの DRM サポートを持ちません。 JS トークンをFlashアプリケーションと共有すると、より安全な環境を利用して、より安全なトークンを少なくする可能性が高まります。

プログラマー統合ライフサイクル prog-integ-lifecycle

図：認証とプログラマーの Web サイトおよびアプリケーションとの統合

論理フロー logical-flows

権利フローチャート chart

次のフローチャートに、(Adobe Pass Authentication Access Enabler クライアントコンポーネントを使用した ) 使用権限の確認の全体的なプロセスを示します。

図：使用権限の確認プロセス

認証手順 authn-steps

次の手順は、Adobe Pass認証フローの例を示しています。 これは、プログラマーがユーザーが MVPD の有効な顧客かどうかを判断するエンタイトルメントプロセスの一部です。 このシナリオでは、ユーザーは MVPD の有効な購読者です。 ユーザーは、次のプログラマーのアプリケーションを使用して、保護されたコンテンツを表示しようとしています。Flash:

  1. ユーザーがプログラマーの Web ページを参照し、プログラマーのFlashアプリケーションとAdobe Pass Authentication Access Enabler コンポーネントをユーザーのマシンに読み込みます。 Flashアプリケーションは、Access Enabler を使用してAdobe Pass Authentication でプログラマーの識別子を設定し、Adobe Pass Authentication は、そのプログラマー (「requestor」) の構成と状態データを使用して Access Enabler を設定します。 他の API 呼び出しを実行する前に、Access Enabler がサーバからこのデータを受け取る必要があります。 技術メモ：プログラマは、Access Enabler の setRequestor() メソッド。詳しくは、 プログラマー統合ガイド.
  2. ユーザがプログラマの保護されたコンテンツを表示しようとすると、プログラマのアプリケーションは、ユーザに MVPD のリストを提示し、そこからプロバイダを選択する。
  3. ユーザーは、Adobe Pass認証サーバーにリダイレクトされ、暗号化された SAML ユーザーが選択した MVPD に対するリクエストが作成されます。 このリクエストは、プログラマーに代わって認証リクエストとして MVPD に送信されます。 MVPD のシステムに応じて、ユーザーのブラウザが MVPD のサイトにリダイレクトされてログインするか、プログラマーのアプリでログイン iFrame が作成されます。
  4. どちらの場合も（redirect または iFrame）、MVPD はリクエストを受け入れ、そのログインページを表示します。
  5. ユーザーが MVPD を使用してログインすると、MVPD はユーザーの有料顧客としてのステータスを検証し、MVPD は独自の HTTP セッションを作成します。
  6. ユーザーが検証されると、MVPD は応答（SAML および暗号化）を作成し、MVPD はAdobe Pass Authentication に返します。
  7. Adobe Pass認証は MVPD 応答を受け取り、Adobe Pass認証 HTTP セッションが開いていることを確認し、MVPD からの SAML 応答を検証し、プログラマーのサイトにリダイレクトします。
  8. プログラマのサイトが再読み込みされ、Access Enabler が再読み込みされ、プログラマが setRequestor() を再度呼び出します。 現在の構成が変更されたので、setRequestor() の 2 回目の呼び出しが必要です。AuthN トークンがサーバ上で生成されるのを待っていることを Access Enabler に通知するフラグが存在します。
  9. Access Enabler は、保留中の認証があることを確認し、Adobe Pass Authentication Server にトークンを要求します。 トークンは、サーバーの DRM 機能を呼び出すことでFlash Playerから取得されます。
  10. AuthN トークンは、プログラマーのFlash PlayerLSO キャッシュに格納されます。認証が完了し、セッションはAdobe Pass認証サーバーで破棄されます。

認証手順 authz-steps

以下の手順は、 認証手順:

  1. ユーザーがプログラマーの保護されたコンテンツにアクセスしようとすると、プログラマーのアプリケーションは、まず、ユーザーのローカルマシンまたはデバイス上の AuthN トークンを確認します。 そのトークンがない場合、 認証手順 上に続く。 AuthN トークンが存在する場合、認証フローは、保護されたコンテンツの特定の項目に対するユーザーの表示権限を取得する要求を受けて、プログラマーのアプリケーションが Access Enabler への呼び出しを開始すると進みます。
  2. 保護されたコンテンツの特定の項目は、「リソース識別子」で表されます。 これは単純な文字列か、より複雑な構造になるかもしれませんが、どの場合でも、リソース識別子の性質はプログラマーと MVPD の間で事前に合意されます。 プログラマのアプリケーションは、リソース識別子を Access Enabler に渡します。 Access Enabler は、ユーザーのローカルマシンまたはデバイス上で AuthZ トークンを確認します。 AuthZ トークンがない場合、Access Enabler はリクエストをバックエンドのAdobe Pass Authentication Server に渡します。
  3. Adobe Pass認証サーバーは、標準化されたプロトコルを使用して MVPD 承認エンドポイントと通信します。 MVPD の応答が、ユーザーが保護されたコンテンツを表示する権限を持っていることを示している場合、Adobe Pass認証サーバーは AuthZ トークンを作成し、AuthZ トークンを Access Enabler に渡します。AuthZ トークンはユーザーのマシンに保存されます。
  4. AuthZ トークンがユーザーのマシンまたはデバイスに保存されている場合、プログラマーのアプリケーションは Access Enabler を呼び出してAdobe Pass認証サーバからメディアトークンを取得し、そのトークンをプログラマーのアプリケーションに提供します。
  5. 最後に、プログラマーのアプリケーションは、メディアトークン検証コンポーネントを使用して、適切なユーザーが適切なコンテンツを表示していることを確認し、メディアトークンを設定した状態で、保護されたコンテンツを表示できます。

登録と初期化 reg-and-init

Adobe Pass Authentication を使用する際の最初の手順は、Adobeに登録するか、Adobe Pass認証を許可されたパートナーと登録することです。

登録時に、Adobe Pass認証との通信に使用するドメインのリストを指定します。 例えば、Turner Broadcasting System ドメインには、 tbs.comおよび tnt.tv が含まれ、Adobe Pass Authentication が登録したドメインとして扱われます。 これらの各コンテンツサイトには、Adobe Pass認証へのアクセス権が付与され、独自の要求者 ID（例：「TBS」、「TNT」）が割り当てられます。 サイトを追加する場合は、許可されたドメインのリストに追加し、要求者 ID を追加するために、追加のドメイン名をAdobeに通知する必要があります。

WARNING
統合をテストする際は、実稼動環境で使用する登録済みのドメインにテストサーバーが存在することを確認してください。 ホワイトリストに登録されていないドメインからのリクエストも、テストリクエストも無視されます。 例えば、実稼動環境でのdomain.comの使用をリクエストした場合は、domain.com、test.domain.com、staging.domain.comの下にテスト統合をデプロイしていることを確認してください。
ドメインがホワイトリストに登録されている場合でも、URL にユーザー名と/またはパスワードを含む要求は無視されます。 例： //username@registered-domain/

リクエスト元 ID は、Adobe Pass Authentication の Access Enabler クライアントコンポーネントとのすべての通信で、プログラマーのクライアントを一意に識別します。 プログラマーに関連付けられているすべてのAdobe Pass Authentication 静的データは、この ID にキーが設定されます。

TIP
リクエスト元 ID に加え、登録時に、Access Enabler クライアントコンポーネントとメディアトークン検証機能の機能 URL も受け取ります。

統合手順 integration-steps

TIP
AdobeのOpen Source Media Framework(「OSMF」) をメディアプレーヤーの開発に使用している場合、Adobe Pass認証を最もすばやく使用するには、OSMF プラグインを統合する必要があります （廃止） をプレーヤーのコードに追加します。
  1. 依頼者の設定
  2. 認証と承認の処理
  3. シングルログアウトのサポート

1.リクエスト元の設定 requestor

1a. 登録Adobe

最初の手順は、AdobeまたはAdobe Pass Authentication 認証承認済みパートナーに登録することです。 登録時に、1 つ以上のグローバル一意の ID(GUID) が発行されます。 発行された各 GUID は、Adobe Pass Authentication へのアクセスが許可されるドメインに関連付けられています。 Access Enabler とやり取りする各セッションの ID を登録するには、リクエストドメインの GUID（リクエスト元 ID と呼ばれる）を渡します。 詳しくは、 登録と初期化 (「Programmer Integration Guide」) を参照してください。

1b. 初期アクセスイネーブラの統合

次の手順では、Access Enabler を既存のメディアプレーヤーアプリケーションまたは Web ページに統合します。

  • 埋め込み可能なFlashバージョン AccessEnabler.swf、Flashベースのビデオプレーヤーで埋め込むことも、Web ページのHTMLに直接埋め込むこともできます。 Access EnablerSWFとは、ActionScriptまたは JavaScript で通信できます。 ベース API はActionScriptですが、JavaScript を使用したい場合は、完全なラッパーライブラリをページに組み込むことができます。

  • 非Flash環境では、次の操作が可能です。

    • HTML5/JavaScript バージョンの AccessEnabler.js を使用し、JavaScript API を使用して通信します。
    • AIR Native Extension for Adobe Pass Authentication を使用して、ネイティブコードと組み込みのActionScriptクラスを組み合わせる
    • Access Enabler ライブラリ (iOSまたは Android) のネイティブ・クライアント・バージョンの 1 つを使用する

2.認証・承認への対応 authn-authz

2a. Access Enabler との通信

Access Enabler と Web ページまたはプレーヤーアプリとの間の通信は非同期的に行われます。 アプリケーションが Access Enabler メソッドを呼び出し、Access Enabler は、Access Enabler ライブラリに登録したコールバックを介して応答します。

  • 有効な AuthN トークンがローカル・システム上に存在しない場合は、アプリケーションが認証要求を行うと、Access Enabler は自動的に認証要求を開始します。 認証が成功すると、ユーザーの AuthN トークンがローカルに保存されるので、再度ログインする必要はありません。 MVPD Web サイトや別のプログラマーを使用して、Adobe Pass認証を通じて正常に認証された場合、Access Enabler はローカル AuthN トークンにアクセスでき、追加の認証は不要です。
  • ユーザーが保護されたコンテンツにアクセスしようとすると、Access Enabler に認証要求が送信されます。 認証を検証（または開始）した後、Access Enabler は (Adobe Pass Authentication サーバを介して )MVPD にアクセスし、お客様が保護されたコンテンツを表示する資格があるかどうかを判断します。 アプリケーションは、要求を Access Enabler に送信し、応答（認証の成功または失敗）を処理するだけで済みます。 認証に成功した場合、AuthZ トークンはクライアントシステムに保存されます。 最後に、アプリケーションは、独自の認証手順で使用する短時間のみ有効なメディアトークンを受け取ります。
NOTE

  • 認証は、サービスプロバイダー (SP) としてのAdobe Pass Authentication と ID プロバイダー (IdP) としての MVPD との間の SAML 交換としておこなわれます。

  • 認証では、Adobe Pass Authentication(SP) と MVPD(IdP) との間のバックチャネル（サーバー間）Web サービス交換が使用されます。

2b. 権限付与ユーザーインターフェイスの指定 entitlement-ui

コンテンツにユーザーがアクセスできるように、独自の UI を提供します。 実際のログインプロセスなどの一部の要素は MVPD によって提供され、一部の要素はAdobe Pass認証の一部としてオプションで使用できます。 少なくとも、次の操作を実行します。

  • 新しいユーザが MVPD を識別し、初めてログインできるようにする MVPD 選択インターフェイスを実装します。. 開発の際に、Access Enabler は、お客様に MVPD を選択してログイン処理を開始する基本的なユーザー・インタフェースを提供します。 実稼動環境の場合は、独自の MVPD セレクターダイアログを実装する必要があります。 一部の MVPD は、ログイン用に独自のサイトにリダイレクトし、iFrame 内にログインページを表示する必要があります。 ユーザーの MVPD が iFrame でログインページを表示する場合に対処するには、この iFrame を作成するコールバックを実装する必要があります。
  • 保護されたコンテンツの識別. 保護されたコンテンツにはアクセスの認証が必要です。 インターフェイスに、保護されるコンテンツと、承認されたコンテンツを示す必要があります。 認証ステータスは、多くの場合、「ロック解除済み」アイコンと「ロック済み」アイコンで示されます。
  • ユーザーが認証されたことを表示. 保護されたコンテンツの識別に使用する方法の一部として、ユーザーの認証ステータスを指定する必要があります。 Access Enabler を照会して、お客様が既に認証済みかどうかを判断できます。

2c. メディアトークン検証ツールの統合 int-media-token-ver

Adobe Pass Authentication Media Token Verifier コンポーネントをメディアサーバーに統合する必要があります。 これにより、既存のトークン検証者が、Adobe Pass Authentication から提供される短時間のみ有効なメディアトークンを正常な認証で認識できるようになります。 メディアトークン検証ツールは、保護されたコンテンツへのユーザーアクセスを提供する前に、メディアトークンを最後のセキュリティ手順として検証します。 Adobeの登録時に、メディアトークン検証ツールをダウンロードする場所を受け取ります。

3.シングルログアウトのサポート ssl

ほとんどの場合、メディアプレーヤーは、シンプルな Access Enabler API を使用してユーザーのログアウトを処理します。 logout() を呼び出すと、Access Enabler は次の処理を実行します。

  • 現在のユーザーをログアウトします。
  • ログアウトしたユーザーの認証情報と認証情報をすべてクリアします。
  • ユーザーのローカルシステムからすべての AuthN および AuthZ トークンを削除します

ユーザーがトークンの期限が切れるまでマシンをアイドル状態のままにしておくと、ユーザーはセッションに戻り、ログアウトを正常に開始できます。 Adobe Pass認証は、すべてのトークンが確実に削除され、セッションも削除するよう MVPD に通知します。

Adobe Pass Authentication と統合されていないサイトからログアウトが開始された場合、MVPD は、ブラウザーのリダイレクトを通じてAdobe Pass Authentication Single Logout サービスを呼び出すことができます。

ユーザー ID について user-ids

概念上、エンタイトルメントフローを開始する各ユーザーは、1 つの一意なユーザー ID に関連付けられます。 ただし、エンタイトルメントフローの過程では、ID の取得元の API に応じて、1 つのユーザー ID を異なる方法で表示できます。

ショートメディアトークンの sessionGUID は、セキュアな形式の UserID で、 sendTrackingData() 呼び出しで使用できます。 現在のすべての統合では、これは、時間とデバイスをまたいでユーザーに対して永続的な GUID ですが、GUID のソースは、MVPD からの SAML 応答で UserID で始まります。 しかし、一部の MVPD は将来的に心を変え、一時的な GUID を送り始める可能性があります。 AuthN 応答の MVPD ソース UserID が永続的であることを確認したい場合、プログラマは MVPDs との合意に基づいてそれを手配する必要があります。

Adobe Pass Authentication API でユーザー ID を表す様々な方法を次に示します。

  • sendTrackingData() GUID プロパティ — MVPD UserID のAdobeでハッシュ化されたバージョンです。 このユーザー ID はハッシュ化されているので、MVPD からソースにこのユーザー ID を追跡できません。 この ID は一意で、通常は永続的ですが、MVPD と共有して、特定の使用動作を MVPD の側にあるものと比較することはできません。 デジタル署名されていないので、不正防止に対してスプーフィックできませんが、分析には十分です。 この形式のユーザー ID は、AuthN/AuthZ フローでAdobe Pass認証が生成するすべてのイベントでクライアント側で提供されます。
  • ショートメディアトークン sessionGUID プロパティ — これは、を介した UserID と同じです。 sendTrackingData()しかし、これは完全性を保護するためにデジタル署名されています。 これにより、同時使用の不正追跡にこの値が十分に役立ちます。 これは、アドビのバリデータライブラリを使用した後にサーバー側で処理されることを目的としており、クライアントにビデオストリームをリリースする前に、不正パターンを分析できます。 これらのタスクを実行するかどうかは、プログラマー次第です。
  • getMetadata() userID property — このプロパティを使用すると、Adobeは実際のソース MVPD UserID をプログラマに公開できます。 プログラマーから取得した証明書の公開鍵で暗号化され、クライアントに対して明確に公開されなくなります。 これにより、プログラマは MVPD から実際の UserID を取得できるので、MVPD と直接アカウントのリンクや不正の調査に使用できます。

まとめ

  • MVPD ユーザー ID は、一般的に、保証されていないが、永続的な一意の ID で、 MVPD から生成され、認証成功時にAdobeに渡される. 一部の例外を除き、通常、この値はすべてのネットワークで一貫しています。
  • MVPD ユーザー ID に PII が含まれておらず、アカウント番号でもありません。 PII が送信されていないすべての MVPD で検証したので、暗号化された形式で公開する必要はありません。

ユーザー ID の使用方法は、使用例によって異なります。

  • トラッキング/分析に必要な場合、最も実用的な場所は、 sendTrackingData().
  • ストリームリリース、不正、または運用データに関してサーバー側で必要な場合は、メディアトークンバリデーターから取得できます。
  • アカウントのリンクとより深い不正に対して必要な場合は、Adobeの担当者に問い合わせて、可用性を確認してください。
recommendation-more-help
3f5e655c-af63-48cc-9769-2b6803cc5f4b