JP2003296277A - ネットワーク装置、認証サーバ、ネットワークシステム、認証方法 - Google Patents

Abstract

(57)【要約】 【課題】 ＷＷＷ上で複数のサービスに対してシングル
サインオン機能を提供する際に、より安全に通信が可能
なネットワークシステムを提供する。 【解決手段】 ＷＷＷブラウザ２からＳＳＯサーバ６へ
アクセスし、利用者の認証を行った後にＷＷＷアプリケ
ーション４へアクセスを行う。ＷＷＷアプリケーション
４はＳＳＯサーバ６へ利用者の認証状況を問い合わせ、
認証済の利用者であればＷＷＷアプリケーション４専用
の認証チケットを発行し、以後、その認証チケットを利
用してＷＷＷアプリケーション４のサービスを受ける。
次にＷＷＷアプリケーション５へアクセスすると、ＷＷ
Ｗアプリケーション５はＳＳＯサーバ６へ問い合わせ、
利用者が認証済である旨を受けてＷＷＷアプリケーショ
ン５専用の認証チケットを発行する。このようにＷＷＷ
アプリケーション毎の認証チケットを発行するので、認
証チケット広範囲に漏れることはない。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、クライアントがネ
ットワークを通じてサービスを利用する際の認証技術に
関するものであり、特に、シングルサインオン（Ｓｉｎ
ｇｌｅ ＳｉｇｎＯｎ：ＳＳＯ）技術に関するものであ
る。

【０００２】

【従来の技術】クライアントがネットワークを通じてサ
ービスを利用する場合、そのサービスを利用する権限を
有していることを確認するため、ユーザ名やパスワード
の入力によるサインを行う。シングルサインオンは、ク
ライアントがただ一度のサイン（ユーザ名，パスワード
入力）を行うことで複数アプリケーションの利用を可能
にするものである。

【０００３】シングルサインオンを実現する従来の方法
の一つとして、例えばクライアント側で用いているブラ
ウザにおいて、アプリケーション毎のサイン（ユーザ
名，パスワード）を保持する方法がある。しかし、この
ような機能を有していないブラウザもあり、汎用的に利
用できる技術ではない。

【０００４】別の方法として、例えばクライアントから
のアクセスを受け付けるログイン代理サーバを設け、こ
のログイン代理サーバを通じて各種のサービスを提供す
る方法がある。この場合、ログイン代理サーバに対して
１回のサイン（ユーザ名，パスワード入力）のみで、各
種のサービスを利用することが可能である。例えば特開
２０００−１０６５５２号公報などにおいても、窓口と
なるＷｅｂサーバを設け、そのＷｅｂサーバを通じて各
種の業務サーバを利用する構成が採用されている。

【０００５】このようなログイン代理サーバを利用する
方法では、すべてのアクセスがログイン代理サーバに対
して行われる。そのため、ログイン代理サーバにおける
トラフィック量が非常に多くなるとともに、ログイン代
理サーバがダウンしたときにはいずれのサービスも全く
利用することができなくなってしまうという問題があ
る。

【０００６】さらに別の方法として、認証チケットを利
用する方法がある。この方法では、チケットセンターが
クライアントの認証を行った際に、利用可能なサービス
に対する認証チケットを発行する。そして、クライアン
トがサービスを利用する際には、当該サービスに対して
認証チケットを提示し、サービスの提供を受ける。この
方法の場合にも、チケットセンターから認証チケットを
受け取る際に１回のサイン（ユーザ名，パスワード入
力）のみで複数のサービスを利用することができる。

【０００７】このような認証チケットを利用する方式と
しては、Ｋｅｒｂｅｒｏｓ認証が代表的である。しか
し、Ｋｅｒｂｅｒｏｓ認証はＷＷＷ（Ｗｏｒｌｄ Ｗｉ
ｄｅＷｅｂ）における方式ではないため、そのままでは
利用することができない。このＫｅｒｂｅｒｏｓ認証方
式をＷＷＷに適用する場合、認証チケットとしてクッキ
ー（Ｃｏｏｋｉｅ）を利用することになる。クッキー
は、ＷＷＷにおいてＨＴＴＰのような接続状態を管理し
ない通信プロトコルを用いる場合に、クライアント（あ
るいはクライアントで用いられているＷＷＷブラウザ）
と、サービス（あるいはサーバ等のネットワーク装置で
動作しているＷＷＷアプリケーション）間でセッション
を管理するために用いられる。すなわち、クライアント
からＷＷＷ上のサービスをＨＴＴＰにより利用する場合
には、ＨＴＴＰで規定されるクッキーを用いてセッショ
ン管理を行うとともに、当該クッキーを認証チケットと
して用いることになる。

【０００８】１つの認証チケットによって複数のサービ
スの提供を受けるには、認証チケットに利用可能なサー
ビスの一覧を記述しておくことになる。クッキーを用い
た場合には、ドメインを指定することによって複数のサ
ービスを利用可能とすることができる。しかし、指定さ
れたドメイン内には利用するサービス以外にも様々なＷ
ＷＷアプリケーションが存在しており、悪意のＷＷＷア
プリケーションに認証チケットとして利用するクッキー
が提示されることも考えられる。この場合、悪意のＷＷ
Ｗアプリケーションは提示されたクッキー（認証チケッ
ト）を利用して、無制限に他のサービスを利用可能とな
ってしまう。このように、従来の認証チケットによる認
証方法は、認証チケットの盗用が起こりやすく、セキュ
リティレベルが低いという問題があった。

【０００９】

【発明が解決しようとする課題】本発明は、上述した事
情に鑑みてなされたもので、ＷＷＷ上で複数のサービス
に対してシングルサインオン機能を提供する際に、より
安全に通信が可能なネットワークシステムと、当該ネッ
トワークシステムで利用可能なネットワーク装置及び認
証サーバ、及び通信時に利用する認証方法を提供するこ
とを目的とするものである。

【００１０】

【課題を解決するための手段】本発明では、クライアン
トがサービス（ネットワーク装置）に最初にアクセスし
たときには、認証サーバによる認証を受けることにな
る。その後、クライアントからアクセスされたサービス
が認証サーバにクライアントの認証結果を問い合わせ、
認証済であれば、サービスからクライアントに当該サー
ビスを利用する際の認証チケットを発行する。以後、そ
の認証チケットを利用して当該サービスを利用すること
になる。別のサービスを利用する場合には、認証サーバ
によるクライアントの認証を行わず、当該別のサービス
からのクライアントの認証結果の問い合わせに対して認
証サーバが認証済を返し、当該別のサービスが当該別の
サービスを利用する際の別の認証チケットを発行する。

【００１１】このようにして、クライアントは認証サー
バにおいて１回の認証を行うのみにより複数のサービス
を利用することができる。また、複数のサービスを利用
する際には、それぞれのサービスがそれぞれ認証チケッ
トを発行する。例えばＨＴＴＰ等では、認証チケットは
発行したサービスにのみ提示されるため、従来のように
ドメインの指定のような包括的な認証チケットと異な
り、他のサービスに認証チケットが提示されることがな
い。従って、悪意のＷＷＷアプリケーションに認証チケ
ットが提示されて、なりすましによるサービスの利用を
防止することができる。

【００１２】また、クライアントと各サービスの間、及
びクライアントと認証サーバの間の通信は、例えばＣＨ
ＡＰ（Ｃｈａｌｌｅｎｇｅ Ｈａｎｄｓｈａｋｅ Ａｕ
ｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を用い
ることができる。これによって、例えば認証チケットが
盗まれたとしても、安全に通信を行うことができる。さ
らにＳＳＬ認証（例えばＳＳＬサーバ認証）などを用い
て行うことによって、例えば盗聴などによる認証チケッ
トの漏洩も防ぐことができる。

【００１３】なお、クライアントの認証を行う際には、
クライアントが直接認証サーバにアクセスするほか、ク
ライアントが利用したいサービスに未ログインのままア
クセスした場合に、例えばリダイレクションなどによっ
てサービスから認証サーバに対してクライアントの認証
を依頼するように構成することができる。これによっ
て、クライアントは認証サーバを意識することなく各サ
ービスを利用することができる。

【００１４】また、クライアントに対して提供可能な前
記サービス中の機能（ケイパビリティ）についても認証
サーバで管理し、サービスに対してクライアントのケイ
パビリティの判断結果（ケイパビリティの情報）を返す
ように構成することもできる。さらに、サービスにおい
てクライアントのライセンス認証が必要な場合に、当該
クライアントのライセンス認証を行うように構成するこ
ともできる。

