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

はじめに intro

iOS AccessEnabler は、モバイルアプリで TV Everywhere の権限付与サービスにAdobe Pass認証を使用できるようにする、Objective C iOS/tvOS ライブラリです。 この実装は、 AccessEnabler 使用権限 API を定義するインターフェイスと EntitlementDelegate および EntitlementStatus ライブラリのコールバックを記述するプロトコルトリガー。 プロトコルと共に使用されるインターフェイスは、AccessEnabler ライブラリという 1 つの共通名の下に表示されます。

iOSと tvOS の要件 reqs

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

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

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

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

AccessEnabler でサポートされるすべての権限付与ワークフローは、以前に setRequestor() をクリックして、id を確立します。 この呼び出しを実行して Requestor ID を指定するのは、通常、アプリケーションの初期化/設定フェーズ中に 1 回だけにします。

iOSネイティブクライアントで、 setRequestor()を使用する場合、次の手順を実行する方法を選択できます。

成功の通知をアプリに待機させるか、 setRequestor() または、AccessEnabler の呼び出しキュー・メカニズムに依存している場合もあります。 それ以降のすべての認証要求にはリクエスト元 ID と関連する設定情報が必要なので、 setRequestor() メソッドは、初期化が完了するまで、すべての認証および承認 API 呼び出しを効果的にブロックします。

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

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

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

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

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

ログアウトフローは、ユーザーが UIWebView/WKWebView or SFSafariViewController コントローラーを使用します。 したがって、Adobeでは、ログアウトプロセス中にコントロールを非表示（非表示）にすることをお勧めします。

トークン tokens

定義と使用方法 definitions

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

トークンの有効期限は限られています。有効期限が切れたら、認証ワークフローや認証ワークフローの再開を通じてトークンを再発行する必要があります。

使用権限付与ワークフローでは、次の 3 種類のトークンが発行されます。

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

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

認証トークン

認証トークン

いつでも、AccessEnabler によってキャッシュされる認証トークンは PER RESOURCE に 1 つだけです。 複数の認証トークンをキャッシュすることができますが、異なるリソースに関連付けられます。 新しい認証トークンが発行され、古い認証トークンが 同じリソース ​を指定した場合、新しいトークンは既存のキャッシュされた値を上書きします。

メディアトークン

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

永続性 persistence

トークンは、同じアプリケーションの連続した実行の間、保持する必要があります。 つまり、認証および認証トークンが取得され、ユーザーがアプリケーションを閉じると、ユーザーがアプリケーションを再度開いたときに、同じトークンがアプリケーションで使用できるようになります。 さらに、これらのトークンは複数のアプリケーション間で保持することが望ましい。 つまり、ユーザーが 1 つのアプリケーションを使用して特定の ID プロバイダーにログインした後（認証および認証トークンの取得に成功）、同じトークンを別のアプリケーションで使用でき、同じ ID プロバイダー経由でログインする際に資格情報の入力を求められなくなります。 このようなシームレスな認証/承認ワークフローにより、Adobe Pass Authentication Solution が真の 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 の設定については、次のテクニカルノートを参照してください（このテクニカルノートは Access Enabler 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 に含まれる別のストレージ関連機能により、古いストレージ領域から認証トークンをインポートできます。 この「トークンインポーター」は、ストレージバージョンがアップグレードされても SSO 状態を維持し、連続する AccessEnabler リリース間の互換性を実現するのに役立ちます。 インポーターは、 setRequestor() フローとは、次の 2 つのシナリオで実行されます（現在のプログラマーの有効な認証トークンが現在のストレージに存在しない場合）。

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

トークン・サニタイザ (AccessEnabler 1.7.5)

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

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

Token Sanitizer が無効なトークンを削除しない場合、AccessEnabler は、無効な認証トークンが存在するため、認証を取得できませんでした。 認証エラーメッセージは暗号化され、問題の原因を特定するのに過度に役立たないので、これはエンドユーザーにとってデバッグが難しいことを証明します。

形式 format

ここでは、AuthN および AuthZ トークンの形式については、バックグラウンド情報に関してのみ記述します。 これらのトークンの構造は、いつでもAdobe Pass認証によって変更できます。 AuthN と AuthZ トークンはローカルデバイスで公開されないので、プログラマーはアプリを実装するために AuthN と AuthZ トークンの正確な構造を知る必要はありません。 Short Media トークン 次に該当 プログラマーのアプリケーションに公開される。

認証トークン 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 Authentication サービスで使用できるようにすることができます。 この情報を使用して実際のトークンに埋め込むので、トークンを特定のデバイスに効果的にバインドします。 この最終目標は、デバイス間でトークンを転送できないようにすることです。

これは明らかにセキュリティ関連の機能なので、セキュリティの観点から言えば、この情報は本質的に「機密性」が高いものです。 その結果、この情報は改ざんや盗聴の両方から保護される必要があります。 盗聴の問題は、認証/承認リクエストを 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 以降では、デバイス ID の計算方法が変更され、iOSデバイスの個人情報が提供されるようになりました。 この変更は、iOS 7 の変更を反映しています。iOS 7 以降、Appleは WiFi MACアドレスをトラッキングオプションとして提供しなくなり、広告主識別子 (IDFA) が優先されます。 iOS 7 で実行するアプリの個別化情報は IDFA に基づいており、その情報がエンタイトルメントフロートークンに埋め込まれるので、この変更によってユーザーエクスペリエンスに様々な影響が及ぶ可能性があります。 考えられる様々な影響は、ユーザーがアップグレードするiOSのバージョンと、プログラマがアップグレードする AccessEnabler のバージョンを組み合わせたバージョンに基づいています。 この変更の詳細については、AccessEnabler SDK 1.7.5 に含まれるリリースノートを参照してください。