JP2018110012A - 認証システム及び認証方法 - Google Patents

Abstract

【課題】ＯＳアカウント情報を利用したＳＳＯにより、アクセス制限されたｗｅｂサービスの認証を行う場合に生じる不具合を、既存のシステム基盤環境を大幅に変更することなく解消できる認証システム及び認証方法を提供する。【解決手段】認証システムは、クライアント端末のＯＳアカウント情報により認証を行う第１の認証装置と、ｗｅｂブラウザーにおいてログインフォームに入力されたＦｏｒｍ認証情報により認証を行う第２の認証装置と、ｗｅｂブラウザーの種類を判別し、当該ｗｅｂブラウザーが所定のｗｅｂブラウザーである場合に第１の認証装置で認証が行われるように制御する一方、当該ｗｅｂブラウザーが所定のｗｅｂブラウザーでない場合に第２の認証装置で認証が行われるように制御する振分けサーバーと、を備える。【選択図】図２

Description

本発明は、アクセス制限されたｗｅｂサービスの認証をシングルサインオンにより行う認証システム及び認証方法に関する。

近年、シングルサインオン（ＳＳＯ：Single Sign-On）と呼ばれる統合認証技術が普及している（例えば特許文献１）。ＳＳＯによれば、個別に認証処理が必要な複数のｗｅｂサービス（例えばグループウェアのアプリケーション）を、一度のログイン操作によるユーザー認証だけで利用できるようになる。ＳＳＯにより連携しているｗｅｂサービスを「ＳＳＯ連携サービス」と称する。

特に、ｗｉｎｄｏｗｓ（登録商標）の標準ブラウザーであるインターネットエクスプローラー（登録商標、以下「ＩＥ」と称する）の場合、個別に認証処理が必要な複数のｗｅｂサービスにアクセスする場合には、マイクロソフト社製のアクティブディレクトリに参加することで、統合ｗｉｎｄｏｗｓ認証を利用することができる（例えば特許文献２）。統合ｗｉｎｄｏｗｓ認証では、オペレーティングシステム（以下「ＯＳ」と称する）にログインする際のアカウント情報（ユーザーＩＤ及びパスワード、以下「ＯＳアカウント情報」と称する）によって、初回アクセス時の認証が行われる。

図１は、統合ｗｉｎｄｏｗｓ認証を利用してシングルサインオンを行う、従来の認証システム６０の一例を示す図である。図１に示すように、認証システム６０は、例えばＬＡＮ（Local Area Network）等の企業内ネットワークＮ１に接続された、認証処理が必要な複数のｗｅｂサーバー２０が提供するｗｅｂサービスを利用する際の認証を行う。この認証には、企業内ネットワークＮ１内に存在しているクライアント端末５３が、アクティブディレクトリ４０に参加することで、統合ｗｉｎｄｏｗｓ認証を利用することができる。また、インターネットＮ２からＶＰＮサーバー５５（ＶＰＮ：Virtual Private Network）を介して、外部のクライアント端末５１もアクティブディレクトリ４０に参加することで、同様に統合ｗｉｎｄｏｗｓ認証を利用することができる。

認証システム６０は、統合ｗｉｎｄｏｗｓ認証を実現する統合ｗｉｎｄｏｗｓ認証環境であり、リバースプロキシサーバー６１及びＳＳＯサーバー６２を有する。リバースプロキシサーバー６１とＳＳＯサーバー６２が協働して統合ｗｉｎｄｏｗｓ認証による認証処理を行う。以下に、ｗｅｂサーバー２０への初回アクセス時の認証処理について説明する。

なお、クライアント端末５０によってｗｅｂサーバー２０が提供するｗｅｂサービスのＵＲＬへのアクセス要求があった場合、ＤＮＳサーバー５４によって、リバースプロキシサーバー６１に接続されるようになっている。