【００１５】

【発明の実施の形態】図１は、本発明の第１の実施の形
態を示すシステム構成図である。図中、１はネットワー
ク、２，３はＷＷＷブラウザ、４，５はＷＷＷアプリケ
ーション、６はＳＳＯサーバ、１１は通信制御部、１２
は処理部、２１は認証部、２２は個人情報管理データベ
ースである。図１に示す例では、ＷＷＷブラウザ２，
３、ＷＷＷアプリケーション４，５、ＳＳＯサーバ６な
どがネットワーク１を利用して通信可能に構成されてい
る。もちろん、多くのＷＷＷブラウザ、多くのＷＷＷア
プリケーション、その他多くのサーバ等と通信可能であ
る。ネットワーク１は、ＬＡＮやインターネットなど、
各種のネットワークで構成することができ、またそれら
が複合的に組み合わされた構成であってよい。

【００１６】ＷＷＷブラウザ２，３は、ネットワーク１
を通じて、例えばＨＴＴＰなどによりＷＷＷアプリケー
ション４，５やＳＳＯサーバ６などと通信を行い、利用
者の指示に従って様々なサービス、情報の提供を受ける
クライアントとして機能する。ＷＷＷブラウザ２，３
は、例えばコンピュータなどの上で動作するソフトウェ
アであり、一般的に利用されているものである。もちろ
ん携帯端末などのようにブラウザとして独立したソフト
ウェアでない場合もあるが、そのような場合も含め、以
下の説明ではクライアントの具体例としてＷＷＷブラウ
ザ２，３を例示している。

【００１７】ＷＷＷアプリケーション４，５は、クライ
アントに対して各種のサービスを提供する。またＷＷＷ
アプリケーション４，５も、例えばコンピュータなどの
ネット枠装置（サーバ）上でクライアントにサービスを
提供するソフトウェアである。ここでは、クライアント
に対して提供されるサービスに対応するものとして、Ｗ
ＷＷアプリケーション４，５を示している。なお、ここ
ではＷＷＷアプリケーション４，５は、接続状態を管理
しない通信プロトコルＨＴＴＰを用いてＷＷＷブラウザ
との間の通信を行うものとする。また、ＷＷＷアプリケ
ーション４，５は、サービスの提供にはユーザの認証を
必要とするものとしている。

【００１８】ＷＷＷアプリケーション４は、通信制御部
１１及び処理部１２を含んで構成されている。ＷＷＷア
プリケーション５については図示していないが、同様の
構成を含んで構成することができる。処理部１２は、実
際にサービスを提供する部分である。通信制御部１１
は、ネットワーク１を通じてＷＷＷブラウザ２，３から
のアクセスを受け付けて、対応する処理を行う。例えば
未ログインのＷＷＷブラウザ２，３からのアクセスを受
けた際には、ＳＳＯサーバ６に問い合わせを行い、ＷＷ
Ｗブラウザの利用者が認証済であれば、当該ＷＷＷアプ
リケーション４へのアクセスのための認証チケット（ク
ッキー）を発行する。また、ログイン済のＷＷＷブラウ
ザ２，３からのアクセス時には、先に発行した認証チケ
ットを受け取って、処理部１２にサービスを行わせる。
なお、未ログインのＷＷＷブラウザ２，３からのアクセ
スを受けた際に、ＳＳＯサーバ６へのリダイレクション
によりＳＳＯサーバ６による認証を受けさせた後に、Ｓ
ＳＯサーバ６への問い合わせを行うように構成すること
ができる。

【００１９】ＳＳＯサーバ６は、ＷＷＷブラウザ２，３
からのアクセスに対応して利用者の認証を行うととも
に、ＷＷＷアプリケーション４，５などからの要求に応
じてクライアントの認証結果を返す認証サーバとして機
能する。ＳＳＯサーバ６は、認証部２１及び個人情報管
理データベース２２を含んで構成されている。個人情報
管理データベース２２には、それぞれの利用者毎の認証
情報、例えばユーザＩＤ及びパスワードなどの情報が登
録されている。

【００２０】認証部２１は、ＷＷＷブラウザ２，３から
のアクセスに対して認証処理を行うとともに、ＷＷＷア
プリケーション４，５からの問い合わせに応じて認証結
果の返送などを行う。ＷＷＷブラウザ２，３からのアク
セスを受けたとき、ＷＷＷブラウザ２，３の利用者が未
認証である場合には、ＷＷＷブラウザに対して認証フォ
ームを送信して利用者によるユーザＩＤやパスワードな
どの入力情報を受け取る。そして、その入力情報に基づ
いて個人情報管理データベース２２への問い合わせを行
って、利用者の認証を行う。このとき、ＳＳＯサーバ６
に対してのみ有効なクッキーを発行しておく。また、認
証済の利用者によるＷＷＷブラウザ２，３からのアクセ
スに対しては、ＷＷＷブラウザに対して認証フォームを
送信することはせず、従って利用者によるユーザＩＤや
パスワードなどの入力情報の入力や、認証の処理などを
行わない。この認証済の状態は、所定の時間、あるいは
ＷＷＷブラウザ２，３のセッションの終了まで保持され
る。ＷＷＷブラウザ２，３からのアクセス時に認証済で
あるか否かは、アクセス時に発行済みのクッキーが渡さ
れること、及び、内部における認証済の情報などによっ
て判断することができる。

【００２１】なお、この例では個人情報管理データベー
ス２２をＳＳＯサーバ６内に設けるように図示している
が、これに限らず、ＳＳＯサーバ６とは別のサーバによ
り構成することも可能である。また、それぞれの構成要
素は実際の装置構成と一致しない場合もある。例えばそ
れぞれのＷＷＷアプリケーションがそれぞれ１台のコン
ピュータに対応している必要はないし、ＳＳＯサーバも
独立したコンピュータとして構成されている必要はな
い。

【００２２】次に、本発明の第１の実施の形態における
動作について、ＷＷＷブラウザに表示される画面の具体
例などを用いながら説明する。なお、以下の動作の説明
では、利用者がＷＷＷブラウザ２を利用しているものと
し、最初にＷＷＷアプリケーション４を利用し、その
後、ＷＷＷアプリケーション５を利用するものとしてい
る。また、利用するプロトコルはＨＴＴＰである。

【００２３】図２は、本発明の第１の実施の形態におけ
る動作の一例を示すシーケンス図、図３は、同じくＷＷ
Ｗアプリケーションへの最初のアクセスを行った際の動
作の一例の説明図である。ＷＷＷブラウザ２を利用して
いる利用者は、ＷＷＷアプリケーション４を利用する場
合には、ＷＷＷアプリケーション４のＵＲＬ（ｕｒｌ
１）を（１）において入力し、アクセスを指示する。す
るとＷＷＷブラウザ２は、（２）においてＷＷＷアプリ
ケーション４へのアクセスを行う。このときのＨＴＴＰ
の要求メッセージでは“ＧＥＴ”メソッドを用い、例え
ば“ＧＥＴ ｕｒｌ１ ＨＴＴＰ／１．ｘ”といった要
求メッセージをＷＷＷアプリケーション４へ送る。

【００２４】ＷＷＷアプリケーション４は、ＷＷＷブラ
ウザ２からのアクセスを受けると、ＷＷＷブラウザ２と
の間にセッションが存在するか否かを判断する。セッシ
ョンの有無は、ＷＷＷアプリケーション４内に保持して
いるセッションオブジェクトとして登録されているか否
かを判断するなど、任意の方法によって行えばよい。こ
こではそれまでにＷＷＷブラウザ２との間にセッション
が存在しない。この場合には、新たに例えば一時的なＩ
Ｄを割り当て、セッションオブジェクトとして登録して
おく。

【００２５】ＷＷＷアプリケーション４は、ＷＷＷブラ
ウザ２とのセッションが存在していなかったので、ＷＷ
Ｗブラウザ２に対してＳＳＯサーバ６による認証を行う
ように促す。ここでは（３）において、ＳＳＯサーバ６
へのリダイレクションをＷＷＷブラウザ２に対して指示
する。具体的には、ＳＳＯサーバ６のＵＲＬをｓｓｏと
するとき、応答時のコード“３０２”を用い、応答メッ
セージとして例えば“ＨＴＴＰ／１．ｘ ３０２ Ｍｏ
ｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ Ｌｏｃａｔｉｏｎ：
ｓｓｏ＋ｉｄ”などとして、リダイレクションによりア
クセスするように応答すればよい。なお、“ｓｓｏ＋ｉ
ｄ”は、ＳＳＯサーバ６のＵＲＬ“ｓｓｏ”に、ＷＷＷ
アプリケーション４が一時的に発行したＩＤを付加した
ものである。さらに、ＷＷＷアプリケーション４のＵＲ
Ｌも付加しておくとよい。また、応答時にＷＷＷアプリ
ケーション４用の仮のクッキーをＷＷＷブラウザ２に送
っておいてもよい。

