iOS/tvOS SDK の概要 iostvos-sdk-overview

概要 intro

iOS AccessEnabler は、モバイルアプリが TV Everywhere の権利付与サービスにAdobe Pass Authentication を使用できるようにする、Objective C iOS/tvOS ライブラリです。 このインプリメンテーションは、資格 API を定義する AccessEnabler インタフェースと、ライブラリがトリガーするコールバックを記述する EntitlementDelegate および EntitlementStatus プロトコルで構成されます。 プロトコルと共にインタフェースは、共通の名前である AccessEnabler ライブラリの下で参照されます。

iOSと tvOS の要件 reqs

iOS、tvOS プラットフォーム、Adobe Pass認証に関する現在の技術要件については、 プラットフォーム/デバイス/ツールの要件を参照し、SDK ダウンロードに含まれるリリースノートを参照してください。 このページの残りの部分には、特定の SDK バージョン以降に適用される変更に注意が必要な節が表示されます。 例えば、以下は 1.7.5 SDK に関する正当な注意事項です。

ネイティブクライアントワークフローについて flows

ネイティブクライアントワークフローは、通常、ブラウザーベースのAdobe Pass認証クライアントと同じか、非常に似ています。 ただし、以下に説明するように、いくつかの例外があります。

初期化後のワークフロー post-init

AccessEnabler でサポートされるすべての使用権限ワークフローでは、ID を確立するために以前に setRequestor() と呼んだことを前提としています。 この呼び出しを行うと、要求者 ID を 1 回だけ指定できます。通常、アプリケーションの初期化/設定段階で指定します。

iOS ネイティブクライアントの場合、setRequestor() への最初の呼び出しの後、進め方を選択できます。

setRequestor() の成功の通知をアプリで待たせるか、AccessEnabler のコール キューメカニズムに依存させるかを選択できます。 後続のすべての承認および認証リクエストには要求者 ID と関連する設定情報が必要なため、setRequestor() の方法は、初期化が完了するまで、すべての認証および承認 API 呼び出しを効果的にブロックします。

汎用初期認証ワークフロー generic

このワークフローの目的は、MVPD を使用してユーザーにログインすることです。 ログインに成功すると、バックエンドサーバーはユーザーに認証トークンを発行します。 認証は通常、認証プロセスの一部として行われますが、次に認証が単独で機能する方法を説明します。には認証手順は含まれていません。

このワークフローは、ネイティブクライアントと一般的なブラウザーベースの認証ワークフローでは異なりますが、手順 1～5 は、ネイティブクライアントとブラウザーベースのクライアントで同じです。

ログアウトワークフロー logout

ネイティブクライアントの場合、ログアウトは、上記の認証プロセスと同様に処理されます。

ログアウトフローは、認証フローとは異なり、ユーザーは UIWebView/WKWebView or SFSafariViewController ントロールコントローラーとやり取りする必要がありません。 そのため、Adobeはログアウトプロセス中にコントロールを非表示（つまり非表示）にすることをお勧めします。

トークン tokens

定義と使用方法 definitions

Adobe Pass認証使用権限ソリューションでは、認証および承認ワークフローが正常に完了したときにAdobe Pass認証によって生成される特定のデータ（トークン）を生成します。 これらのトークンは、クライアントのiOS デバイス上にローカルで保存されます。

トークンの有効期間は限られています。有効期限が切れた場合は、認証ワークフローまたは承認ワークフローを再開することでトークンを再発行する必要があります。

使用権限ワークフローで発行されるトークンには、次の 3 つのタイプがあります。

認証と承認に成功すると、Adobe Pass Authentication は認証、承認および短時間のみ有効なメディアトークンを発行します。 これらのトークンは、ユーザーのデバイスにキャッシュし、関連する存続期間中に使用する必要があります。

キャッシュガイドライン caching

認証トークン

認証トークン

AccessEnabler によってキャッシュされる認証トークンは、常にリソースごとに 1 つのみです。 複数の認証トークンがキャッシュされている場合がありますが、それらは異なるリソースに関連付けられています。 新しい認証トークンが発行され、古いトークンが 同じリソース に既に存在する場合、新しいトークンは既存のキャッシュ値を上書きします。

メディアトークン

短時間のみ有効なメディアトークンはキャッシュしないでください。 メディアトークンは、1 回限りの使用に制限されているので、認証 API が呼び出されるたびにサーバーから取得する必要があります。

永続性 persistence

