シングル・サインオンの有効化

シングル・サインオンが有効化されている場合、ユーザーは、外部ユーザー管理システムにすでにログインしているときはEDQアプリケーションにログインする必要はありません。たとえば、EDQをWindows Active Directoryと統合するように構成することが可能であるため、Active Directoryドメインにすでにログインしたユーザーは、EDQログイン画面をバイパスでき、すべてのEDQユーザー・アプリケーションに自動的にログインされます。

サポートされているシングル・サインオン・システム

シングル・サインオンには、Microsoft Active Directoryドメインなど、ユーザー認証にKerberosを使用するシステムが必要です。この場合、ユーザーはActive Directoryで認証され、その資格証明を証明するKerberosチケットを使用して発行されます。その後、このチケットを使用してEDQでユーザーを認証できるため、ユーザー詳細（ユーザー名またはパスワード）を再入力する必要がないことを意味します。

構成

clientcreds = true

これは、サーバーに対して、Kerberosサインイン・プロセスのaccept部分で、ローカル・マシン・アカウントの現在の資格証明を使用するように指示します。

資格証明がKerberosキータブから取得されるUnix形式のインストールの場合、clientcredsはfalseに設定するか、または省略する必要があります。

ブラウザ設定

書込み時に、大部分のブラウザでは、SSOに必要なNEGOTIATE認証メカニズムがサポートされていません（またはデフォルトでサポートされていません）。次に、既知のイシューを示します。

Microsoft Internet Explorerでは、サーバーがローカル・イントラネット・ゾーンにある場合のみNEGOTIATE機能が使用されます。
Mozilla Firefoxでは、NEGOTIATEを有効にするには構成の微調整（network.negotiate-auth.trusted-uris）が必要です。
Google ChromeではNEGOTIATEはサポートされません。
すべてのブラウザ - シングル・サインオンは、クライアント・ブラウザとサーバーが同じシステム上にある場合は機能しません。WindowsではGSSのかわりにNTLMが使用され、これは単一のハンドシェイクでは完了できません。
ブラウザはHTTP/サーバー名に対するKerberosサービス・チケットを取得しようとし、大部分のローカル・マシン・アカウントには、適合するservicePrincipalNameがそのADSアカウントにありません。ネットワーク管理者は、setspnコマンドを使用してこれを設定できます。
さらに、EDQ Webサービスのテストによく使用されるアプリケーションSoapUIでは、NEGOTIATE認証がサポートされていません。

前述のイシューが解決できると仮定すると、次の行によって、すべてのブラウザ・コンテキストでSSOが有効になります。

http.gss = true

様々なコンテキストを選択して有効にするには、次のように複数の行を使用します。

http.gss.admin = true

http.gss.formws = true

http.gss.ws = true

http.gss.dashboard = true

内容は次のとおりです。

adminは、EDQ起動パッドからアクセスされる管理ページを意味します。
formwsは、フォームベースのWebサービスを意味します。
wsは、SOAP Webサービスを意味します。
dashboardは、ダッシュボード・ログインを意味します。