【００２６】ＷＷＷブラウザ２は、上述のようなＷＷＷ
アプリケーション４からの応答メッセージを受けると、
自動的に（４）においてＳＳＯサーバ６に対してアクセ
スを行う。図４は、ＳＳＯサーバ６へのリダイレクショ
ン時の表示画面の一例の説明図である。ＷＷＷブラウザ
２がＷＷＷアプリケーション４から（３）における応答
メッセージを受け取ると、ＷＷＷブラウザ２によって図
４に示すような表示が行われる。このような表示が行わ
れても、利用者は特段の操作を要せず、自動的にＳＳＯ
サーバ６に対してのアクセスが行われる。自動的にＳＳ
Ｏサーバ６にアクセスされない場合には、下線が付され
た“ｈｅｒｅ”の部分を利用者が指示することによっ
て、ＳＳＯサーバ６へのアクセスを行うことができる。
このようなリダイレクションを利用することによって、
ユーザはＳＳＯサーバ６のＵＲＬ等を知らなくても、利
用したいＷＷＷアプリケーションにアクセスすれば、初
回はＳＳＯサーバ６へ自動的にアクセスされるので、利
便性を向上させることができる。

【００２７】（４）において自動的に行われるＷＷＷブ
ラウザ２からＷＷＷアプリケーション４へのアクセス時
の要求メッセージは、具体的には“ＧＥＴ”メソッドを
用い、アドレス部分は（３）で渡された“Ｌｏｃａｔｉ
ｏｎ：”以降の部分、すなわち“ｓｓｏ＋ｉｄ”であ
る。例えば“ＧＥＴ ｓｓｏ＋ｉｄ ＨＴＴＰ／１．
ｘ”といった要求メッセージがＷＷＷブラウザ２からＷ
ＷＷアプリケーション４へ渡される。なお、アドレス部
分にＷＷＷアプリケーション４のＵＲＬが含まれる場合
もある。

【００２８】ＳＳＯサーバ６では、ＷＷＷブラウザ２か
らのアクセスを受けた場合、この時点ではいままでにＷ
ＷＷブラウザ２とのセッションはなく、認証を行ってい
ない。従って新規にセッションを生成し、内部にセッシ
ョンオブジェクトとして登録しておく。このとき、アド
レス部分で渡された、ＷＷＷアプリケーション２で生成
したＩＤを用いることができる。また、アドレス部分に
ＷＷＷアプリケーション４のＵＲＬが含まれる場合、そ
のＵＲＬも保持しておく。

【００２９】新たにＷＷＷブラウザ２からアクセスされ
た場合、ＳＳＯサーバ６は、（５）において、認証を行
うための認証フォームをＷＷＷブラウザ２へ送る。具体
的には応答コード“２００”を用い、例えば応答ヘッダ
“ＨＴＴＰ／１．ｘ ２００ＯＫ”と、認証フォームの
データを応答メッセージとしてＷＷＷブラウザ２に送信
すればよい。このとき、ＳＳＯサーバ６用の仮のクッキ
ーを送信しておいてもよい。

【００３０】図５は、認証フォーム画面の一例の説明図
である。ＷＷＷブラウザ２では、ＳＳＯサーバ６から送
られてきた認証フォームのデータを表示することによっ
て、例えば図５に示すような画面が利用者に提示され
る。この画面では、ユーザＩＤ（ｕｉｄ）の入力欄とパ
スワード（ｐｗｄ）の入力欄が設けられている。利用者
は、これらの欄にユーザＩＤ及びパスワードを入力（図
２，図３の（６））したのち、「クエリ送信」ボタンを
操作すればよい。これによって、図２，図３の（７）に
おいて、利用者が入力したユーザＩＤ及びパスワードが
ＷＷＷブラウザ２からＷＷＷアプリケーション４へ送ら
れる。

【００３１】ＷＷＷブラウザ２からＷＷＷアプリケーシ
ョン４へユーザＩＤ及びパスワードを送信する場合の具
体的な要求メッセージは、“ＰＯＳＴ”メソッドを用
い、例えばリクエストラインとして“ＰＯＳＴ ｓｓｏ
ＨＴＴＰ／１．ｘ”、ボディ部に利用者が入力したユ
ーザＩＤ及びパスワードを含めればよい。

【００３２】ＷＷＷアプリケーション４は、ＷＷＷブラ
ウザ２からユーザＩＤおよびパスワードを受け取ると、
（８）において、個人情報管理データベース２２への問
い合わせを行い、（９）においてその結果を受け取る。
ユーザＩＤとパスワードが正しくなければ、認証できな
かった旨をＷＷＷブラウザ２に通知し、再入力を受ける
かあるは処理を終了する。

【００３３】受け取ったユーザＩＤとパスワードが正し
ければ、ＷＷＷブラウザ２の利用者を正規の利用者とし
て認証する。このとき、ＳＳＯサーバ６へのログインが
行われ、ログイン済である状態が利用者のユーザＩＤと
ともにセッションオブジェクトとして登録される。な
お、（４）におけるセッション開始時のセッションオブ
ジェクトが修正されることになる。

【００３４】ＳＳＯサーバ６へのログインが行われた
ら、（１０）において、ＳＳＯサーバ６はＷＷＷブラウ
ザ２に対して応答メッセージを返す。この応答メッセー
ジとともに、ＳＳＯサーバ６への認証チケット（クッキ
ー）をＷＷＷブラウザ２に対して発行する。図６は、Ｓ
ＳＯサーバ６への認証チケットの一例の説明図である。
図６に示す例において、“Ｃｏｏｋｉｅ情報”中の“ド
メイン”欄及び“パス”欄において、ＳＳＯサーバ６の
ドメイン及びパスが記述されており、ＳＳＯサーバ６に
対してのみ提示されることを示している。従って、この
認証チケットでは、ＷＷＷアプリケーション４を利用す
ることはできない。なお、この認証チケット（クッキ
ー）には、利用者のユーザＩＤを含めておくとよい。こ
の時点では、ＳＳＯサーバ６はＷＷＷアプリケーション
４への認証チケットは発行しない。

【００３５】（１０）における応答メッセージは、この
例ではリダイレクションによりＷＷＷアプリケーション
４にアクセスが行われるようにしている。これは、もと
もと利用者はＷＷＷアプリケーション４へのアクセスを
行っており、利用者が知らずにＳＳＯサーバ６へのアク
セスが行われている。従って、ＳＳＯサーバ６における
処理が終了した時点で自動的にＷＷＷアプリケーション
４へ戻ることが望ましい。これを実現するため、ＳＳＯ
サーバ６における認証の処理が終了した（１０）の応答
メッセージにおいて、ＷＷＷアプリケーション４へのリ
ダイレクションによりＷＷＷアプリケーション４に戻し
ている。具体的には、応答コード“３０２”を使用し、
例えば“ＨＴＴＰ／１．ｘ ３０２ Ｍｏｖｅｄ Ｔｅ
ｍｐｏｒａｒｉｌｙ Ｌｏｃａｔｉｏｎ：ｕｒｌ１”と
し、ＷＷＷアプリケーション４のＵＲＬ（“ｕｒｌ
１”）を指定したリダイレクションをＷＷＷブラウザ２
に指示すればよい。

【００３６】図７は、ＷＷＷアプリケーション４へのリ
ダイレクション時の表示画面の一例の説明図である。Ｗ
ＷＷブラウザ２は、図２，図３の（１０）におけるＳＳ
Ｏサーバ６からの応答メッセージを受けると、図７に示
すような表示がなされる。この画面は図４に示した画面
とほぼ同様であるが、アドレス欄がＳＳＯサーバ６のア
ドレスとなっており、ＳＳＯサーバ６からのものである
ことが分かる。

