認証

QlikView は匿名でのアクセスを許可するよう設定可能ですが、実装する場合は大部分においてユーザー許可が必要になります。このような環境において、QlikView Server を介してセッションを確立する (ブラウザを通じて、あるいは QlikView Desktop クライアントを通じてドキュメントをダウンロードまたは開く) 場合、QlikView は必ずユーザー許可を要求します。

QlikView のコンテクストでは、ほとんどの場合、ユーザー許可は外部エンティティに対して行われ、これが外部の許可ユーザー ID を QlikView Server に渡す際に用いられます。このシナリオでは、QlikView にアクセスする前に許可を実行することでその ID のトークンの一部が QlikView に送信され、これにより QlikView がユーザーを識別します。

Windows ユーザー環境で QlikView Server を使用する場合の認証

Windows ユーザー環境で QlikView Server に対する認証 (例: アクティブ ディレクトリ の組み込み) 手順はシンプルです。手順は以下の通りです。

 

  1. ユーザーがクライアント マシンの Windows オペレーティング システムにログインする際、ユーザーの認証情報の検証が行われます。
  2. その後ユーザーが QlikView Server (QVS) でデスクトップのブラウザを介するなどしてセッションの確立を試みた場合、QVS は組み込みの Integrated Windows Authentication (IWA) を使用できます。
  3. ログイン済みのユーザーの ID は、ケルベロス許可または NTLM セキュリティ ソリューションのいずれかを用いて QlikView Server に送信されます。このソリューションは煩わしい設定なしでシングル サインオン機能を提供します。許可交換がユーザーの特定に失敗した場合は、ブラウザに Windows ユーザーのアカウント名とパスワードを求めるメッセージが表示されます。
注: ユーザー グループは、QlikView システムに転送できません。ユーザー グループは、Directory Service Connector (DSC) で解決する必要があるか、またはまったく解決の必要がありません。

下の図は IWA の標準的な許可フローを示したものです。

Windows ユーザー環境で QlikView Server を使用する場合の認証

下の図は、NTLM と代替ログインの組み合わせの許可フローを示しています。これは、IWA の標準的なフローとは異なります。

NTLM と代替フォームを使用した許可

許可プロセスは環境に応じて異なります。

  • ローカル エリア ネットワーク (LAN): LAN 環境の Windows ユーザーの認識において最も一般的かつ適しているのは IWA です。許可作業はワークステーションにログインした際に行われ、QlikView はこの ID を利用します。
  • マルチドメイン環境: ワークショップのドメインとサーバーのドメイン間の信頼性が確立されていないマルチドメイン環境が存在する構造において、あるいはリバース プロキシ上で使用する場合は、社内ネットワーク IWA は回避すべきです。このような環境では、QlikView に許可 ID を提示するのに、既存の外部 SSO サービスまたは QlikView カスタム チケット交換のいずれかを用いるよう QlikView の実装を設定する必要があります。

既存のシングル サインオン (SSO) ソフトウェア パッケージを用いた QlikView Server での認証

SSO の基本構造がすでに存在する環境 (例: CA SiteMinder®、IBM® WebSeal、Oracle® Oblix など) では、QlikView は SSO 基本構造が提供するシングル サインオンの HTTP ヘッダー挿入方法を利用できます。これは、煩わしい設定なしでシングル サインオンが提供されることを意味します。SSO 基本構造ソフトウェア パッケージは、以下のように設定できます。

  • リピート ユーザーのアクセスの取得: リソースを保護するようソフトウェア パッケージを設定できます。ユーザーが QlikView へのアクセスを要求した場合、ユーザーが過去に SSO 許可ページにサインインしたことがあれば、SSO パッケージはアクセスを許可します。
  • 新規ユーザーのログイン: SSO パッケージの既存のセッションがない場合、ユーザーは SSO パッケージのログイン ページにリダイレクトされます。ログイン後、最初に要求した URL にリダイレクトされます。

どちらの場合も、ユーザーが SSO ソフトウェアに対し正しく許可されている場合はユーザー名が HTTP ヘッダーに挿入され、そのヘッダー内の値は QlikView サーバーが受け取ったユーザーの許可 ID になります。

注: SSO ソフトウェアが正しく機能している場合を除き、QlikView Server への HTTP ヘッダー方法による許可は使用しないでください。HTTP ヘッダーは容易にスプーフィングされてしまいます。ユーザーにとってソフトウェア パッケージがコンテンツにアクセスする唯一のパスである場合、上記で述べたすべての SSO ソフトウェア パッケージは、この種類のスプーフィング攻撃に対する保護を提供します。

QlikView は HTTP ヘッダーに ID を提供するための特定のツールや製品を推奨または支持するものではありません。このアプローチはユーザーが内部アクティブ ディレクトリに存在しないエクストラネットの実装に非常に適しています。許可作業は、リバース プロキシまたはエンド ユーザーの QlikView コンテンツの使用を妨害する ISAPI フィルタにより実行されます。

IWA またはシングル サインオン ソフトウェアを用いない認証

上記の方法がどちらも適さない場合、QlikView ではシングル サインオン用の Custom Ticket Exchange (CTE) を利用できます。

CTE では、ユーザーはその他のシステムに先立ち許可を受けている必要があります。

  1. サードパーティ システムは、サード パーティ システムの許可ユーザーの代表として QVS から許可トークン (QlikView では「チケット」と呼ばれる) を要求する権利と責任を付与されます。正しい許可を受けたユーザーのみに対しチケットを要求する作業は、サード パーティ システムの責任のもとで行う必要があります (たとえば、QVS はユーザーの許可ステータスに関する知識を備えていません)。
  2. その後システムが許可トークンをユーザーに渡し、ユーザーはこれを用いて QVS とのセッションを開くよう要求します。
  3. QVS はチケットが有効かどうか確認し、許可ユーザーにセッションを公開します。

チケッティング許可は主に QlikView コンテンツをサード パーティのアプリケーションやポータルに埋め込む場合に適しており、QlikView への通常のアクセスの提供に用いられることはほぼありません。CTE を実行するためにチケットを要求してこれを渡すには、通常多少のカスタム開発が必要になります。

IWA またはシングル サインオン ソフトウェアを用いない認証

カスタム ユーザーを用いた QlikView Server の認証

上記で述べた 3 つの方法はシングル サインオンの原則を用いたもので、ユーザー ID とパスワードが外部の QlikView Server に保存され、外部エンティティが許可を行います。あまり一般的ではありませんが、QlikView Publisher のカスタム ユーザー機能を用いて QlikView Server 環境にユーザーの許可情報を保存する方法もあります。ここでは、ユーザーとパスワードは QlikView 環境で定義および保存され、QlikView 実装のウェブ層がフォーム許可を行います。このソリューションは小規模のスタンドアロン QlikView Server の実装に適しています。複数のシステムがユーザー定義にアクセス可能な環境では使用しないでください。このような環境では、上記で述べたシングル サインオン ソリューションのいずれかを使用することが推奨されます。

フォームが異なる許可には、それぞれ異なるウェブ サーバー インスタンスが必要です。その後それぞれのウェブ サーバーが、ユーザーの要求を同一の QVS インスタンスに転送します。

カスタム ユーザーを用いた QlikView Server の認証