トークンは、同じアプリケーションを連続して実行しても永続的である必要があります。 つまり、認証トークンと認証トークンが取得され、ユーザーがアプリケーションを閉じると、ユーザーがアプリケーションを再度開いたときに、同じトークンがアプリケーションで使用できるようになります。 さらに、これらのトークンは、複数のアプリケーションにわたって永続的であることが望ましいです。 つまり、ユーザーが 1 つのアプリケーションを使用して特定の ID プロバイダーでログインした後（認証および認証トークンの取得に成功した場合）、別のアプリケーションを通じて同じトークンを使用でき、同じ ID プロバイダーを介してログインする際に、ユーザーが資格情報を要求されなくなりました。 このタイプのシームレスな認証/承認ワークフローにより、Adobe Pass認証ソリューションは真の TV-Everywhere となっています
実装。

iOS

iOS AccessEnabler ライブラリは、トークン・データを 貼り付けボード と呼ばれる「クリップボードのような」データ構造に保存することで、アプリケーション間のデータ共有の問題を回避します。 このシステムレベルの共有リソースは、目的とする永続的なトークンのユースケースの実装を可能にする主な要素を提供します。

特定のトークンがトークン・キャッシュに配置されると、その有効性は AccessEnabler ライブラリによって異なる時刻にチェックされます。 有効なトークンは次のように定義されます。

tvOS

tvOS ではペーストボードが使用できないため、tvOS AccessEnabler ライブラリは NsUserDefaults をストレージ オプションとして使用します。 これにより、認証トークンと認証トークンを保持する問題が解決されますが、保存された情報は異なるアプリケーション間で共有できません。

iOS 10 ペーストボードの変更点 – 以前のバージョンのiOSからアップグレードすると、ペーストボードが消去されます。 つまり、すべてのアプリケーションを再認証する必要があります。

iOS 7 のペーストボードの変更 – iOS 7 のペーストボードの機能が変更されたので、iOS 7 で実行されているアプリケーション間のクロス SSO は制限されます。 同じ <Bundle Seed ID> （<Team ID> とも呼ばれます）を持つアプリケーションはトークンを共有します。つまり、同じプログラマー X のアプリ A1 と A2 はトークンを共有し、アプリ A1 （プログラマー X）とアプリ A3 （プログラマー Y）はトークンを共有しません。

iOS 7 以降で SSO を構成する方法の詳細については、このテクニカル ノートを参照してください（テクニカル ノートはアクセス イネーブラ v1.8 以降に適用されます）。https://tve.zendesk.com/entries/58233434-Configuring-Pay-TV-pass-SSO-on-iOS

トークン・ストレージ（AccessEnabler 1.7）

AccessEnabler 1.7 以降のトークン・ストレージでは、複数の認証トークンを保持できるマルチレベルのネストされたマップ構造に基づいて、複数の Programmer-MVPD の組み合わせをサポートできます。 この新しいストレージは、AccessEnabler パブリック API に影響を与えず、プログラマ側での変更も必要ありません。 次に例を示します
に、この新しい機能を示します。

以前のバージョンの AccessEnabler では、トークン・ストレージでサポートされていた認証トークンは 1 つのみのため、ステップ 6 ではユーザーが未認証と表示されていました。

1 つのプログラマー/MVPD セッションからログアウトすると、デバイス上の他のすべてのプログラマー/MVPD 認証トークンを含む、基礎となるストレージ全体がクリアされます。 一方、認証フローをキャンセル（setSelectedProvider(null) を呼び出す）しても、基になるストレージはクリアされませんが、現在のプログラマ/MVPD 認証の試行にのみ影響します（現在のプログラマの MVPD を消去することによって）。

トークン インポーター（AccessEnabler 1.7）

AccessEnabler 1.7 に含まれるもう 1 つのストレージ関連機能により、古いストレージ領域から認証トークンをインポートできます。 この「トークン インポーター」は、連続する AccessEnabler のリリース間の互換性を実現し、ストレージ バージョンがアップグレードされた場合でも SSO 状態を維持するのに役立ちます。 インポーターは、setRequestor() フロー中に実行され、次の 2 つのシナリオで実行されます（現在のプログラマーの有効な認証トークンが現在のストレージに存在しないと仮定）。

読み込み操作はプログラマーに対して透過的で、クライアントアプリケーションでコードを変更する必要はありません。

トークン・サニタイザ（AccessEnabler 1.7.5）