【００３７】上述のリダイレクションによって、図２，
図３の（１１）において、今度はＷＷＷアプリケーショ
ン４へのアクセスが自動的に行われる。このとき、例え
ば上述の（３）においてＷＷＷアプリケーション４から
仮のクッキーが渡されている場合には、そのクッキーも
送信される。ＷＷＷアプリケーション４はＷＷＷブラウ
ザ２からのアクセスを受けると、既にセッションが存在
するか否かを判定する。クッキーが送られてくる場合に
はそのクッキーでも判断できるし、セッションオブジェ
クトを調べることによっても判断することができる。こ
の例の場合には、（２）におけるＷＷＷブラウザ２から
のアクセス時のセッションが存在している。従って（１
１）のアクセス時にはセッションの存在が判定される。

【００３８】既にセッションが存在するアクセスを受け
た場合、認証チケットが提示されているか否かをさらに
判定する。この時点ではＷＷＷブラウザ２はＷＷＷアプ
リケーション４に対する認証チケットを入手していない
ので、ＷＷＷブラウザ２からは認証チケットは提示され
ない。認証チケットが提示されない場合、（１２）にお
いて、ＷＷＷアプリケーション４はＳＳＯサーバ６に対
してＷＷＷブラウザ２の利用者の認証状況を問い合わせ
る。このとき、（４）におけるリダイレクションによる
ＷＷＷブラウザ２からＳＳＯサーバ６へのアクセス時
に、ＷＷＷアプリケーション４が（３）でＷＷＷブラウ
ザ２に渡した一時的なＩＤ（ｉｄ）をＳＳＯサーバ６に
対して渡しており、ＳＳＯサーバ６においてもセッショ
ンオブジェクトとして登録している。これを利用するた
め、（１２）では先にＷＷＷブラウザ２に発行した一時
的なＩＤ（ｉｄ）をＳＳＯサーバ６に渡して、認証状況
の問い合わせを行う。

【００３９】ＳＳＯサーバ６では、ＷＷＷアプリケーシ
ョン４からの問い合わせに応じ、セッションオブジェク
トを検索することによって受け取った一時的なＩＤから
利用者を割り出し、当該利用者が認証済であるか否かを
判断する。認証済であればその旨を（１３）においてＷ
ＷＷアプリケーション４に返す。ここでは、利用者のユ
ーザＩＤをＷＷＷアプリケーション４に通知する。

【００４０】ＷＷＷアプリケーション４は、ＳＳＯサー
バ６から利用者が認証済である旨の通知を受け取ると、
当該利用者をログイン済としてセッションオブジェクト
を登録する。そして（１４）において、ＷＷＷブラウザ
２に対して応答メッセージを返す。具体的には応答コー
ド“２００”を用い、例えば応答ヘッダ“ＨＴＴＰ／
１．ｘ ２００ ＯＫ”と、例えばＷＷＷアプリケーシ
ョン４のホームページのデータをボディ部として送信す
ればよい。図８は、ＷＷＷアプリケーション４へのログ
イン時の表示画面の一例の説明図である。この例では、
ＷＷＷアプリケーション４のホームページとして、“Ｈ
ｅｒｅ ｉｓ Ａｐｐｌｉｃａｔｉｏｎ．”が表示され
ている。

【００４１】この（１４）の応答メッセージをＷＷＷブ
ラウザ２に対して送信する際に、ＷＷＷアプリケーショ
ン４のみに有効な認証チケット（クッキー）をＷＷＷブ
ラウザ２に対して発行する。図９は、ＷＷＷアプリケー
ション４への認証チケットの一例の説明図である。図９
に示す例において、“Ｃｏｏｋｉｅ情報”中の“ドメイ
ン”欄及び“パス”欄においてＷＷＷアプリケーション
４のドメイン及びパスが記述されており、ＷＷＷアプリ
ケーション４のみに適用される認証チケットであること
が明示されている。従って、この認証チケットでは、Ｗ
ＷＷアプリケーション４のみ利用可能である。

【００４２】以後、ＷＷＷブラウザ２からＷＷＷアプリ
ケーション４へのアクセスが行われる際には（１４）で
受け取った認証チケットがＷＷＷアプリケーション４に
提示される。図１０は、本発明の第１の実施の形態にお
けるＷＷＷアプリケーションへの２回目以降のアクセス
を行った際の動作の一例の説明図である。図２とともに
図１０を参照しながら説明してゆく。例えば上述のよう
にしてＷＷＷアプリケーション４に対する最初のアクセ
スを行った後、（１５）において利用者がＷＷＷブラウ
ザ２に対してＷＷＷアプリケーション４へのアクセスを
再び指示すると、（１６）においてＷＷＷブラウザ２か
らＷＷＷアプリケーション４へ要求メッセージが渡され
る。このとき、上述の（１４）で受け取った認証チケッ
トがＷＷＷアプリケーション４に提示される。ＷＷＷア
プリケーション４では、ＷＷＷブラウザ２からのアクセ
スを受け、認証チケットを受け取ると、ＳＳＯサーバ６
への問い合わせなどを行わずに、処理部１２によって要
求された処理を行い、処理結果を（１７）においてＷＷ
Ｗブラウザ２に返す。このようにして、以後はＷＷＷア
プリケーション４によるサービスを受けることができ
る。

【００４３】次に、今度は利用者は別のサービスとして
ＷＷＷアプリケーション５を利用したいとする。以下、
上述のようにしてＷＷＷアプリケーション４を利用した
後に、ＷＷＷアプリケーション５を利用する場合の動作
の一例について説明してゆく。図１１は、本発明の第１
の実施の形態における別のＷＷＷアプリケーションへの
アクセスを行った際の動作の一例の説明図である。以
下、図２とともに図１１を用いて説明してゆく。ＷＷＷ
ブラウザ２の利用者は、ＷＷＷアプリケーション５を利
用する場合には、ＷＷＷアプリケーション５のＵＲＬ
（ｕｒｌ２）を（２１）において入力し、アクセスを指
示する。するとＷＷＷブラウザ２は、（２２）において
ＷＷＷアプリケーション５へのアクセスを行う。具体的
には、例えば“ＧＥＴ ｕｒｌ２ ＨＴＴＰ／１．ｘ”
といった要求メッセージをＷＷＷアプリケーション５へ
送る。

【００４４】ＷＷＷアプリケーション５は、ＷＷＷブラ
ウザ２からのアクセスを受けると、ＷＷＷブラウザ２と
の間にセッションが存在するか否かを判断する。この時
点では、ＷＷＷアプリケーション５はＷＷＷブラウザ２
との間にセッションは存在していない。この場合には、
新たに例えば一時的なＩＤを割り当て、セッションオブ
ジェクトとして登録しておく。

【００４５】ＷＷＷアプリケーション５は、ＷＷＷブラ
ウザ２とのセッションが存在していないので、上述のよ
うに（２３）において、ＳＳＯサーバ６へのリダイレク
ションをＷＷＷブラウザ２に対して指示する。ＷＷＷブ
ラウザ２は、ＷＷＷアプリケーション５からの応答メッ
セージを受けると、自動的に（２４）においてＳＳＯサ
ーバ６に対してアクセスを行う。図１２は、ＳＳＯサー
バ６へのリダイレクション時の表示画面の一例の説明図
である。ＷＷＷブラウザ２がＷＷＷアプリケーション５
から（２３）における応答メッセージを受け取ると、Ｗ
ＷＷブラウザ２によって図１２に示すような表示が行わ
れる。この表示は図４や図７と同様であるが、アドレス
欄のＵＲＬがＷＷＷアプリケーション５のものとなって
いる。このような表示が行われても、利用者は特段の操
作を要せず、自動的にＳＳＯサーバ６に対してのアクセ
スが行われる。

【００４６】（２４）において自動的に行われるＷＷＷ
ブラウザ２からＷＷＷアプリケーション５へのアクセス
時の要求メッセージは、具体的には例えば“ＧＥＴ ｓ
ｓｏ＋ｉｄ ＨＴＴＰ／１．ｘ”などのように、ＳＳＯ
サーバ６のＵＲＬとともに、ＷＷＷアプリケーション５
がＷＷＷブラウザ２に対して割り当てた一時的なＩＤ
（ｉｄ）が含まれるようにしておく。

【００４７】この（２４）におけるＷＷＷブラウザ２か
らＷＷＷアプリケーション５へのアクセスの際に、ＷＷ
Ｗアプリケーション４を利用したときにＳＳＯサーバ６
から（１０）で受け取った認証チケット（クッキー）が
ＳＳＯサーバ６に対して提示される。ＳＳＯサーバ６で
は、ＷＷＷブラウザ２からのアクセス時に認証チケット
が提示されたことによって、当該ユーザは認証済である
とし、改めて利用者の認証を行うことはしない。従っ
て、ＷＷＷブラウザ２に対して認証フォームを送った
り、個人情報管理データベース２２への問い合わせなど
は行わない。

