QlikView では、 (ブラウザを使用するか、または QlikView Desktop クライアントを介してドキュメントをダウンロードして開くかのどちらかで) QlikView Server によりセッションを確立する場合に、ユーザーが認証される必要があります。実装環境の大半でユーザー認証が必要とされますが、 QlikView は匿名でのアクセスを許可するように設定することも可能です。
QlikView のコンテキストでは、ほとんどの場合にユーザー認証が外部のエンティティに対して実行され、外部で認証されたユーザー ID を QlikView Server に渡すために使用されます。そのようなシナリオの場合、 QlikView では QlikView へのアクセス前に実行される認証により、ユーザー ID の一部のトークンが QlikView に送信され、信用されるようにします。
Windows ユーザー環境で QlikView Server を使用する場合の認証
Windows ユーザーに基づく環境での QlikView Server に対する認証処理 (Active Directory の組み込みなど) はシンプルです。手順は以下の通りです。
- ユーザーがクライアント マシンの Windows オペレーティング システムにログインする際、ユーザーの認証情報の検証が行われます。
- その後ユーザーがデスクトップのブラウザを使用するなどの方法で QlikView Server (QVS) とのセッションを確立しようとする場合、QVS では組み込みの Integrated Windows Authentication (IWA) を使用できます。
- ログインしたユーザーの ID は、Kerberos または NTLM のどちらかのセキュリティ ソリューションを使用して QlikView Server に送信されます。このソリューションは煩わしい設定なしでシングル サインオン機能を提供します。許可交換がユーザーの特定に失敗した場合は、ブラウザに Windows ユーザーのアカウント名とパスワードを求めるメッセージが表示されます。
下の図は IWA の標準的な許可フローを示したものです。
下の図は、NTLM と代替ログインの組み合わせの許可フローを示しています。これは、IWA の標準的なフローとは異なります。
許可プロセスは環境に応じて異なります。
- ローカル エリア ネットワーク (LAN): LAN 環境の Windows ユーザーの認識において最も一般的かつ適しているのは IWA です。認証処理はワークステーションへのログイン時に実行され、 QlikView はこの ID を利用します。
- マルチドメイン環境: ワークショップのドメインとサーバーのドメイン間の信頼性が確立されていないマルチドメイン環境が存在する構造において、あるいはリバース プロキシ上で使用する場合は、社内ネットワーク IWA は回避すべきです。このような環境では、認証された ID を既存の外部 SSO サービスと QlikView カスタム チケット交換のいずれかを使用して 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 として受け取る値となります。
QlikView が HTTP ヘッダーに ID を挿入するための特定のツールや製品を推奨または支持することはありません。このアプローチはユーザーが内部アクティブ ディレクトリに存在しないエクストラネットの実装に非常に適しています。認証処理は、リバース プロキシまたはエンド ユーザーの QlikView コンテンツの使用を妨害する ISAPI フィルターにより実行されます。
IWA またはシングル サインオン ソフトウェアを用いない認証
上記の方法がどちらも適切ではない場合、 QlikView では、第 3 のシングル サインオン方法として Custom Ticket Exchange (CTE) を使用できます。
CTE では、ユーザーはその他のシステムに先立ち許可を受けている必要があります。
- サードパーティ システムには、サード パーティ システムの認証ユーザーのために、QVS から (QlikView では「チケット」と呼ばれる) 認証トークンを要求する権利と責任が付与されています。正しい許可を受けたユーザーのみに対しチケットを要求する作業は、サード パーティ システムの責任のもとで行う必要があります (たとえば、QVS はユーザーの許可ステータスに関する知識を備えていません)。
- その後システムが許可トークンをユーザーに渡し、ユーザーはこれを用いて QVS とのセッションを開くよう要求します。
- QVS はチケットが有効かどうか確認し、許可ユーザーにセッションを公開します。
チケッティング認証は、主に QlikView コンテンツをサードパーティのアプリケーションやポータルに埋め込む場合に適用することができ、 QlikView への一般的なアクセスを提供するために使用されることは滅多にありません。CTE を実行するためにチケットを要求してこれを渡すには、通常多少のカスタム開発が必要になります。
カスタム ユーザーを使用した QlikView Server 認証
上記の 3 つすべての方法ではシングル サインオンの原理を使用しており、ユーザー ID とパスワードは QlikView Server の外部で保管され、外部エンティティが認証を担当します。QlikView Publisher のカスタム ユーザー機能を使用してユーザーの資格情報を QlikView Server 環境に保管することも可能ですが、あまり一般的ではありません。この場合は、ユーザーとパスワードが QlikView 環境内で定義および保管され、 QlikView 展開の Web 層でフォーム認証が実行されます。このソリューションは、小規模なスタンドアロンの QlikView Server 展開に適しており、ユーザー定義を複数のシステムで使用可能な環境で使用することはできません。このような環境では、上記で述べたシングル サインオン ソリューションのいずれかを使用することが推奨されます。
フォームが異なる許可には、それぞれ異なるウェブ サーバー インスタンスが必要です。その後それぞれのウェブ サーバーが、ユーザーの要求を同一の QVS インスタンスに転送します。
