メイン コンテンツをスキップする 補完的コンテンツへスキップ
Qlik リソース

マッシュアップの移行

すべてのマッシュアップが同じ方法で実装されるわけではありません。マッシュアップ移行プロセスに関与する注意事項を概説するガイドとして、次の内容を考慮してください。マッシュアップを移行しようとする前に、次を完了するようにしてください。

  • Qlik Cloud テナントを展開して構成する。

  • ユーザーは IdP で認証できます。そうすると必要なアプリが、ユーザーが最小限として [閲覧可能権限] を持つ、適切な共有または管理スペースに移行します。権限については、「共有スペースでの権限の管理」と「管理スペースでの権限の管理」を参照してください。

  • テナント管理役割を持つテナントにアクセスします (ウェブ統合を作成するのに必要です)。

また、IFrame だけでオブジェクトを埋め込むのか、Qlik Capability API を使うのかにかかわらず、JavaScript と HTML を使って Qlik Sense マッシュアップが一般的にどのように実装されているのかに精通しておく必要があります。

明確にするために言っておくと、新しいマッシュアップとは Qlik Cloud にあるものであり、古いマッシュアップとは Qlik Sense Client-Managed の既存のマッシュアップを指します。

ウェブ統合

Qlik Cloud の新しいマッシュアップは、Qlik Sense Client-Managed ではなく Qlik Cloud テナントからのコンテンツをロードおよび組み込みます。ウェブ統合は、マッシュアップ Web サイト (元) を特定できるよう、Qlik Cloud で ウェブ統合を構成する必要があります。

ウェブ統合とは、URL インクルージョン リストに関連付けられた有効な ID を提示する Web サイトが、埋め込まれたビジュアライゼーションをレンダリングできるようにするセキュリティ メカニズムです。Qlik Cloud と対話する Web アプリケーションには、テナントで構成される ウェブ統合が必要です。

Qlik Cloud でウェブ統合を作成する

ウェブ統合を作成するには、Qlik Cloud のテナント管理者である必要があります。

次の手順を実行します。

  1. 管理コンソール で、[ウェブ] セクションに移動し、右上隅の [新規作成] をクリックします。

  2. ダイアログで、ウェブ統合に名前を付けます。

  3. オリジンのアドレスを https://ドメイン.com の形式で入力します。[追加] をクリックしてオリジンを許可リストに追加します。

    情報メモ複数のオリジンを追加できます。
  4. [作成] をクリックします。
ウェブ統合の作成

ウェブ統合を作成したら、ID が付与されます。これは、マッシュアップに対する qlik ウェブ統合 ID であり、これは新しいマッシュアップ コードで必要な属性またはパラメーターです。

ウェブ統合 ID

ウェブ統合 ID の例

ウェブ統合作成の詳細については、ウェブ統合の管理を参照してください。

認証

Qlik Sense Client-Managed のマッシュアップは通常、認証メカニズムが事前に構成された仮想プロキシを通して認証を処理します。オプションには、ヘッダー、チケット、SAML、JWT、OpenID Connect ( OIDC)、および匿名などがあります。詳細については、「認証ソリューション」を参照してください。

Qlik Sense Client-Managed 古いマッシュアップの場合、認証は必要な静的Qlikファイルやライブラリなど、リソースの前のコードで処理されるのが普通で、この仮想プロキシ経由でロードされます。

例、

  • チケットと JWT の場合、通常、Qlik チケットまたは JWT トークンをセキュアに作成するためのバックエンド認証モジュールの呼び出しがあります。

  • ヘッダーの場合、いくつかの基礎となるモジュールまたは逆プロキシが適切なヘッダーを設定します。

  • OIDC および SAML の場合、リソースをロードしてコンテンツの埋め込みを開始できるよう、認証フローをトリガーして、最終的には Qlik Sense でセッションを開始する対応する ID プロバイダーへの開始時リダイレクトが必要です。

Qlik Cloud は、仮想プロキシを使用しません。代わりに、テナントで作成するウェブ統合を使用します。認証については、次の 2 つのメカニズムが使用できます。 

  • インタラクティブ サインイン — このメカニズムは、通常のアクセスのためにテナントが使用する構成済み IdP に依存します。これは既定では Qlik Account IdP、または Okta、Auth0、ADFS、AzureAD、Salesforce、Generic、および Keycloak などの利用可能なオプションのいずれかです。

  • JSON Web Tokens (JWT)—この認証メカニズムは、バックエンド サービスによって通常安全に生成される署名済みの JWT トークンに依存します。この場合、タイプ JWT のテナントに構成済みの ID プロバイダーがあるはずです。

Qlik オブジェクトが機能 API で埋め込まれるマッシュアップ

インタラクティブなサインインを使った認証