【００４８】ＳＳＯサーバ６は、提示された認証チケッ
トからユーザＩＤを取り出し、ＷＷＷアプリケーション
５で付与された一時的なＩＤとともにセッションオブジ
ェクトを登録する。そして、（２５）においてＷＷＷブ
ラウザ２に対して応答メッセージを返す。この場合も応
答メッセージはＷＷＷアプリケーション５へのリダイレ
クションを指示する。具体的な応答メッセージは上述の
（１０）と同様であり、指定するＵＲＬがＷＷＷアプリ
ケーション５のＵＲＬ（ｕｒｌ２）となる。図１３は、
ＷＷＷアプリケーション５へのリダイレクション時の表
示画面の一例の説明図である。ＷＷＷブラウザ２は、図
２，図１１の（２５）におけるＳＳＯサーバ６からの応
答メッセージを受けると、図１３に示すような表示がな
される。この画面は図７に示した画面とほぼ同様であ
る。

【００４９】上述のリダイレクションによって、図２，
図１１の（２６）において、今度はＷＷＷアプリケーシ
ョン５へのアクセスが自動的に行われる。このとき、例
えば上述の（２３）においてＷＷＷアプリケーション５
から仮のクッキーが渡されている場合には、そのクッキ
ーも送信される。ＷＷＷアプリケーション５はＷＷＷブ
ラウザ２からのアクセスを受けると、既にセッションが
存在するか否かを判定する。クッキーが送られてくる場
合にはそのクッキーでも判断できるし、セッションオブ
ジェクトを調べることによっても判断することができ
る。この例の場合には、（２２）におけるＷＷＷブラウ
ザ２からのアクセス時のセッションが存在している。従
って（２６）のアクセス時にはセッションの存在が判定
される。しかし、ＷＷＷブラウザ２は、まだＷＷＷアプ
リケーション５の認証チケットを入試していないため、
ＷＷＷアプリケーション５には認証チケットが提示され
ない。そのため、ＷＷＷアプリケーション５は（２７）
においてＳＳＯサーバ６に対してＷＷＷブラウザ２の利
用者の認証状況を問い合わせる。このとき、（２３）で
ＷＷＷブラウザ２に発行した一時的なＩＤ（ｉｄ）をＳ
ＳＯサーバ６に渡して、認証状況の問い合わせを行う。

【００５０】ＳＳＯサーバ６では、ＷＷＷアプリケーシ
ョン５からの問い合わせに応じ、セッションオブジェク
トを検索することによって受け取った一時的なＩＤから
利用者を割り出し、当該利用者が認証済であるか否かを
判断する。認証済であればその旨を（２８）においてＷ
ＷＷアプリケーション５に返す。ここでは、利用者のユ
ーザＩＤをＷＷＷアプリケーション５に通知する。

【００５１】ＷＷＷアプリケーション５は、ＳＳＯサー
バ６から利用者が認証済である旨の通知を受け取ると、
当該利用者をログイン済としてセッションオブジェクト
を登録する。そして（２９）において、ＷＷＷブラウザ
２に対して応答メッセージを返す。このとき、例えばＷ
ＷＷアプリケーション５のホームページのデータをボデ
ィ部として送信する。図１４は、ＷＷＷアプリケーショ
ン５へのログイン時の表示画面の一例の説明図である。
この例では、ＷＷＷアプリケーション５のホームページ
として、“Ｈｅｒｅ ｉｓ Ａｐｐｌｉｃａｔｉｏ
ｎ．”が表示されている。図８と比べ、アドレス欄が
“Ａｐｐｌｉｃａｔｉｏｎ２”となっており、ＷＷＷア
プリケーション４ではなくＷＷＷアプリケーション５か
らのものである。

【００５２】この（２９）の応答メッセージをＷＷＷブ
ラウザ２に対して送信する際に、ＷＷＷアプリケーショ
ン５のみに有効な認証チケット（クッキー）をＷＷＷブ
ラウザ２に対して発行する。図１５は、ＷＷＷアプリケ
ーション５への認証チケットの一例の説明図である。図
１５に示す例において、“Ｃｏｏｋｉｅ情報”中の“ド
メイン”欄及び“パス”欄においてＷＷＷアプリケーシ
ョン５のドメイン及びパスが記述されており、ＷＷＷア
プリケーション５のみに適用される認証チケットである
ことが明示されている。図９に示したＷＷＷアプリケシ
ョン４への認証チケットと比べて、これらの欄の記述が
異なっていることによって、各認証チケットはそれぞれ
のＷＷＷアプリケーション毎に適用されることになる。
従って図１５に示す認証チケットは、ＷＷＷアプリケー
ション５のみ利用可能である。

【００５３】以後、ＷＷＷブラウザ２からＷＷＷアプリ
ケーション５へのアクセスが行われる際には（２９）で
受け取った認証チケットがＷＷＷアプリケーション５に
提示される。例えば上述のようにしてＷＷＷアプリケー
ション５に対する最初のアクセスを行った後、（３０）
において利用者がＷＷＷブラウザ２に対してＷＷＷアプ
リケーション５へのアクセスを再び指示すると、（３
１）においてＷＷＷブラウザ２からＷＷＷアプリケーシ
ョン５へ要求メッセージが渡される。このとき、上述の
（２９）で受け取った認証チケットがＷＷＷアプリケー
ション５に提示される。ＷＷＷアプリケーション５で
は、ＷＷＷブラウザ２からのアクセスを受け、認証チケ
ットを受け取ると、ＳＳＯサーバ６への問い合わせなど
を行わずに、処理部１２によって要求された処理を行
い、処理結果を（３２）においてＷＷＷブラウザ２に返
す。このようにして、以後はＷＷＷアプリケーション５
によるサービスを受けることができる。

【００５４】このように、最初にＷＷＷアプリケーショ
ンのサービスを受ける際には、ユーザＩＤやパスワード
などの入力を行い、ＳＳＯサーバ６による認証を行う。
しかし、その後の当該ＷＷＷアプリケーションの利用、
及び、他のＷＷＷアプリケーションの利用に際しては、
ユーザＩＤやパスワードの入力を必要としない。従っ
て、シングルサインオンを実現することができた。

【００５５】また、上述のように、本発明では各ＷＷＷ
アプリケーションがそれぞれ認証チケットを発行する。
例えばＷＷＷアプリケーション４は、ＷＷＷアプリケー
ション４に対してのみ適用される認証チケットを発行
し、またＷＷＷアプリケーション５は、ＷＷＷアプリケ
ーション５のみに適用される認証チケットを発行する。
そのため、従来のように認証チケットが広範囲に漏れる
といった問題を防止することができ、安全に通信を行う
ことができる。

【００５６】上述の動作例では、ＷＷＷブラウザ２から
ＷＷＷアプリケーション４，５を利用する場合について
示したが、ＷＷＷブラウザ３からＷＷＷアプリケーショ
ン４，５を利用する場合も同様である。

【００５７】また、上述の動作例では、ＷＷＷブラウザ
２からＷＷＷアプリケーション４やＷＷＷアプリケーシ
ョン５へ最初にアクセスしたときに、ＳＳＯサーバ６に
対してリダイレクションによりＷＷＷブラウザ２からア
クセスするようにした。本発明はこれに限られるもので
はなく、例えば利用者が自発的にＷＷＷブラウザ２から
ＳＳＯサーバ６に対してアクセスして認証を行い、その
後、利用したいＷＷＷアプリケーションへアクセスする
ようにしてもよい。その場合には、ＷＷＷアプリケーシ
ョンへの最初のアクセス時にＷＷＷアプリケーションか
らＳＳＯサーバへ利用者の認証状況を問い合わせ、認証
済であれば各ＷＷＷアプリケーションが認証チケットを
発行すればよい。

【００５８】なお、図６，図９，図１５にも示したよう
に、認証チケットには有効期限を指定することができ、
これらの例ではセッションの終了とともに認証チケット
は削除されて利用できなくなる。この有効期限として例
えば時間を指定すれば、指定した時間内だけ有効な認証
チケットを発行することもできる。

【００５９】しかし、時間を指定したとしても、ＷＷＷ
ブラウザとＷＷＷアプリケーションは、数十分〜数時間
の間、同一の認証チケットを使い続けることになり、何
回もＷＷＷブラウザからＷＷＷアプリケーションに対し
て認証チケットが送信される。そのため、通信経路の途
中で認証チケットを盗み（コピーし）、なりすましによ
って悪用されることが考えられる。