クライアント端末５３がＯＳにログインした時、アクティブディレクトリ４０からＴＧＴ（Ticket Granting Ticket）と呼ばれる認証チケットが発行される。この状態でクライアント端末５３のＩＥが、ｗｅｂサーバー２０が提供するｗｅｂサービスへのアクセスを要求すると、リバースプロキシサーバー６１は、クライアント端末５３がＳＳＯサーバー６２に認証されているかを判断する。

ユーザーが未認証であることが確認されると、ＳＳＯサーバー６２は認証エラー（４０１エラー）で応答する。クライアント端末５３のＩＥは４０１エラーを受け取るとＳＳＯサーバー６２に対し、認証チケットの情報とアクティブディレクトリ４０に登録されているＯＳアカウント情報の照合を要求する。この要求を受けたＳＳＯサーバー６２は認証チケットの情報とアクティブディレクトリ４０に登録されているＯＳアカウント情報の照合を行い、照合が成立すると、クライアント端末５３のＩＥに対してＳＳＯサーバー６２の認証Ｃｏｏｋｉｅを発行する。

これにより、統合ｗｉｎｄｏｗｓ認証が成立するため、クライアント端末５３は、この認証Ｃｏｏｋｉｅを利用してｗｅｂサーバー２０が提供するｗｅｂサービスを含むＳＳＯ連携サービスを利用できるようになる。つまり、ＳＳＯ連携サービスを利用する際に、その都度、ログイン操作を行うことなく、認証Ｃｏｏｋｉｅを所有していることをもってアクセスが許可される。

一方、クライアント端末５２がｉＰｈｏｎｅ（登録商標）やｉＰａｄ（登録商標）などであり、ＩＥ以外のｗｅｂブラウザー（例えばｉＯＳの標準ブラウザーであるＳａｆａｒｉ（登録商標））から、ｗｅｂサーバー２０が提供するｗｅｂサービスへアクセスを要求した場合、認証システム６０において統合ｗｉｎｄｏｗｓ認証は行われない。統合ｗｉｎｄｏｗｓ認証においては、ＩＥの使用が前提となっており、ＩＥ以外のｗｅｂブラウザーはサポートされていないためである。

この場合、Ｓａｆａｒｉは、認証エラー（４０１エラー）を無視して、ＳＳＯサーバー６２に対して、認証を行うためのログインＩＤおよびログインパスワードを入力するログイン画面を要求する。このログイン画面を利用してＳＳＯサーバー６２へ認証を成立させる行為を「Ｆｏｒｍ認証」と称する。ユーザーがＦｏｒｍ認証を行うことにより、ＳＳＯサーバー６２で入力されたログインＩＤおよびログインパスワードの照合が成立すると、クライアント端末５２のＳａｆａｒｉに対して認証Ｃｏｏｋｉｅが発行される。

特許第４６５２３５０号公報 特開２０１３−８１４０号公報

上述したように、ＩＥ以外のｗｅｂブラウザーでは、統合ｗｉｎｄｏｗｓ認証による認証は行われず、Ｆｏｒｍ認証による認証が行われる。しかしながら、使用するｗｅｂブラウザーによっては、認証エラーを解釈できずに、Ｆｏｒｍ認証すらできなくなる場合がある。例えば、ｉＯＳ７．０以降のバージョンにおいては、Ｓａｆａｒｉで統合ｗｉｎｄｏｗｓ認証を利用しようとすると、通信エラーが発生し、Ｓａｆａｒｉがハングアップしてしまう。このような問題の解決策としては、以下の３つの手法が一般的である。

第一に、ｉＯＳ７．０以降のバージョンは、エンタープライズシングルサインオン機能を有しているので、ｉＯＳの構成プロファイルを変更し、統合ｗｉｎｄｏｗｓ認証による認証を利用可能とすることが考えられる。しかしながら、本来的にアクセス権限のある全てのクライアント端末の管理が必要となる上、ｉＯＳは自動的にアップデートされるため、突然の動作不良などが生じる虞がある。