HTML 潜在的コードの更新

Qlik Sense Client-Managed マッシュアップと同様に、HTML の <head> セクションに 2 つの Qlik 静的ファイル (qlik-styles.css および require.js) をロードする必要があります。ただし、Qlik Cloud の場合、これらのファイルは直接アクセス可能で、認証は不要です。

HTML 潜在的コードの更新

JavaScript 潜在的コードの更新

Qlik Sense Client-Managed では、マッシュアップは機能 API を使用して Qlik Sense Client-Managed のオブジェクトを埋め込んで、対話し、次のコードをレビューします。この例では、機能 API Qlik ライブラリを使用していくつかのビジュアライゼーションを埋め込んでいます。

JavaScript 潜在的コードの更新

必須の構成変数および baseUrl

新しい Qlik Cloud マッシュアップの場合、構成変数がテナント host と webIntegrationId を反映している必要があります。また、仮想プロキシがないため、prefix は / である必要があります。セッションが共有されず、このマッシュアップのコンテクストでのみ使用されるよう、identity 属性を設定できます。ポートは 443 である必要があります。これは、isSecure が常に true であることを示唆しています。

require 構成には、webIntegrationId を含む必要があり、Qlik Cloud へのコミュニケーションが常にポート 443 の https 上であるために、baseUrl はより単純となります。

必須の構成変数および baseURL

機能 API のロード

require (js/qlik) Qlik 機能 API ライブラリをロードする前に、ユーザーがすでにサインインしたかどうかをチェックしてください。これは、例えば、現在のユーザー メタデータ エンドポイントの REST API 呼び出しをトリガーすることによって行うことができます。応答ステータスが 200 でない場合、コードはログイン画面にリダイレクトし、URL: returnto (実際のマッシュアップ URL) とand qlik-web-integration-id に 2 つのパラメーターを挿入します。

コード実行は次の通りです。

  • ユーザーが GET リクエストで /api/v1/users/me REST API エンドポイントにすでにサインインしたかどうかをチェックします。

    • そうでない場合 (応答ステータスが 200 でない) 場合、ログイン画面/login にリダイレクトし、return to と qlik-web-integration-id パラメーターを追加します。

    • サインインが済んでいる場合 (応答ステータスが 200)、qlik/js 機能 API ライブラリを require を使ってロードし、この一連の API を使用し続けます。

最終的なコードは次の例のようになります。JavaScript の場合、完璧なコードを書く固有の方法がないため、有効なコード オプションは 1 つのみです。

JSON Web Token (JWT) を使った認証

JWT ID プロバイダーを構成する

JWT トークンは、証明書 プライベート キーを使って安全に署名したペイロード ユーザー メタデータ (名前、メール、グループ、件名など) を暗号化した結果です。関連付けられた証明書 パブリック キーを持つ人は、トークンを認証して、そこに書かれたユーザー情報を読むことができます。

Qlik Cloud が署名済みの JWT トークンを認証するには、タイプ JWT の Qlik Cloud テナントで ID プロバイダーを構成する必要があります。構成が済んだら、テナントは適切に署名された bearer JWT トークンを含む API リクエストを承認して認証することができます。

次の手順を実行します。

  1. 管理コンソールでは、 ID プロバイダー を [構成] セクションから選択して、新しいものを作成します。

    タイプ JWT で ID プロバイダー構成を作成する

  2. PEM 形式で証明書パブリック キーを、上記の [証明書] ボックスに貼り付けます。

    古いマッシュアップが Qlik Sense Client-Managed の認証にすでに JWT を使っている場合、もう使用されている証明書のプライベートとパブリック キーを知っている可能性があります。また、署名済みの JWT トークン作成のためのバックエンド サービスをもう持っているかもしれません。そうでない場合は、「JWT 認証のために署名済みトークンを作成する」を参照してください。

  3. オプションで、発行者とキー ID を指定できます。どちらの場合も、作成後にこれらの値が表示されます。

    ID プロバイダー構成の発行者およびキー ID

署名済み JWT トークン バックエンド サービス潜在的コードの更新

Qlik Sense Client-Managed の場合、JWT トークンを生成するペイロードには、JWT 認証に対して Qlik Sense の仮想プロキシによって求められるため、クレーム ユーザー ID とユーザー ディレクトリのみが必要となります。Qlik Cloud の場合、このペイロードにはより多くの、異なるクレーム属性が必要となります。

ペイロードの JWT トークン生成バックエンド サービスのコードを、必要な署名オプションとともに、Qlik Cloud で要求されるものを反映するよう調整する必要があります。例えば、JWT の ID プロバイダーの発行者とキー ID は必須の署名オプションです。詳しい説明については、「Qlik Sense 認証の JWT 形式」を参照してください。

HTML 潜在的コードの更新