【００６０】このような問題を解決するため、例えばＷ
ＷＷブラウザ−ＳＳＯサーバ間や、ＷＷＷブラウザ−Ｗ
ＷＷアプリケーション間の通信にＣＨＡＰ（Ｃｈａｌｌ
ｅｎｇｅ Ｈａｎｄｓｈａｋｅ Ａｕｔｈｅｎｔｉｃａ
ｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を導入することができ
る。すなわち、ＳＳＯサーバ６やＷＷＷアプリケーショ
ン４，５からＷＷＷブラウザ２，３に対して毎回異なる
情報Ｃを送り、ＷＷＷブラウザ２，３から要求メッセー
ジをＳＳＯサーバ６やＷＷＷアプリケーション４，５に
送る際には所定の関数ｆによりＣを変換した値ｆ（Ｃ）
を含めて送る。ＳＳＯサーバ６やＷＷＷアプリケーショ
ン４，５では、変換値ｆ（Ｃ）が正しいか否かを判断す
ればよい。例えば情報Ｃを盗んでも、関数ｆが分からな
い限り、正しい変換値を送信することができない。ま
た、変換値ｆ（Ｃ）を盗んでも、情報Ｃを変更してゆく
ことによって、なりすましを防止することができる。

【００６１】すなわち，ネットワーク盗聴により，認証
チケットを盗むことは可能であるが、ＣＨＡＰが提供す
るセキュリティレベルで、ＷＷＷブラウザ−ＷＷＷサー
バ間、ＷＷＷブラウザ−ＷＷＷアプリケーション間の通
信をセキュアに行うことができる。

【００６２】さらに、ＷＷＷブラウザ−ＳＳＯサーバ間
や、ＷＷＷブラウザ−ＷＷＷアプリケーション間の通信
にＳＳＬ認証を導入することもできる。すなわち、ＳＳ
Ｌ認証が提供するセキュリティレベルで、ＷＷＷブラウ
ザ−ＳＳＯサーバ間及びＷＷＷブラウザ−ＷＷＷアプリ
ケーション間の通信をセキュアに行うことができるた
め、認証チケットの盗用そのものを防ぐことができる。
ＳＳＬ認証にはサーバ認証とクライアント認証がある
が、ＨＴＴＰレベルでの暗号通信により認証チケット
（クッキー）の盗聴を防げればよいので、コスト的に安
価なサーバ認証であっても十分対応することが可能であ
る。

【００６３】図１６は、本発明の第２の実施の形態を示
すシステム構成図である。図中、図１と同様の部分には
同じ符号を付して説明を省略する。２３はケイパビリテ
ィ管理データベースである。なお、この第２の実施の形
態は、ケイパビリティ管理データベース２３を利用する
以外は上述の第１の実施の形態と同様であり、動作例に
ついても同様の説明を省略する。

【００６４】ケイパビリティ管理データベース２３は、
利用者毎に、各ＷＷＷアプリケーションが提供している
サービスのうちいずれを利用可能であるかを示す情報で
ある。図１７は、ケイパビリティ管理データベースの内
容の一例の説明図である。図１７に示すケイパビリティ
管理データベース２３の例では、Ｍ人の利用者毎に、Ｎ
個のそれぞれのＷＷＷアプリケーションについて、それ
ぞれのＷＷＷアプリケーションが提供しているサービス
について、利用の可否を最右欄の‘１’または‘０’に
よって示している。すなわち、ユーザＩＤ“ｕｓｒ＿
１”のユーザは、ＷＷＷアプリケーション“ａｐｌ＿
１”が提供するＰ個のサービス“ｆｕｎｃ＿１”〜“ｆ
ｕｎｃ＿Ｐ”について、“ｆｕｎｃ＿１”は利用できる
が“ｆｕｎｃ＿２”は利用できず、…、“ｆｕｎｃ＿
Ｐ”は利用することができる。他のＷＷＷアプリケーシ
ョン、他の利用者についても同様である。なお、このケ
イパビリティ管理データベース２３をＳＳＯサーバ６と
は別のサーバにより構成することも可能である。

【００６５】認証部２１は、ＷＷＷアプリケーション
４，５から利用者の認証状況について問い合わせを受け
た際に、利用者のユーザＩＤ及び問い合わせを受けたＷ
ＷＷアプリケーションに基づいてケイパビリティ管理デ
ータベース２３に問い合わせを行う。これによって例え
ば図１７に示すケイパビリティ管理データベース２３の
例における最右欄の‘１’、‘０’のケイパビリティ情
報を受け取り、これをＷＷＷアプリケーションに対して
返す。ＷＷＷアプリケーションでは、受け取ったケイパ
ビリティ情報をもとに、利用者に対してサービスを提供
してよいか否かを判断すればよい。

【００６６】例えば図２に示した動作例におけるシーケ
ンス図において、（１２）や（２７）におけるＷＷＷア
プリケーションからＳＳＯサーバへの問い合わせ時に、
上述のケイパビリティ管理データベース２３を利用して
提供可能なサービスを判断すればよい。判断の結果は、
（１３）や（２８）においてＳＳＯサーバからＷＷＷア
プリケーションへ返せばよい。

【００６７】あるいは、ＷＷＷアプリケーション４，５
が利用者に新たなサービスを提供する毎に、当該サービ
スを指定してＳＳＯサーバ６に対して認証状況の問い合
わせを行ってもよい。この場合、認証部２１は利用者が
認証済であっても指定されたサービスの提供を許されて
いない場合には、問い合わせ元のＷＷＷアプリケーショ
ンに対して否定応答を行えばよい。

【００６８】図１８は、本発明の第３の実施の形態を示
すシステム構成図である。図中、図１６と同様の部分に
は同じ符号を付して説明を省略する。２４はライセンス
情報管理データベースである。なお、この第３の実施の
形態は、ライセンス情報管理データベース２４を利用す
る以外は上述の第１及び第２の実施の形態と同様であ
り、動作例についても同様の説明を省略する。

【００６９】ライセンス情報管理データベース２４は、
ＷＷＷアプリケーション毎のライセンス情報を保持して
おり、認証部２１からの問い合わせに応じてライセンス
の有無を通知する。なお、このライセンス情報管理デー
タベース２４をＳＳＯサーバ６とは別のサーバにより構
成することも可能である。

【００７０】認証部２１は、ＷＷＷアプリケーション
４，５から利用者の認証状況について問い合わせを受け
た際に、利用者のユーザＩＤ及び問い合わせを受けたＷ
ＷＷアプリケーションに基づいてライセンス情報管理デ
ータベース２４に問い合わせを行う。これによって、当
該利用者が問い合わせ元のＷＷＷアプリケーションに対
してライセンスを有しているか否かを判断する。例えば
利用者が個人情報管理データベース２２による認証が終
了している場合でも、利用しようとしたＷＷＷアプリケ
ーションについてのライセンスを有していなければ、問
い合わせ元のＷＷＷアプリケーションに対して否定応答
を行う。さらに、ライセンスに違反する利用が発生した
際に、当該ＷＷＷアプリケーションのベンダにその旨を
通知するように構成することもできる。

【００７１】例えば図２に示した動作例におけるシーケ
ンス図において、（１２）や（２７）におけるＷＷＷア
プリケーションからＳＳＯサーバへの問い合わせ時に、
上述のライセンス情報管理データベース２４を利用して
ライセンス認証を行うように構成することができる。ラ
イセンス認証の結果は、（１３）や（２８）においてＳ
ＳＯサーバからＷＷＷアプリケーションへ返せばよい。
また、ライセンス認証のために利用者に対して入力を要
求する場合には、ＳＳＯサーバ６からＷＷＷブラウザに
対して入力フォームを送信して入力情報を受け取ればよ
い。

【００７２】なお、上述の第２の実施の形態で述べたよ
うに、ケイパビリティ管理データベース２３を利用した
ケイパビリティのチェックについても行うことができ
る。すなわち、ＷＷＷアプリケーションからの問い合わ
せ時に、個人認証とともに、利用するＷＷＷアプリケー
ションに対するライセンス認証、さらにＷＷＷアプリケ
ーション内で利用可能なサービスに対するケイパビリテ
ィチェックを合わせて行うことができる。