第二に、ＳＳＯ環境を導入する場合に設置されるロードバランサーの機能を利用して、認証時にアクセス元のｗｅｂブラウザーの種類を判別し、判別結果に基づいてアクセス先の認証環境（統合ｗｉｎｄｏｗｓ認証用の認証環境又はＦｏｒｍ認証用の認証環境）を振り分けることが考えられる。しかしながら、ｗｅｂブラウザーの種類を判別する機能はロードバランサーに必須の機能ではなく、当該機能を有していないロードバランサーもあるため、標準的な解決策にはならない。

第三に、ＩＥがアクセスするＤＮＳサーバーと、ＩＥ以外のｗｅｂブラウザーがアクセスするＤＮＳサーバーを設置し、ＤＮＳサーバーによってアクセス先の認証環境を振り分けることが考えられる。しかしながら、クライアント端末やｗｅｂブラウザーごとにＤＮＳサーバーを変えるというのは一般的な運用ではないため、多くの場合、システム基盤環境の再構築が必要となる。

本発明の目的は、ＯＳアカウント情報を利用したＳＳＯにより、アクセス制限されたｗｅｂサービスの認証を行う場合に生じる不具合を、既存のシステム基盤環境を大幅に変更することなく解消できる認証システム及び認証方法を提供することである。

本発明に係る認証システムは、アクセス制限されたｗｅｂサービスに対してクライアント端末のｗｅｂブラウザーからアクセス要求があった場合に、ＳＳＯにより認証を行う認証システムであって、
前記クライアント端末のＯＳアカウント情報により認証を行う第１の認証装置と、
前記ｗｅｂブラウザーにおいてログインフォームに入力されたＦｏｒｍ認証情報により認証を行う第２の認証装置と、
前記ｗｅｂブラウザーの種類を判別し、当該ｗｅｂブラウザーが所定のｗｅｂブラウザーである場合に前記第１の認証装置で認証が行われるように制御する一方、当該ｗｅｂブラウザーが前記所定のｗｅｂブラウザーでない場合に前記第２の認証装置で認証が行われるように制御する振分けサーバーと、を備える。

本発明に係る認証方法は、アクセス制限されたｗｅｂサービスに対してクライアント端末のｗｅｂブラウザーからアクセス要求があった場合に、ＳＳＯにより認証を行う認証方法であって、
（Ａ）前記ｗｅｂブラウザーの種類を判別する工程と、
（Ｂ）前記工程Ａで判別されたｗｅｂブラウザーが所定のｗｅｂブラウザーである場合に、前記クライアント端末のＯＳアカウント情報により認証を行う工程と、
（Ｃ）前記工程Ａで判別されたｗｅｂブラウザーが前記所定のｗｅｂブラウザーでない場合に、前記ｗｅｂブラウザーにおいてログインフォームに入力されたＦｏｒｍ認証情報により認証を行う工程と、を備えることを特徴とする。

本発明によれば、予めｗｅｂブラウザーに対応付けられた認証装置が当該ｗｅｂブラウザーに適した認証処理を行うので、ＯＳアカウント情報を利用したＳＳＯにより、アクセス制限されたｗｅｂサービスの認証を行う場合に生じる不具合を、既存のシステム基盤環境を大幅に変更することなく解消することができる。

統合ｗｉｎｄｏｗｓ認証を利用してシングルサインオンを行う、従来の認証システムの一例を示す図である。 本発明の一実施の形態に係る認証システムの一例を示す図である。 本実施の形態の認証システムを利用した初回アクセス時の認証処理の一例を示す図である。 本実施の形態の認証システムを利用した初回アクセス時の認証処理の他の一例を示す図である。

以下、本発明の実施の形態を、図面を参照して詳細に説明する。

図２は、本発明の一実施の形態に係る認証システム１０を示す図である。図２に示すように、認証システム１０、ｗｅｂサーバー２０、振分けサーバー３０、及びアクティブディレクトリ４０は、例えばＬＡＮ等の企業内ネットワークＮ１に接続される。