AccessEnabler 1.7.5 以降、このサービスは setRequestor(). WiFi MAC アドレスからトラッキング用の IDFA へのiOS 7 の切り替えの結果として開発されました。 サニタイザーは、現在のストレージに有効な認証トークン（デバイス ID （以前はiOS7 より前のMAC アドレスを使用して計算されていました）のみが含まれていることを確認します。 トークンサニタイザーは、無効なトークンをすべて削除します。

Token Sanitizer サービスは、AccessEnabler 1.7.5 アプリケーションをiOS 6 で使用した後、iOS 7 にアップデートする場合に最も役立ちます。 これが発生すると、（MAC アドレスの使用から IDFA にデバイス ID アルゴリズムが変更されたため）iOS 6 で取得されたすべての認証トークンが無効になります。 サニタイザーは無効なトークンをすべてクリアし、ユーザーは認証されなくなります。

トークン・サニタイザが無効なトークンを削除しないと、無効な認証トークンが存在するため、AccessEnabler は認証を取得できません。 承認エラーメッセージは不可解な場合があり、問題の原因を判断する際にあまり役に立たないので、エンドユーザーにとってはデバッグが難しくなります。

形式 format

なお、AuthN トークンと AuthZ トークンの形式は、背景情報としてのみ記載されています。 これらのトークンの構造は、Adobe Pass Authentication でいつでも変更できます。 AuthN および AuthZ トークンはローカルデバイスでは公開されないので、プログラマーはアプリを実装するために AuthN および AuthZ トークンの正確な構造を知る必要はありません。 ショートメディアトークン は プログラマーのアプリケーションに公開されます。

認証トークン authn_token

次のリストは、認証トークンの形式を示しています。

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

認証トークン authz_token

以下のリストは、認証トークンの形式を示しています。

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

短いメディアトークン short_token

以下のリストは、ショートメディアトークンの形式を示しています。 このトークンは、プログラマーのアプリケーションに公開されます。 正常な使用権限プロセスの最後に、プログラマーのアプリケーションに渡されます。

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

デバイス バインド device_binding

上記の XML の一覧で、「simpleTokenFingerprint」というタグが付いていることに注意してください。 このタグの目的は、ネイティブデバイス ID の個別化情報を保持することです。 AccessEnabler ライブラリでは、これらの個別化情報を取得し、使用権限呼び出し中にAdobe Pass認証サービスで使用できるようにします。 サービスはこの情報を使用して、実際のトークンに埋め込み、トークンを特定のデバイスに効果的にバインドします。 この最終目標は、デバイス間でトークンを転送できないようにすることです。

これは明らかにセキュリティ関連の機能なので、この情報はセキュリティの観点から本質的に「機密」です。 その結果、この情報は改ざんと盗聴の両方から保護する必要があります。 盗聴の問題は、HTTPS プロトコルで認証/承認リクエストを送信することで解決されます。 改ざん防止は、デバイス識別情報にデジタル署名することで処理されます。 AccessEnabler ライブラリは、デバイスから提供された情報からデバイス ID を計算し、そのデバイス ID をリクエスト・パラメータとしてAdobe Pass認証サーバに「クリアに」送信します。 Adobe Pass認証サーバは、Adobeの秘密鍵を使用してデバイス ID にデジタル署名し、AccessEnabler に返される認証トークンに追加します。 したがって、デバイス ID は認証トークンにバインドされます。 認証フロー中に、AccessEnabler はデバイス ID を認証トークンとともにクリアで再度送信します。 検証プロセスが失敗すると、認証/承認ワークフローが自動的に失敗します。 Adobe Pass認証サーバーは、秘密鍵をデバイス ID に適用し、認証トークンの値と比較します。 一致しない場合、使用権限フローは失敗します。

AccessEnabler 1.7.5 のデバイス バインディングに関する注意： AccessEnabler 1.7.5 以降、iOS デバイスの個別化情報を提供するために、デバイス ID の計算方法が変更されました。 この変更は、iOS 7 における次の変更を反映しています。iOS 7 からは、Appleは WiFi MAC アドレスをトラッキングオプションとして提供しなくなり、広告主の識別子（IDFA）を優先します。 iOS 7 で動作するアプリの個別化情報は IDFA に基づいており、その情報はエンタイトルメントフロートークンに埋め込まれているので、この変更によってユーザーエクスペリエンスに様々な影響が生じる可能性があります。 使用できる影響は、アップグレード元のiOSのバージョンと、プログラマがアップグレード元の AccessEnabler のバージョンによって異なります。 この変更の詳細については、AccessEnabler SDK 1.7.5 に含まれるリリース ノートを参照してください。