Qlik Sense Client-Managed マッシュアップと同様に、HTML の <head> セクションに 2 つの Qlik 静的ファイル (qlik-styles.css および require.js) をロードする必要があります。ただし、Qlik Cloud の場合、これらのファイルは直接アクセス可能で、認証は不要です。

JavaScript 潜在的コードの更新

コードの概念はインタラクティブ サインインの使用と似ています。例えば、この場合は、通常のログイン画面に対するリダイレクトの代わりに、/login/jwt-session エンドポイントに対する POST リクエストで JWT セッションを開始し、bearer JWT トークンとウェブ統合 id のヘッダーを渡す必要があります。

次の手順を実行します。

  • ユーザーがリクエストで /api/v1/users/me REST API エンドポイントにすでにサインインしたかどうかをチェックします。

    • サインインが済んでいる場合 (応答ステータスが 200)、qlik/js 機能 API ライブラリを require と併用します。

    • そうでない場合 (応答ステータスが 200 でない)、POST リクエストをトリガーして、所定の署名済み JWT トークンを使って JWT セッションを開始します。

      • サインインが済んでいる場合、qlik/js 機能 API ライブラリを require と併用します。

      • そうでない場合、JWT が無効、期限切れ、または承認されなかったために、JWT 認証が失敗した可能性があります。

次に挙げるのは、上記で説明したプロセスのコード例です。

Qlik Cloud の機能 API と互換性

機能 API は、ルート API、ビジュアライゼーション API、アプリ API、グローバル API、項目 API、テーブル API、変数 APIなど、異なる API のコレクションと対話できるようにする JavaScript ライブラリです。詳しいリストについては、「機能 API」を参照してください。

ウェブ アプリケーションに対して機能 API を使用する際、Qlik Cloud と Qlik Sense Client-Managed 間にほぼ完全な互換性がありますが、Qlik Cloud 展開でウェブサイトにこの JavaScript ライブラリを使用している場合、いくつかの微妙な違いと使用できない方法があります。例えば、グローバル API は Qlik Cloud で使用できません。

詳細については、「製品間の API 比較」を参照してください。

Qlik オブジェクトが IFrames に埋め込まれるマッシュアップ

Qlik オブジェクトが機能 API で埋め込まれるマッシュアップ の説明通り認証を処理するだけでなく、Qlik Cloud がどのようにコンテンツ セキュリティ ポリシー (CSP) を取り扱うかに精通しておく必要があります。

コンテンツセキュリティポリシー

Qlik Cloud の CSP ページは、他のドメインから Qlik オブジェクトへのアクセスをブロックします。つまり、シングル API IFrame アプローチを使って Qlik オブジェクトを埋め込むと、frame-ancestors ‘self’ ポリシー エラーが発生します。

ポリシー エラー: frame-ancestors 'self'

マッシュアップ IFrames を使って Qlik Cloud オブジェクトを埋め込めるように CSP を構成する方法については、「コンテンツ セキュリティ ポリシー」を参照してください。

enigma.js を使ったマッシュアップ

enigma.js ライブラリを使うと、JavaScript 環境の Qlik Associative Engine と通信できます。

Qlik で enigma.js を使用する際は、必須のウェブ統合とユーザー認証処理とは別にクロスサイト リクエスト フォージェリ (CSRF) の概念を考慮する必要があります。

クロスサイト リクエスト フォージェリ (CSRF)

Qlik Cloud には、クロスサイト リクエスト フォージェリ (CSRF) から保護するための対策があります。Qlik Cloud と通信するウェブ ソリューションの場合、すべての非 GET REST 呼び出すに WebSocket 接続などの有効な CSRF トークンを提供する必要があります。

バックエンドまたはフロントエンド コードのいずれかのウェブ アプリケーションで enigma.js を使用する際、WebSocket 接続が作成されます。これは、enigma.js ライブラリが Qlik Cloud でセキュア セッションを開くためには、CRSF トークンが WebSocket 接続のパラメーターとして含まれる必要があるということです。

ユーザーがサインインすると、有効な CSRF トークンを /api/v1/csrf-token エンドポイントにリクエストできます。

次の enigma.js のコード例 (ユーザーはサインイン済み) は、アプリを開いてレイアウトをフェッチするためにフロントエンド コードで使用されています。

完全なコード例を見るには、次のチュートリアルをご覧ください:

シンプルなウェブ アプリ チュートリアルを作成します。

を使って iframes のシートを処理するenigma.js

Visit the discussion forum at community.qlik.com

このページは役に立ちましたか?

このページまたはコンテンツに、タイポ、ステップの省略、技術的エラーなどの問題が見つかった場合は、お知らせください。改善に役立たせていただきます。

こちらにフィードバックをお寄せください