認証システム１０は、クライアント端末５０が、ｗｅｂサーバー２０が提供するアクセス制限されたｗｅｂサービスを利用する際のシングルサインオンを実現する。認証システム１０によって初回アクセス時の認証が行われ、認証Ｃｏｏｋｉｅが発行されると、ｗｅｂサーバー２０が提供するｗｅｂサービスを含むＳＳＯ連携サービスを個別に認証処理することなく利用することができる。

ｗｅｂサーバー２０が提供するｗｅｂサービスには、企業内ネットワークＮ１内に存在し、アクティブディレクトリ４０に参加しているクライアント端末５３だけでなく、インターネットＮ２から、ＶＰＮサーバー５５を介して、外部のクライアント端末５１、５２もアクセスできる。

クライアント端末５１、５３は、ＯＳがｗｉｎｄｏｗｓであり、ｗｉｎｄｏｗｓの標準ブラウザーであるＩＥでｗｅｂサービスを利用する場合、統合ｗｉｎｄｏｗｓ認証環境によるＳＳＯがサポートされる。クライアント端末５２は、ＯＳがｉＯＳであり、ｉＯＳの標準ブラウザーであるＳａｆａｒｉでｗｅｂサービスを利用する場合、ｉＯＳの構成ファイルを変更するなどしない限り、初期設定では、統合ｗｉｎｄｏｗｓ認証環境によるＳＳＯはサポートされない。

認証システム１０は、第１の認証装置１１、第２の認証装置１２、及びｗｅｂブラウザーの種類を判別し、判別結果に基づいて認証装置先を制御する振分けサーバー３０を備える。

第１の認証装置１１は、統合ｗｉｎｄｏｗｓ認証を実現する認証環境であり、リバースプロキシサーバー１１１及びＳＳＯサーバー１１２を有する。ｗｅｂサーバー２０が提供するｗｅｂサービスへの初回アクセス時に、リバースプロキシサーバー１１１とＳＳＯサーバー１１２が協働して、統合ｗｉｎｄｏｗｓ認証による認証処理を行う。

第２の認証装置１２は、Ｆｏｒｍ認証を実現する認証環境であり、リバースプロキシサーバー１２１及びＳＳＯサーバー１２２を有する。ｗｅｂサーバー２０が提供するｗｅｂサービスへの初回アクセス時に、リバースプロキシサーバー１２１とＳＳＯサーバー１２２が協働して、Ｆｏｒｍ認証による認証処理を行う。

アクティブディレクトリ４０には、企業内ネットワークＮ１の正規ユーザーＯＳアカウント情報が登録される。

振分けサーバー３０は、インターネットＮ２に接続するクライアント端末５１、５２が、ＶＰＮサーバー５５を介して、ｗｅｂサーバー２０が提供するサービスへのアクセス要求を行った場合に、クライアント端末５１、５２のｗｅｂブラウザーの種類を判別し、アクセス先を決定する。具体的には、振分けサーバー３０は、アクセス元のｗｅｂブラウザーの種類を判別し、当該ｗｅｂブラウザーがＩＥである場合に第１の認証装置１１で認証が行われるように制御する一方、当該ｗｅｂブラウザーがＩＥでない場合に第２の認証装置１２で認証が行われるように制御する。

振分けサーバー３０には、例えば「Apache HTTP Server」（以下「Ａｐａｃｈｅ」と称する）を適用する。Ａｐａｃｈｅの設定により、アクセス要求に含まれるUser-Agent HTTPヘッダーに基づいて、アクセス元のｗｅｂブラウザーの種類を判別し、第１の認証装置１１又は第２の認証装置１２に振り替える。

なお、クライアント端末５１、５２によってｗｅｂサーバー２０が提供するｗｅｂサービスのＵＲＬへのアクセス要求があった場合、ＤＮＳサーバー５４によって、振分けサーバー３０に接続されるようになっている。

以下に、ｗｅｂサーバー２０が提供するｗｅｂサービスへの初回アクセス時の認証処理について説明する。