【００７３】図１９は、本発明の第４の実施の形態を示
すシステム構成図である。図中、３１はネットワーク、
３２，３３はＷＷＷブラウザ、３４，３５は処理システ
ム、４１，４２，５１，５２，５３はＷＷＷアプリケー
ション、４３，５４はＳＳＯサーバである。この実施の
形態では、複数のＳＳＯサーバを利用する場合の一構成
例を示している。なお、ネットワーク３１，ＷＷＷブラ
ウザ３２，３３、ＷＷＷアプリケーション４１，４２，
５１，５２，５３、ＳＳＯサーバ４３，５４は、それぞ
れ、図１に示した第１の実施の形態におけるネットワー
ク１、ＷＷＷブラウザ２，３、ＷＷＷアプリケーション
４，５、ＳＳＯサーバ６と同等のものであり、これらの
詳細な説明は省略する。また、ＳＳＯサーバ６の構成
は、上述の第１ないし第３の実施の形態におけるいずれ
の構成であってもよい。なお、各部の動作についても上
述の第１の実施の形態等と同様である。

【００７４】上述の各実施の形態においては、１つのＳ
ＳＯサーバのみしか設けていないが、システム内に複数
のＳＳＯサーバを設置することも可能である。このと
き、上述の動作例でも分かるように、ＷＷＷアプリケー
ションとＳＳＯサーバとの間で利用者の認証状況の問い
合わせとその応答を行うため、なるべく安全に通信でき
ることが望ましい。そのため、サービスを提供するＷＷ
ＷアプリケーションとＳＳＯサーバとを同じドメイン内
など、同じ処理システム内に配置することが考えられ
る。

【００７５】図１９に示した例では、２つの処理システ
ム３４，３５を示しており、処理システム３４にはＷＷ
Ｗアプリケーション４１，４２及びＳＳＯサーバ４３を
設け、処理システム３５にはＷＷＷアプリケーション５
１，５２，５３とＳＳＯサーバ５４を設けている。それ
ぞれの処理システム３４，３５とも、ネットワーク３１
を通じてＷＷＷブラウザ３２，３３などからのアクセス
を受けることができる。

【００７６】処理システム３４では、ＷＷＷアプリケー
ション４１，４２にＷＷＷブラウザ３２，３３等から最
初のアクセスがあると、ＳＳＯサーバ４３に対してリダ
イレクションによる認証を依頼し、またその後の利用者
の認証状況の問い合わせもＳＳＯサーバ４３に対して行
う。これによって、ＷＷＷアプリケーション４１，４２
とＳＳＯサーバ４３との間の通信は、ＳＳＯサーバ４３
が外部に存在する場合に比べて安全に行うことができ
る。

【００７７】一方、処理システム３５でも、ＷＷＷアプ
リケーション５１，５２，５３にＷＷＷブラウザ３２，
３３等から最初のアクセスがあると、ＳＳＯサーバ５４
に対してリダイレクションによる認証を依頼し、またそ
の後の利用者の認証状況の問い合わせもＳＳＯサーバ５
４に対して行う。これによって、ＷＷＷアプリケーショ
ン５１，５２，５３とＳＳＯサーバ５４との間の通信
は、ＳＳＯサーバ５４が外部に存在する場合に比べて安
全に行うことができる。

【００７８】しかしこのままでは、例えばＳＳＯサーバ
４３において認証を受けた利用者は、ＷＷＷアプリケー
ション４１，４２については１回の認証（ユーザＩＤ及
びパスワードの入力）を行うだけでいずれを利用するこ
とも可能である。しかし、アプリケーション５１，５
２，５３を利用する場合には、アプリケーション５１，
５２，５３からリダイレクションによりＳＳＯサーバ５
４がアクセスされたときに未ログインの利用者として扱
われ、再度の認証（ユーザＩＤ及びパスワードの入力）
を行う必要が生じる。しかし、利用者にとっては利用す
るサービスによって認証（ユーザＩＤ及びパスワードの
入力）が必要になるため、シングルサインオンの利便性
が低下してしまう。

【００７９】このような問題を解決するため、ＳＳＯサ
ーバ４３とＳＳＯサーバ５４との間でログイン済の利用
者の情報を共有するように構成するとよい。具体的に
は、図１９において矢線で示すように、ＳＳＯサーバ４
３とＳＳＯサーバ５４との間でログインした利用者の情
報を転送し合い、一方のＳＳＯサーバで認証を行った場
合でも、いずれのＳＳＯサーバも当該利用者を認証済と
して扱えるように構成することができる。あるいは、認
証済の利用者の情報を保持する認証済サーバを設け、い
ずれかのＳＳＯサーバで認証を行ったら認証済サーバへ
の登録を行い、認証状況の問い合わせを受けた場合には
認証済サーバへの問い合わせを行うように構成すること
もできる。いずれの場合にも、ＳＳＯサーバ間あるいは
ＳＳＯサーバと認証済サーバ間の通信は、安全に行われ
る必要がある。

【００８０】図１９に示した例では、処理システムが２
つの例を示しているが、もちろん処理システムは２つに
限られるものではない。なお、処理システムはネットワ
ーク上の概念的なものであって、実際の装置構成とは異
なっている場合もある。例えば処理システム３４と処理
システム３５が同じコンピュータシステム内で実現され
ることもあるし、それぞれ異なるコンピュータで構成さ
れ、異なる場所に設置されることもあり、実現形態は任
意である。

【００８１】

【発明の効果】以上の説明から明らかなように、本発明
によれば、シングルサインオンを実現するとともに、認
証チケットが広範囲に漏れることによるなりすましのア
クセスを防止することができ、安全に通信を行うことが
できるという効果がある。また、ＣＨＡＰやＳＳＬなど
を利用することによって、認証チケットそのものの盗用
を防止し、さらに安全に通信を行うことができるという
効果がある。

【図面の簡単な説明】

【図１】 本発明の第１の実施の形態を示すシステム構
成図である。

【図２】 本発明の第１の実施の形態における動作の一
例を示すシーケンス図である。

【図３】 本発明の第１の実施の形態においてＷＷＷア
プリケーションへの最初のアクセスを行った際の動作の
一例の説明図である。

【図４】 ＳＳＯサーバ６へのリダイレクション時の表
示画面の一例の説明図である。

【図５】 認証フォーム画面の一例の説明図である。

【図６】 ＳＳＯサーバ６への認証チケットの一例の説
明図である。

【図７】 ＷＷＷアプリケーション４へのリダイレクシ
ョン時の表示画面の一例の説明図である。

【図８】 ＷＷＷアプリケーション４へのログイン時の
表示画面の一例の説明図である。

【図９】 ＷＷＷアプリケーション４への認証チケット
の一例の説明図である。

【図１０】 本発明の第１の実施の形態におけるＷＷＷ
アプリケーションへの２回目以降のアクセスを行った際
の動作の一例の説明図である。

【図１１】 本発明の第１の実施の形態における別のＷ
ＷＷアプリケーションへのアクセスを行った際の動作の
一例の説明図である。

【図１２】 ＳＳＯサーバ６へのリダイレクション時の
表示画面の一例の説明図である。

【図１３】 ＷＷＷアプリケーション５へのリダイレク
ション時の表示画面の一例の説明図である。

【図１４】 ＷＷＷアプリケーション５へのログイン時
の表示画面の一例の説明図である。

【図１５】 ＷＷＷアプリケーション５への認証チケッ
トの一例の説明図である。

【図１６】 本発明の第２の実施の形態を示すシステム
構成図である。

【図１７】 ケイパビリティ管理データベースの内容の
一例の説明図である。

【図１８】 本発明の第３の実施の形態を示すシステム
構成図である。

【図１９】 本発明の第４の実施の形態を示すシステム
構成図である。

【符号の説明】