図３は、本実施の形態の認証システム１０を利用した初回アクセス時の認証処理の一例を示す図である。図３は、ｗｅｂブラウザーがＩＥであるクライアント端末５１からアクセス要求が行われる場合の処理フローを示す。

ステップＳ１０１において、クライアント端末５１のＩＥは、ｗｅｂサーバー２０が提供するｗｅｂサービスへのアクセス要求を行う。当該ｗｅｂサービスのＵＲＬは、例えば「http://test-web.com」である。ＤＮＳサーバー５４によって、「http://test-web.com」に関連づけられているＩＰアドレスが判明し、アクセス要求は振分けサーバー３０に送信される。

ステップＳ１０２において、振分けサーバー３０は、アクセス要求を行ったｗｅｂブラウザーの種類を判別する。ここでは、アクセス要求を行ったｗｅｂブラウザーはＩＥである。

ステップＳ１０３、Ｓ１０４において、振分けサーバー３０は、ＩＥに対応するＳＳＯ環境である第１の認証装置１１にアクセスするようにｗｅｂブラウザーに対して回答を行う。回答内容である第１の認証装置１１のＵＲＬは、振分けサーバー３０で管理される設定ファイルに基づき、例えば「http://test-web-win.com」となる。

ステップＳ１０５において、第１の認証装置１１は、統合ｗｉｎｄｏｗｓ認証により、認証を行う。具体的には、ＳＳＯサーバー１１２は、クライアント端末５１の認証チケットの情報とアクティブディレクトリ４０に登録されているＯＳアカウント情報による照合を行い、照合が成立すると、クライアント端末５１のＩＥに対して認証Ｃｏｏｋｉｅを発行する。

ステップＳ１０６において、第１の認証装置１１は、ｗｅｂサーバー２０に対して、クライアント端末５１によるｗｅｂサービスの利用を許可する。このとき、アクセス先のＵＲＬを本来のアクセス先である「http://test-web.com」に変換する。アクセス先のＵＲＬが、第１の認証装置１１のＵＲＬ「http://test-web-win.com」のままだと、ｗｅｂサービスにおいて誤動作が生じる虞があるためである。アクセス先のＵＲＬを変換することにより、ｗｅｂサービスを正常に動作させることができる。

ステップＳ１０７において、ｗｅｂサーバー２０は、クライアント端末５１に対して、アクセス要求されたｗｅｂサービスを提供する。なお、クライアント端末５１は、第１の認証装置１１によって発行された認証Ｃｏｏｋｉｅを利用して、ｗｅｂサーバー２０が提供するｗｅｂサービスを含むＳＳＯ連携サービスを個別に認証処理することなく利用することができる。

図４は、本実施の形態の認証システムを利用した初回アクセス時の認証処理の一例を示すフローチャートである。図４は、ｗｅｂブラウザーがＳａｆａｒｉであるクライアント端末５２からアクセス要求が行われる場合の処理フローを示す。

ステップＳ２０１において、クライアント端末５２のＳａｆａｒｉは、ｗｅｂサーバー２０が提供するｗｅｂサービスへのアクセス要求を行う。当該ｗｅｂサービスのＵＲＬは、例えば「http://test-web.com」である。ＤＮＳサーバー５４によって、「http://test-web.com」に関連づけられているＩＰアドレスが判明し、アクセス要求は振分けサーバー３０に送信される。

ステップＳ２０２において、振分けサーバー３０は、アクセス要求を行ったｗｅｂブラウザーの種類を判別する。ここでは、アクセス要求を行ったｗｅｂブラウザーはＳａｆａｒｉである。

ステップＳ２０３、Ｓ２０４において、振分けサーバー３０は、Ｓａｆａｒｉに対応するＳＳＯ環境である第２の認証装置１２にアクセスするようにｗｅｂブラウザーに対して回答を行う。回答内容である第２の認証装置１２のＵＲＬは、振分けサーバー３０で管理される設定ファイルに基づき、例えば「http://test-web-form.com」となる。

ステップＳ２０５において、第２の認証装置１２は、Ｆｏｒｍ認証により認証を行う。具体的には、ＳＳＯサーバー１２２は、クライアント端末５２のＳａｆａｒｉにＦｏｒｍ認証用のログインフォーム画面を表示する。ユーザーがＦｏｒｍ認証情報（ログインＩＤ及びログインパスワード）を入力して送信することに伴い、第２の認証装置１２は、入力されたログインＩＤ及びログインパスワード情報とＯＳアカウント情報による照合を行い、照合が成立すると、クライアント端末５２のＩＥに対して認証Ｃｏｏｋｉｅを発行する。

ステップＳ２０６において、第２の認証装置１２は、ｗｅｂサーバー２０に対して、クライアント端末５２によるｗｅｂサービスの利用を許可する。このとき、アクセス先のＵＲＬを本来のアクセス先である「http://test-web.com」に変換する。アクセス先のＵＲＬが、第２の認証装置１２のＵＲＬ「http://test-web-form.com」のままだと、ｗｅｂサービスにおいて誤動作が生じる虞があるためである。アクセス先のＵＲＬを変換することにより、ｗｅｂサービスを正常に動作させることができる。

ステップＳ２０７において、ｗｅｂサーバー２０は、クライアント端末５２に対して、アクセス要求されたｗｅｂサービスを提供する。なお、クライアント端末５２は、第２の認証装置１２によって発行された認証Ｃｏｏｋｉｅを利用して、ｗｅｂサーバー２０が提供するｗｅｂサービスを含むＳＳＯ連携サービスを個別に認証処理することなく利用することができる。

実施の形態に係る認証システム１０は、アクセス制限されたｗｅｂサービスに対してクライアント端末５０のｗｅｂブラウザーからアクセス要求があった場合に、ＳＳＯにより認証を行う認証システムであって、クライアント端末５０のＯＳアカウント情報により認証を行う第１の認証装置１１と、ｗｅｂブラウザーにおいてログインフォームに入力されたＦｏｒｍ認証情報により認証を行う第２の認証装置１２と、ｗｅｂブラウザーの種類を判別し、当該ｗｅｂブラウザーがＩＥ（所定のｗｅｂブラウザー）である場合に第１の認証装置１１で認証が行われるように制御する一方、当該ｗｅｂブラウザーがＩＥでない場合に第２の認証装置１２で認証が行われるように制御する振分けサーバー３０と、を備える。

また、本実施の形態に係る認証方法は、アクセス制限されたｗｅｂサービスに対してクライアント端末５０のｗｅｂブラウザーからアクセス要求があった場合に、ＳＳＯにより認証を行う認証方法であって、（Ａ）ｗｅｂブラウザーの種類を判別する工程と、（Ｂ）工程Ａで判別されたｗｅｂブラウザーがＩＥ（所定のｗｅｂブラウザー）である場合に、クライアント端末５０のＯＳアカウント情報により認証を行う工程と、（Ｃ）工程Ａで判別されたｗｅｂブラウザーがＩＥでない場合に、ｗｅｂブラウザーにおいてログインフォームに入力されたＦｏｒｍ認証情報により認証を行う工程と、を備える。

実施の形態に係る認証システム１０及び認証方法によれば、予めｗｅｂブラウザーに対応付けられた第１の認証装置１１又は第２の認証装置１２が当該ｗｅｂブラウザーに適した認証処理を行う。したがって、ＯＳアカウント情報を利用したＳＳＯにより、アクセス制限されたｗｅｂサービスの認証を行う場合に生じる不具合（ＳＳＯ環境でサポートされていないｗｅｂブラウザーのハングアップ等）を、振分けサーバー３０を設けるだけで、既存のシステム基盤環境を大幅に変更することなく解消することができる。すなわち、ユーザーがｗｅｂブラウザーによる統合ｗｉｎｄｏｗｓ認証の可否を意識する必要のない、ｗｅｂブラウザーに依存しないＳＳＯ環境を構築することができる。