１…ネットワーク、２，３…ＷＷＷブラウザ、４，５…
ＷＷＷアプリケーション、６…ＳＳＯサーバ、１１…通
信制御部、１２…処理部、２１…認証部、２２…個人情
報管理データベース、２３…ケイパビリティ管理データ
ベース、２４…ライセンス情報管理データベース、３１
…ネットワーク、３２，３３…ＷＷＷブラウザ、３４，
３５…処理システム、４１，４２，５１，５２，５３…
ＷＷＷアプリケーション、４３，５４…ＳＳＯサーバ。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 廣瀬 陽一 神奈川県川崎市高津区坂戸３丁目２番１号 ＫＳＰ Ｒ＆Ｄ ビジネスパークビル 富士ゼロックス株式会社内 (72)発明者 近藤 勝行 神奈川県川崎市高津区坂戸３丁目２番１号 ＫＳＰ Ｒ＆Ｄ ビジネスパークビル 富士ゼロックス株式会社内 Ｆターム(参考） 5B085 AE01 BA06 BC01 BG02 BG07 5J104 AA07 KA01 PA07

Claims (23)

【特許請求の範囲】
1. 【請求項１】 ネットワークを通じて行われるクライア
   ントからの要求に応じてサービスを提供するネットワー
   ク装置において、要求されたサービスを提供する処理手
   段と、未ログインのクライアントからのアクセスを受け
   た際に認証サーバに問い合わせて認証済であれば当該ネ
   ットワーク装置へのアクセスのための認証チケットを発
   行しログイン済のクライアントからのアクセスを受けた
   際には前記認証チケットを受け取って前記処理手段にサ
   ービスを行わせる通信制御手段を有することを特徴とす
   るネットワーク装置。
2. 【請求項２】 前記通信制御手段は、クライアントとの
   セッションが存在しない時点でのクライアントからのア
   クセスを受けた場合に前記認証サーバに対してクライア
   ントの認証を依頼することを特徴とする請求項１に記載
   のネットワーク装置。
3. 【請求項３】 前記通信制御手段は、前記認証サーバに
   対するクライアントの認証の依頼として、前記クライア
   ントに対して前記認証サーバへのリダイレクションを指
   示し、前記クライアントから前記認証サーバへアクセス
   させることを特徴とする請求項２に記載のネットワーク
   装置。
4. 【請求項４】 前記通信制御手段は、セッションは存在
   するが未ログインのクライアントからのアクセスを受け
   た場合に前記認証サーバに対して認証済か否かの問い合
   わせを行うことを特徴とする請求項１ないし請求項３の
   いずれか１項に記載のネットワーク装置。
5. 【請求項５】 前記通信制御手段は、前記クライアント
   との間の通信をＣＨＡＰにより行うことを特徴とする請
   求項１ないし請求項４のいずれか１項に記載のネットワ
   ーク装置。
6. 【請求項６】 前記通信制御手段は、前記クライアント
   との間の通信をＳＳＬ認証により行うことを特徴とする
   請求項１ないし請求項５のいずれか１項に記載のネット
   ワーク装置。
7. 【請求項７】 クライアントに対して提供されるサービ
   スに代わって前記クライアントの認証を行う認証サーバ
   において、クライアントの認証情報を保持する認証情報
   データベースと、クライアントの認証要求を受けて前記
   クライアントの認証を行うとともに前記サービスからの
   要求に対して前記クライアントの認証の有無を返す認証
   手段を有し、前記認証手段は、前記クライアントが未認
   証の場合には前記クライアントに対して認証フォームを
   送信して入力情報を受け取り、前記入力情報に基づいて
   前記認証情報データベースへの問い合わせを行って前記
   クライアントの認証を行い、前記クライアントが既に認
   証済である場合には前記クライアントに対する問い合わ
   せを行わないことを特徴とする認証サーバ。
8. 【請求項８】 前記認証手段は、前記ネットワーク装置
   からのリダイレクトにより前記クライアントの認証要求
   を受けるとともに、前記サービスから直接前記クライア
   ントの認証の有無の要求を受けることを特徴とする請求
   項７に記載の認証サーバ。
9. 【請求項９】 さらに、クライアントに対して提供可能
   な前記サービス中の機能を管理するケイパビリティ情報
   データベースを有し、前記認証手段は、前記サービスか
   らの要求に対して前記クライアントの認証の有無ととも
   に前記ケイパビリティ情報データベースを用いて前記サ
   ービス中の機能の利用の可否を判断することを特徴とす
   る請求項７または請求項８に記載の認証サーバ。
10. 【請求項１０】 さらに、クライアントのライセンス情
    報を管理するライセンス情報管理データベースを有し、
    前記認証手段は、前記サービスにおいてライセンス認証
    が必要な場合に前記ライセンス情報管理データベースを
    用いてクライアントのライセンス認証を行うことを特徴
    とする請求項７ないし請求項９のいずれか１項に記載の
    認証サーバ。
11. 【請求項１１】 前記認証手段は、前記クライアントと
    の間の通信をＣＨＡＰにより行うことを特徴とする請求
    項７ないし請求項１０のいずれか１項に記載の認証サー
    バ。
12. 【請求項１２】 前記認証手段は、前記クライアントと
    の間の通信をＳＳＬ認証により行うことを特徴とする請
    求項７ないし請求項１１のいずれか１項に記載の認証サ
    ーバ。
13. 【請求項１３】 ネットワークを通じて行われるクライ
    アントからの要求に応じてサービスを提供するネットワ
    ーク装置と、ネットワークを通じて前記クライアントの
    認証を行う認証サーバを含み、前記ネットワーク装置
    は、未ログインのクライアントからのアクセスを受けた
    際に前記認証サーバに問い合わせて認証済であれば当該
    ネットワーク装置へのアクセスのための認証チケットを
    発行し、またログイン済のクライアントからのアクセス
    時には前記認証チケットを受け取ってサービスを提供す
    るものであり、前記認証サーバは、前記クライアントの
    認証要求に対して、前記クライアントが未認証の場合に
    は前記クライアントに対して認証フォームを送信して入
    力情報を受け取り、前記入力情報に基づいて前記クライ
    アントの認証を行い、前記クライアントが既に認証済で
    ある場合には前記クライアントに対する問い合わせを行
    わず、以後の前記ネットワーク装置からの前記クライア
    ントの問い合わせに応じて認証状況を返すことを特徴と
    するネットワークシステム。
14. 【請求項１４】 前記認証サーバは、前記ネットワーク
    装置からの問い合わせに応じて前記クライアントに対し
    て提供可能な前記サービス中の機能についての判断につ
    いても行うことを特徴とする請求項１３に記載のネット
    ワークシステム。
15. 【請求項１５】 前記認証サーバは、前記ネットワーク
    装置においてライセンス認証が必要な場合にクライアン
    トのライセンス認証を行うことを特徴とする請求項１３
    または請求項１４に記載のネットワークシステム。
16. 【請求項１６】 前記ネットワーク装置及び前記認証サ
    ーバは、前記クライアントとの間の通信をＣＨＡＰによ
    り行うことを特徴とする請求項１３ないし請求項１５の
    いずれか１項に記載のネットワークシステム。
17. 【請求項１７】 前記ネットワーク装置及び前記認証サ
    ーバは、前記クライアントとの間の通信をＳＳＬ認証に
    より行うことを特徴とする請求項１３ないし請求項１６
    のいずれか１項に記載のネットワークシステム。
18. 【請求項１８】 ネットワークを通じて行われるクライ
    アントからの要求に応じて複数のサービスを提供するネ
    ットワークシステムにおける認証方法において、前記サ
    ービスに未ログインのクライアントが前記サービスにア
    クセスすると、前記サービスは前記クライアントに認証
    サーバによる認証を受けさせ、前記認証サーバによる前
    記クライアントの認証後に前記サービスは前記認証サー
    バに対して前記クライアントの認証結果を問い合わせて
    認証済であれば前記クライアントに当該サービスを利用
    する際の認証チケットを発行し、以後、前記クライアン
    トから前記認証チケットの提示を受けてサービスの提供
    を行うことを特徴とする認証方法。
19. 【請求項１９】 同じクライアントが別のサービスにア
    クセスした場合には、前記認証サーバによる前記クライ
    アントの認証を行わずに、前記別のサービスから前記ク
    ライアントの認証結果の問い合わせに対して前記認証サ
    ーバが認証済を返し、前記別のサービスが当該別のサー
    ビスを利用する際の認証チケットを発行することを特徴
    とする請求項１８に記載の認証方法。
20. 【請求項２０】 前記サービスからのクライアントの認
    証結果の問い合わせに対して、認証サーバにおいて前記
    クライアントに対して提供可能な前記サービス中の機能
    についての判断も行うことを特徴とする請求項１８また
    は請求項１９に記載の認証方法。
21. 【請求項２１】 前記サービスにおいてライセンス認証
    が必要な場合にクライアントのライセンス認証を行うこ
    とを特徴とする請求項１８ないし請求項２０のいずれか
    １項に記載の認証方法。
22. 【請求項２２】 前記クライアントと前記サービス及び
    前記クライアントと前記認証サーバとの間の通信をＣＨ
    ＡＰにより行うことを特徴とする請求項１８ないし請求
    項２１のいずれか１項に記載の認証方法。
23. 【請求項２３】 前記クライアントと前記サービス及び
    前記クライアントと前記認証サーバとの間の通信をＳＳ
    Ｌ認証により行うことを特徴とする請求項１８ないし請
    求項２２のいずれか１項に記載の認証方法。