また、ネットワーク管理者は、本来的にアクセス権限のある全てのクライアント端末の構成ファイルを変更する必要はなく、さらにはｉＯＳが自動的にアップデートされても、それによる動作不良は生じない。

以上、本発明者によってなされた発明を実施の形態に基づいて具体的に説明したが、本発明は上記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で変更可能である。

例えば、本発明はｗｅｂブラウザーの種別に限定されないため、ＩＥ以外のｗｅｂブラウザーである、Ｓａｆａｒｉや、ＦｉｒｅＦｏｘ、ＧｏｏｇｌｅＣｈｒｏｍｅなどに、振分けサーバー３０で管理される設定ファイルを編集するだけで対応できる。

また、同一のｗｅｂブラウザーにおいて、バージョンごとに認証方式を振分ける必要がある場合に、振分けサーバー３０で管理される設定ファイルを編集するだけで対応できる。

将来的に新しいｗｅｂブラウザーが利用される場合においても、振分けサーバー３０で管理される設定ファイルを編集するだけで対応できる。

さらには、本発明を応用することにより、クライアント端末５０のＩＰアドレスやｗｅｂブラウザーの言語情報によって認証方式を振分けることが考えられ、この場合も振分けサーバー３０で管理される設定ファイルを編集するだけで対応できる。

また、リバースプロキシサーバー１１１、１２１をそれぞれ複数台用意し、それぞれの前段にロードバランサーを備えるようにしてもよい。これにより、クライアント端末５０からの処理要求を分散させ、一台当たりの負荷を低減することができる。

今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１０ 認証システム
１１ 第１の認証装置
１２ 第２の認証装置
１１１、１２１ リバースプロキシサーバー
１１２、１２２ ＳＳＯサーバー
２０ ｗｅｂサーバー
３０ 振分けサーバー
４０ アクティブディレクトリ
５０、５１〜５３ クライアント端末
５４ ＤＮＳサーバー
５５ ＶＰＮサーバー

Claims (4)

1. アクセス制限されたｗｅｂサービスに対してクライアント端末のｗｅｂブラウザーからアクセス要求があった場合に、ＳＳＯにより認証を行う認証システムであって、
   前記クライアント端末のＯＳアカウント情報により認証を行う第１の認証装置と、
   前記ｗｅｂブラウザーにおいてログインフォームに入力されたＦｏｒｍ認証情報により認証を行う第２の認証装置と、
   前記ｗｅｂブラウザーの種類を判別し、当該ｗｅｂブラウザーが所定のｗｅｂブラウザーである場合に前記第１の認証装置で認証が行われるように制御する一方、当該ｗｅｂブラウザーが前記所定のｗｅｂブラウザーでない場合に前記第２の認証装置で認証が行われるように制御する振分けサーバーと、を備えることを特徴とする認証システム。
2. 前記所定のｗｅｂブラウザーはｗｉｎｄｏｗｓ（登録商標）の標準ブラウザーであり、
   前記第１の認証装置は、統合ｗｉｎｄｏｗｓ認証により認証を行うことを特徴とする請求項１に記載の認証システム。
3. 前記ｗｅｂブラウザーは、インターネットから、ＶＰＮサーバーを介して、前記ｗｅｂサービスにアクセスすることを特徴とする請求項１又は２に記載の認証システム。
4. アクセス制限されたｗｅｂサービスに対してクライアント端末のｗｅｂブラウザーからアクセス要求があった場合に、ＳＳＯにより認証を行う認証方法であって、
   （Ａ）前記ｗｅｂブラウザーの種類を判別する工程と、
   （Ｂ）前記工程Ａで判別されたｗｅｂブラウザーが所定のｗｅｂブラウザーである場合に、前記クライアント端末のＯＳアカウント情報により認証を行う工程と、
   （Ｃ）前記工程Ａで判別されたｗｅｂブラウザーが前記所定のｗｅｂブラウザーでない場合に、前記ｗｅｂブラウザーにおいてログインフォームに入力されたＦｏｒｍ認証情報により認証を行う工程と、を備えることを特徴とする認証方法。

Images