JP7227891B2 - 認証サーバおよび認証システム - Google Patents

Description

本発明は、認証サーバおよび認証システムに関し、例えば、ＲＡＤＩＵＳ（Remote Authentication Dial In User Service）サーバを用いた認証技術に関する。

特許文献１には、認証サーバに対してユーザ認証を求める画像処理装置が示される。当該画像処理装置は、ユーザによって入力されたユーザＩＤを検索キーとしてディレクトリサーバに検索要求を送信することで認証用ユーザＩＤを取得し、当該認証用ユーザＩＤを用いて認証サーバに対してユーザ認証を求める。これにより、ユーザは、ディレクトリサーバ上で認証用ユーザＩＤに対応付けられる各種ユーザ属性（電話番号、社員番号等）の中の予め定めた一つ属性をユーザＩＤとして入力すればよく、認証用ユーザＩＤが長い場合等でユーザＩＤの入力操作を簡単にすることができる。

特開２００７－１２８２０８号公報

ネットワーク認証を行う認証サーバとして、ＲＡＤＩＵＳサーバが広く知られている。このような認証サーバは、正しいＩＤ（ユーザ識別子）およびパスワードが予め登録されたアカウントデータベース（アカウントＤＢと略す）に基づいて、ＩＤおよびパスワードを入力したユーザに対するネットワーク認証を行う。アカウントＤＢは、認証サーバ内に設けられる場合の他に、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ（登録商標）サーバ（ＡＤサーバと略す）を代表とする外部のディレクトリサーバに設けられる場合がある。後者の場合、認証サーバは、ディレクトリサーバと連携してネットワーク認証を行う。

一方、ユーザは、例えば、“ｓａｍＡｃｃｏｕｎｔＮａｍｅ”や“ＵｓｅｒＰｒｉｎｃｉｐａｌＮａｍｅ”といったように、異なる２種類のＩＤを有する場合がある。ただし、特に、認証サーバがディレクトリサーバと連携してネットワーク認証を行う場合、各種条件に応じて、例えば、２種類のＩＤの両方を使用できる場合や、一方のみを使用できる場合がある。その結果、ユーザに、ＩＤの使い分けを要求することになり、ユーザの利便性が低下する恐れがある。

本発明は、このようなことに鑑みてなされたものであり、その目的の一つは、ユーザの利便性を向上させることが可能な認証サーバおよび認証システムを提供することにある。

本発明の前記並びにその他の目的と新規な特徴は、本明細書の記述及び添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的な実施の形態の概要を簡単に説明すれば、次のとおりである。

一実施の形態による認証サーバは、ＩＤ検索部と、問い合わせ部とを有し、ユーザによって入力された入力ＩＤおよび入力パスワードに対する認証要求を受信し、外部のディレクトリサーバに認証成否を問い合わせる。ディレクトリサーバは、同一のユーザに対して定められる第１の登録ＩＤと第２の登録ＩＤと登録パスワードとの対応関係を保持する。ＩＤ検索部は、入力ＩＤの属性を第２の登録ＩＤに定めた状態でディレクトリサーバに第２の登録ＩＤに対応する第１の登録ＩＤの検索要求を送信し、ディレクトリサーバから第１の登録ＩＤを取得する。問い合わせ部は、ＩＤ検索部で取得した第１の登録ＩＤと、入力パスワードに対する認証成否をディレクトリサーバに問い合わせる。

本願において開示される発明のうち、代表的な実施の形態によって得られる効果を簡単に説明すると、ユーザの利便性を向上させることが可能になる。

（ａ）は、本発明の実施の形態１による認証システムの主要部の構成例および動作例を示す概略図であり、（ｂ）は、（ａ）におけるディレクトリサーバが備えるアカウントＤＢの構成例を示す概略図である。 図１の認証システムの概略的な動作例を示すシーケンス図である。 図１（ａ）における認証サーバの主要部の構成例を示すブロック図である。 図３の認証サーバにおける処理内容の一例を示すフロー図である。 図３の認証サーバにおける処理内容の他の一例を示すフロー図である。 本発明の実施の形態２による認証システムにおいて、図１（ａ）における認証サーバの主要部の構成例を示すブロック図である。 図６の認証サーバにおける処理内容の一例を示すフロー図である。 図６の認証サーバにおける処理内容の他の一例を示すフロー図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。

（実施の形態１）
《認証システムの概略》
図１（ａ）は、本発明の実施の形態１による認証システムの主要部の構成例および動作例を示す概略図であり、図１（ｂ）は、図１（ａ）におけるディレクトリサーバが備えるアカウントＤＢの構成例を示す概略図である。図１（ａ）に示す認証システムは、ネットワークＮＷに接続される認証スイッチＳＷ、認証サーバ１２およびディレクトリサーバ１３と、認証スイッチＳＷに接続されるユーザ端末ＴＭとを備える。ネットワークＮＷは、例えば、ＯＳＩ参照モデルのレイヤ３（Ｌ３）のネットワーク等である。

認証サーバ１２は、例えば、ＲＡＤＩＵＳサーバである。認証スイッチＳＷは、ＲＡＤＩＵＳクライアントの機能を搭載したイーサネット（登録商標）スイッチ等である。ただし、ＲＡＤＩＵＳクライアントとして、認証スイッチＳＷの代わりに無線ＬＡＮアクセスポイント等が設けられてもよい。認証スイッチＳＷは、例えば、ユーザ端末ＴＭにログインページを提供する機能（Ｗｅｂ認証機能）や、ＩＥＥＥ８０２．１Ｘのオーセンティケータ機能等を有する。

ディレクトリサーバ１３は、例えば、ＡＤサーバ等を代表とするＬＤＡＰ（Lightweight Directory Access Protocol）サーバである。ディレクトリサーバ１３は、アカウントＤＢ１４を備える。アカウントＤＢ１４は、図１（ｂ）に示されるように、同一のユーザ１１に対して定められる第１の登録ＩＤ（ＩＤｒ［１］）と第２の登録ＩＤ（ＩＤｒ［２］）と登録パスワードＰＷｒとの対応関係を保持する。例えば、ＡＤサーバを用いる場合、第１の登録ＩＤ（ＩＤｒ［１］）は、“ｓａｍＡｃｃｏｕｎｔＮａｍｅ”である。一方、第２の登録ＩＤ（ＩＤｒ［２］）は、“ＵｓｅｒＰｒｉｎｃｉｐａｌＮａｍｅ”であり、“ユーザ名＠ドメイン名”のフォーマットを有する。

このような構成において、認証サーバ１２は、ユーザ１１に対するネットワーク認証（ＲＡＤＩＵＳ認証）を行う場合、ユーザ１１によって入力された入力ＩＤ（ＩＤｉ）および入力パスワードＰＷｉに対する認証要求を受信し、外部のディレクトリサーバ１３に認証成否を問い合わせる。

具体的には、まず、ユーザ端末ＴＭは、例えばログインページを介してユーザ１１によって入力された入力ＩＤ（ＩＤｉ）および入力パスワードＰＷｉを、認証スイッチＳＷに送信する（ステップＳ１０３）。これを受けて、認証スイッチＳＷは、入力ＩＤ（ＩＤｉ）および入力パスワードＰＷｉの認証要求を、認証サーバ１２に送信する（ステップＳ１０４）。

続いて、認証サーバ１２は、認証要求に応じて、アカウントＤＢ１４を有するディレクトリサーバ１３に、ＩＤおよびパスワードに対する認証成否を問い合わせる（ステップＳ１０５）。ディレクトリサーバ１３は、ステップＳ１０５に伴うＩＤおよびパスワードがアカウントＤＢ１４の登録情報と一致する場合には認証成功と判定し、不一致の場合には認証失敗と判定する。そして、ディレクトリサーバ１３は、認証成否の判定結果を、問い合わせ結果として認証サーバ１２に送信する（ステップＳ１０６）。

認証サーバ１２は、ディレクトリサーバ１３からの問い合わせ結果（ステップＳ１０６）を認証結果として認証スイッチＳＷに送信する（ステップＳ１０７）。認証スイッチＳＷは、認証結果が認証成功を表す場合には、ユーザ端末ＴＭのネットワークＮＷへの接続を許可し、認証失敗を表す場合には、ユーザ端末ＴＭのネットワークＮＷへの接続を禁止する。

ここで、ステップＳ１０３，Ｓ１０４に際し、ユーザ端末ＴＭ（例えばＩＥＥＥ８０２．１Ｘのサプリカントソフト）または認証スイッチＳＷは、ネットワーク認証で用いる認証プロトコルを予め設定によって定めることができる。認証プロトコルの選択肢として、例えば、ＰＡＰ（Password Authentication Protocol）や、ＣＨＡＰ（Challenge Handshake Authentication Protocol）の一種であるＭＳ－ＣＨＡＰｖ２（MicroSoft（登録商標） CHAP version2）等が挙げられる。

ＰＡＰは、入力パスワードＰＷｉを平文で送信する方式を用いている。一方、ＭＳ－ＣＨＡＰｖ２は、チャレンジ／レスポンス方式を用いている。この場合、入力パスワードＰＷｉは、規定のハッシュ関数、および予め受信した乱数（チャレンジ情報）等によって暗号化された上で、レスポンス情報としてユーザ端末ＴＭから送信される。

また、ステップＳ１０５に際し、認証サーバ１２は、ステップＳ１０４での入力パスワードＰＷｉに適用されている認証プロトコルがＰＡＰの場合、当該入力パスワードＰＷｉを含むアカウントの認証成否をケルベロス認証方式、またはＬＤＡＰ＿ｂｉｎｄコマンドを用いたＬＤＡＰ認証方式等を用いてディレクトリサーバ１３に問い合わせる。このような認証プロトコルと認証方式との対応関係は、パスワードが平文であることが要因となっている。

一方、認証サーバ１２は、ステップＳ１０４での入力パスワードＰＷｉに適用されている認証プロトコルがＭＳ－ＣＨＡＰｖ２の場合、当該入力パスワードＰＷｉを含むアカウントの認証成否をＮＴＬＭ（NT LAN Manager authentication）認証方式等を用いてディレクトリサーバ１３に問い合わせる。このような認証プロトコルと認証方式との対応関係は、パスワードが暗号化されていることが要因となっている。ＮＴＬＭ認証方式では、ＭＳ－ＣＨＡＰｖ２と同様のチャレンジ／レスポンス方式が用いられる。

《前提となる問題点》
ここで、例えば、ＡＤサーバ等のディレクトリサーバ１３において、ケルベロス認証方式は、“ｓａｍＡｃｃｏｕｎｔＮａｍｅ”といった第１の登録ＩＤ（ＩＤｒ［１］）にも、“ＵｓｅｒＰｒｉｎｃｉｐａｌＮａｍｅ”といった第２の登録ＩＤ（ＩＤｒ［２］）にも対応する方式となっている。一方、ＮＴＬＭ認証方式は、第１の登録ＩＤ（ＩＤｒ［１］）に対応し、第２の登録ＩＤ（ＩＤｒ［２］）に対応しない方式となっている。

このため、ネットワーク認証で用いる認証プロトコルとしてＰＡＰが設定されている場合（ひいては、認証サーバ１２がケルベロス認証方式でＡＤサーバに問い合わせる場合）には、特に問題は生じない。すなわち、ユーザ１１がログインページに入力する入力ＩＤ（ＩＤｉ）として、第１の登録ＩＤ（ＩＤｒ［１］）と第２の登録ＩＤ（ＩＤｒ［２］）のいずれを入力した場合でも、ＡＤサーバは、ネットワーク認証の認証成否を正しく判定することができる。

しかし、ネットワーク認証で用いる認証プロトコルとしてＭＳ－ＣＨＡＰｖ２が設定されている場合（ひいては、認証サーバ１２がＮＴＬＭ認証方式でＡＤサーバに問い合わせる場合）には、問題が生じる。すなわち、ユーザ１１がログインページに入力する入力ＩＤ（ＩＤｉ）として第２の登録ＩＤ（ＩＤｒ［２］）を入力した場合、ＡＤサーバは、ネットワーク認証の認証可否を正しく判定することができない。

その結果、ユーザ１１の利便性が低下する恐れがある。具体的には、ネットワーク認証において、ＭＳ－ＣＨＡＰｖ２は、ケルベロス認証方式等と比較して古い方式であるが、実用上、例えば、ユーザ端末ＴＭが旧式である場合を代表に、様々な場合で多く用いられている。一方、ユーザ１１は、このような認証プロトコルの違いに伴うＩＤの使い分けを行うことなく、第１の登録ＩＤ（ＩＤｒ［１］）と第２の登録ＩＤ（ＩＤｒ［２］）のいずれを用いてもネットワーク認証が正しく行われることを望む。

また、近年では、ユーザ１１は、例えば、ディレクトリサーバ１３に対するドメイン認証等の際に、“ＵｓｅｒＰｒｉｎｃｉｐａｌＮａｍｅ”といった第２の登録ＩＤ（ＩＤｒ［２］）を使用する機会が多い。このような状況のもと、ユーザ１１は、ＭＳ－ＣＨＡＰｖ２が適用されている場合には、例えば、ネットワーク認証時のみでログインページに第１の登録ＩＤ（ＩＤｒ［１］）を入力しなければならない。

《認証システムの概略動作（実施の形態１）》
図２は、図１の認証システムの概略的な動作例を示すシーケンス図である。図２において、ステップＳ１０３，Ｓ１０４およびステップＳ１０６，Ｓ１０７に関しては、図１の場合と同様である。図２において、認証スイッチＳＷは、ユーザ端末ＴＭからの未知の通信接続を検知すると（ステップＳ１０１）、ユーザ端末ＴＭに、ログインページのＵＲＬを応答することでユーザ端末ＴＭにログインページを表示させる（ステップＳ１０２）。

これに応じて、ユーザ１１は、ユーザ端末ＴＭに表示されたログインページに自身のアカウント（すなわち、入力ＩＤ（ＩＤｉ）および入力パスワードＰＷｉ）を入力し、ユーザ端末ＴＭは、当該入力されたアカウントを認証スイッチＳＷに送信する（ステップＳ１０３）。認証スイッチＳＷは、入力されたアカウントの認証要求を認証サーバ１２に送信する（ステップＳ１０４）。ここで、認証サーバ１２は、認証スイッチＳＷからの認証要求を受けて、ディレクトリサーバ１３に認証成否を問い合わせる（ステップＳ１０５）。

このステップＳ１０５の際に、認証サーバ１２は、まず、入力ＩＤ（ＩＤｉ）の属性を第２の登録ＩＤ（ＩＤｒ［２］）に定めた状態で、当該入力ＩＤ（ＩＤｉ）を検索キーとして、ディレクトリサーバ１３（すなわちアカウントＤＢ１４）に第２の登録ＩＤ（ＩＤｒ［２］）に対応する第１の登録ＩＤ（ＩＤｒ［１］）の検索要求を送信する（ステップＳ２０１）。この要求に対する応答によって、認証サーバ１２は、ディレクトリサーバ１３から第１の登録ＩＤ（ＩＤｒ［１］）を取得する（ステップＳ２０２）。

この検索要求には、例えば、ＬＤＡＰ検索（具体的にはｌｄａｐｓｅａｒｃｈコマンド等）が用いられる。そして、認証サーバ１２は、取得した第１の登録ＩＤ（ＩＤｒ［１］）と、入力パスワードＰＷｉに対する認証成否を、所定の認証方式（例えば、ケルベロス認証方式またはＮＴＬＭ認証方式）を用いてディレクトリサーバ１３に問い合わせる（ステップＳ２０３）。

なお、ステップＳ２０１において、認証サーバ１２は、入力ＩＤ（ＩＤｉ）の属性（ＬＤＡＰ属性）を第２の登録ＩＤ（ＩＤｒ［２］）に定めた状態でディレクトリサーバ１３に検索要求を送信した。ただし、例えば、入力ＩＤ（ＩＤｉ）が第１の登録ＩＤ（ＩＤｒ［１］）である場合等で、ディレクトリサーバ１３から第１の登録ＩＤ（ＩＤｒ［１］）を取得できないことがある。このような場合（例えば、ディレクトリサーバ１３からエラーが応答された場合）、認証サーバ１２は、入力ＩＤ（ＩＤｉ）を第１の登録ＩＤ（ＩＤｒ［１］）とみなしてステップＳ２０３の処理を行えばよい。

続いて、ディレクトリサーバ１３は、ステップＳ１０５（ステップＳ２０３）での認証成否の問い合わせに応じて、アカウントＤＢ１４の登録内容に基づいて認証成否を判定し、その判定結果を問い合わせ結果として認証サーバ１２に応答する（ステップＳ１０６）。認証サーバ１２は、ステップＳ１０４での認証要求に対する認証結果として、ディレクトリサーバ１３からの問い合わせ結果を認証スイッチＳＷに応答する（ステップＳ１０７）。

ステップＳ１０８において、認証スイッチＳＷは、認証サーバ１２からの認証結果が認証成功を表す場合には、例えば、ユーザ端末ＴＭが接続されているポートを開放すること等でネットワークＮＷへの接続を許可する。一方、認証スイッチＳＷは、認証サーバ１２からの認証結果が認証失敗を表す場合には、例えば、ユーザ端末ＴＭが接続されているポートを閉塞すること等でネットワークＮＷへの接続を禁止する。

このように、認証サーバ１２は、ステップＳ２０１，Ｓ２０２においてディレクトリサーバ１３から第１の登録ＩＤ（ＩＤｒ［１］）を取得することで、仮に、入力ＩＤ（ＩＤｉ）が第２の登録ＩＤ（ＩＤｒ［２］）であったとしても、対応する第１の登録ＩＤ（ＩＤｒ［１］）を用いて認証成否を問い合わせることができる（ステップＳ２０３）。その結果、この認証成否の問い合わせがケルベロス認証方式に限らずＮＴＬＭ認証方式で行われる場合であっても、ディレクトリサーバ１３は、正しく認証成否を判定することが可能になる。

《認証サーバの構成》
図３は、図１（ａ）における認証サーバの主要部の構成例を示すブロック図である。図３に示す認証サーバ１２ａは、認証プロトコル判別部２０と、対象ＩＤ決定部２１と、問い合わせ部２２とを有する。これらの各部は、例えば、認証サーバ１２ａ内のＣＰＵ（Central Processing Unit）を用いたプログラム処理によって実装される。ただし、場合によっては、これらの一部または全ては、ＦＰＧＡ（Field Programmable Gate Array）やＡＳＩＣ（Application Specific Integrated Circuit）等のハードウェアで実装されてもよい。すなわち、これらの各部は、ハードウェアまたはソフトウェアあるいはその組合せを用いて適宜実装されればよい。

認証プロトコル判別部２０は、入力パスワードＰＷｉに適用されている認証プロトコルが第１の認証プロトコル（例えばＰＡＰ）か第２の認証プロトコル（例えばＭＳ－ＣＨＡＰｖ２）かを判別する。具体的には、認証プロトコル判別部２０は、例えば、受信したフレームに含まれるＰＰＰ（Point to Point Protocol）ヘッダの情報等に基づいて認証プロトコルを判別する。

対象ＩＤ決定部２１は、問い合わせ部２２の問い合わせ対象となる対象ＩＤ（ＩＤｑ）を決定する。具体的には、対象ＩＤ決定部２１は、ＩＤ検索部２５を備える。ＩＤ検索部２５は、前述したように、入力ＩＤ（ＩＤｉ）の属性を第２の登録ＩＤ（ＩＤｒ［２］）に定めた状態でディレクトリサーバ１３（アカウントＤＢ１４）に第１の登録ＩＤ（ＩＤｒ［１］）の検索要求を送信することで、第１の登録ＩＤ（ＩＤｒ［１］）を取得する。すなわち、ＩＤ検索部２５は、例えば、認証プロトコル判別部２０の判別結果に関わらず、常に、ディレクトリサーバ１３に検索要求を送信する。そして、対象ＩＤ決定部２１は、ＩＤ検索部２５で取得した第１の登録ＩＤ（ＩＤｒ［１］）を対象ＩＤ（ＩＤｑ）に定める。

一方、対象ＩＤ決定部２１は、認証プロトコル判別部２０の判別結果に基づいて対象ＩＤ（ＩＤｑ）を定めてもよい。具体的には、ＩＤ検索部２５は、認証プロトコル判別部２０の判別結果が第１の認証プロトコル（ＰＡＰ）である場合には、ディレクトリサーバ１３に検索要求を送信しない構成であってもよい。この場合、対象ＩＤ決定部２１は、入力ＩＤ（ＩＤｉ）を対象ＩＤ（ＩＤｑ）に定める。すなわち、ＰＡＰに対応するケルベロス認証方式等では、対象ＩＤ（ＩＤｑ）として、第１の登録ＩＤ（ＩＤｒ［１］）と第２の登録ＩＤ（ＩＤｒ［２］）のいずれを用いることも可能である。

問い合わせ部２２は、対象ＩＤ決定部２１で定められた対象ＩＤ（ＩＤｑ）と、入力パスワードＰＷｉに対する認証成否をディレクトリサーバ１３に問い合わせる。この際に、問い合わせ部２２は、認証プロトコル判別部２０の判別結果が第１の認証プロトコル（ＰＡＰ）である場合にはディレクトリサーバ１３との間で第１の認証方式（ケルベロス認証方式等）を用いて認証成否を問い合わせる。一方、問い合わせ部２２は、認証プロトコル判別部２０の判別結果が第２の認証プロトコル（ＭＳ－ＣＨＡＰｖ２）である場合にはディレクトリサーバ１３との間で第２の認証方式（ＮＴＬＭ認証方式等）を用いて認証成否を問い合わせる。

この際に、対象ＩＤ（ＩＤｑ）は、前述した対象ＩＤ決定部２１の処理に伴い、第２の認証方式（ＮＴＬＭ認証方式等）を用いて認証成否の問い合わせが行われる場合には、第１の登録ＩＤ（ＩＤｒ［１］）に定められる。一方、対象ＩＤ（ＩＤｑ）は、第１の認証方式（ケルベロス認証方式等）を用いて認証成否の問い合わせが行われる場合には、ＩＤ検索部２５を介して第１の登録ＩＤ（ＩＤｒ［１］）に定められるか、または、ＩＤ検索部２５を介さずに入力ＩＤ（ＩＤｉ）に定められる。

《認証サーバの動作［１］》
図４は、図３の認証サーバにおける処理内容の一例を示すフロー図である。図４において、認証サーバ１２ａは、ユーザ１１によって入力されたアカウント（入力ＩＤ（ＩＤｉ）および入力パスワードＰＷｉ）に対する認証スイッチＳＷからの認証要求を受信する（ステップＳ１０４）。これを受けて、認証プロトコル判別部２０は、入力パスワードＰＷｉに適用されている認証プロトコルがＰＡＰ（第１の認証プロトコル）かＭＳ－ＣＨＡＰｖ２（第２の認証プロトコル）かを判別する（ステップＳ３０１，Ｓ３０６）。

認証プロトコル判別部２０の判別結果がＰＡＰである場合（ステップＳ３０１：Ｙｅｓ）、ＩＤ検索部２５は、入力ＩＤ（ＩＤｉ）の属性を第２の登録ＩＤ（ＩＤｒ［２］）に定めた状態で、ディレクトリサーバ１３に、対応する第１の登録ＩＤ（ＩＤｒ［１］）の検索要求を送信することで第１の登録ＩＤ（ＩＤｒ［１］）を取得する（ステップＳ３０２）。そして、第１の登録ＩＤ（ＩＤｒ［１］）を取得できた場合（ステップＳ３０３：Ｙｅｓ）、問い合わせ部２２は、取得された第１の登録ＩＤ（ＩＤｒ［１］）と、入力パスワードＰＷｉに対する認証成否を、ケルベロス認証方式を用いてディレクトリサーバ１３に問い合わせる（ステップＳ３０４）。

一方、ステップＳ３０２で第１の登録ＩＤ（ＩＤｒ［１］）を取得できなかった場合（ステップＳ３０３：Ｎｏ）、問い合わせ部２２は、入力ＩＤ（ＩＤｉ）と入力パスワードＰＷｉに対する認証成否を、ケルベロス認証方式を用いてディレクトリサーバ１３に問い合わせる（ステップＳ３０５）。第１の登録ＩＤ（ＩＤｒ［１］）を取得できなかった場合とは、例えば、入力ＩＤ（ＩＤｉ）が第１の登録ＩＤ（ＩＤｒ［１］）である場合や、入力ＩＤ（ＩＤｉ）が第１の登録ＩＤ（ＩＤｒ［１］）および第２の登録ＩＤ（ＩＤｒ［２］）のいずれにも該当しない場合等である。

また、認証プロトコル判別部２０の判別結果がＭＳ－ＣＨＡＰｖ２である場合（ステップＳ３０６：Ｙｅｓ）、ＩＤ検索部２５は、ステップＳ３０２の場合と同様、ディレクトリサーバ１３に、入力ＩＤ（ＩＤｉ）に対応する第１の登録ＩＤ（ＩＤｒ［１］）の検索要求を送信することで第１の登録ＩＤ（ＩＤｒ［１］）を取得する（ステップＳ３０７）。すなわち、ＩＤ検索部２５は、認証プロトコル判別部２０の判別結果がＰＡＰであるか（ステップＳ３０１：Ｙｅｓ）、ＭＳ－ＣＨＡＰｖ２であるか（ステップＳ３０６：Ｙｅｓ）に関わらず、常に、ディレクトリサーバ１３に検索要求を送信する。

ステップＳ３０７で第１の登録ＩＤ（ＩＤｒ［１］）を取得できた場合（ステップＳ３０８：Ｙｅｓ）、問い合わせ部２２は、取得された第１の登録ＩＤ（ＩＤｒ［１］）と、入力パスワードＰＷｉに対する認証成否を、ＮＴＬＭ認証方式を用いてディレクトリサーバ１３に問い合わせる（ステップＳ３０９）。一方、ステップＳ３０７で第１の登録ＩＤ（ＩＤｒ［１］）を取得できなかった場合（ステップＳ３０８：Ｎｏ）、問い合わせ部２２は、入力ＩＤ（ＩＤｉ）と入力パスワードＰＷｉに対する認証成否を、ＮＴＬＭ認証方式を用いてディレクトリサーバ１３に問い合わせる（ステップＳ３１０）。

なお、認証プロトコル判別部２０の判別結果がＰＡＰでもＭＳ－ＣＨＡＰｖ２でもない場合（ステップＳ３０６：Ｎｏ）、認証サーバ１２ａは、例えば、所定のエラー処理等を実行する（ステップＳ３１１）。

このような処理を用いると、原則として、第１の登録ＩＤ（ＩＤｒ［１］）を対象に、ディレクトリサーバ１３に対する認証成否の問い合わせが行われる。その結果、ユーザが入力ＩＤ（ＩＤｉ）として第１の登録ＩＤ（ＩＤｒ［１］）または第２の登録ＩＤ（ＩＤｒ［２］）のいずれを入力した場合でも、ネットワーク認証の認証可否を正しく判定することができ、ユーザの利便性を向上させることが可能になる。

《認証サーバの動作［２］》
図５は、図３の認証サーバにおける処理内容の他の一例を示すフロー図である。図５に示すフローは、図４に示したフローと比較して、ステップＳ３０２～Ｓ３０４が削除されたものとなっている。すなわち、認証プロトコル判別部２０の判別結果がＰＡＰである場合（ステップＳ３０１：Ｙｅｓ）、ＩＤ検索部２５は、図４の場合と異なりディレクトリサーバ１３に検索要求を送信しない。この場合、問い合わせ部２２は、入力ＩＤ（ＩＤｉ）と入力パスワードＰＷｉに対する認証成否を、ケルベロス認証方式を用いてディレクトリサーバ１３に問い合わせる（ステップＳ３０５）。

このような処理を用いると、認証プロトコル判別部２０の判別結果がＰＡＰである場合に、ディレクトリサーバ１３に対する検索を行わずに済む。その結果、例えば、認証サーバ１２ａとディレクトリサーバ１３との間の通信負荷を軽減すること等が可能になる。

《実施の形態１の主要な効果》
以上、実施の形態１の認証サーバおよび認証システムを用いることで、代表的には、ユーザの利便性を向上させることが可能になる。具体的には、ユーザは、認証プロトコルの違い意識する必要がなく、入力ＩＤ（ＩＤｉ）として第１の登録ＩＤ（ＩＤｒ［１］）と第２の登録ＩＤ（ＩＤｒ［２］）のいずれを用いた場合であってもネットワーク認証を正しく行わせることが可能になる。特に、ユーザは、“ＵｓｅｒＰｒｉｎｃｉｐａｌＮａｍｅ”といった使用頻度が高い第２の登録ＩＤ（ＩＤｒ［２］）を常時用いてネットワーク認証を正しく行わせることが可能になる。言い換えれば、ユーザは、ネットワーク認証時のみで第１の登録ＩＤ（ＩＤｒ［１］）を入力するといったような使い分けをする必要がない。

（実施の形態２）
《認証サーバの構成》
図６は、本発明の実施の形態２による認証システムにおいて、図１（ａ）における認証サーバの主要部の構成例を示すブロック図である。図６に示す認証サーバ１２ｂは、図３に示した認証サーバ１２ａと比較して、対象ＩＤ決定部３１の構成が異なっている。対象ＩＤ決定部３１は、図３に示したようなＩＤ検索部２５に加えて、ＩＤフォーマット判別部３２を備える。

ＩＤフォーマット判別部３２は、入力ＩＤ（ＩＤｉ）のフォーマットが第１の登録ＩＤ（ＩＤｒ［１］）のフォーマットか第２の登録ＩＤのフォーマット（ＩＤｒ［２］）かを判別する。具体的には、“ＵｓｅｒＰｒｉｎｃｉｐａｌＮａｍｅ”といった第２の登録ＩＤは、“ｓａｍＡｃｃｏｕｎｔＮａｍｅ”といった第１の登録ＩＤ（ＩＤｒ［１］）と異なり、“＠ドメイン名”を含んだフォーマットになっている。このため、ＩＤフォーマット判別部３２は、例えば、入力ＩＤ（ＩＤｉ）に“＠ドメイン名”が含まれる場合には、入力ＩＤ（ＩＤｉ）を第２の登録ＩＤ（ＩＤｒ［２］）とみなし、“＠ドメイン名”が含まれない場合には、入力ＩＤ（ＩＤｉ）を第１の登録ＩＤ（ＩＤｒ［１］）とみなせばよい。

ここで、ＩＤフォーマット判別部３２の判別結果が第１の登録ＩＤ（ＩＤｒ［１］）のフォーマットである場合には、ＩＤ検索部２５は、ディレクトリサーバ１３に検索要求を送信しない。この場合、対象ＩＤ決定部３１は、対象ＩＤ（ＩＤｑ）を入力ＩＤ（ＩＤｉ）に定める。一方、ＩＤフォーマット判別部３２の判別結果が第２の登録ＩＤ（ＩＤｒ［２］）のフォーマットである場合には、ＩＤ検索部２５は、ディレクトリサーバ１３に常に検索要求を送信するか、または、認証プロトコル判別部２０の判別結果に基づいて検索要求の送信有無を使い分ける。

《認証サーバの動作［１］》
図７は、図６の認証サーバにおける処理内容の一例を示すフロー図である。図７に示すフローは、図４に示したフローに対して、ＩＤフォーマット判別部３２の処理を追加したものとなっている。図７において、ステップＳ１０４，Ｓ３０１，Ｓ３０６，Ｓ３１１に関しては、図４の場合と同様である。

図７において、認証プロトコル判別部２０の判別結果がＰＡＰである場合（ステップＳ３０１：Ｙｅｓ）、ＩＤフォーマット判別部３２は、入力ＩＤ（ＩＤｉ）のフォーマットが第１の登録ＩＤ（ＩＤｒ［１］）のフォーマットか第２の登録ＩＤ（ＩＤｒ［２］）のフォーマット（ＩＤｒ［２］）かを判別する（ステップＳ４０１）。言い換えれば、ＩＤフォーマット判別部３２は、入力ＩＤ（ＩＤｉ）を第１の登録ＩＤ（ＩＤｒ［１］）とみなすか第２の登録ＩＤ（ＩＤｒ［２］）とみなす。

入力ＩＤ（ＩＤｉ）が第１の登録ＩＤ（ＩＤｒ［１］）とみなされた場合（ステップＳ４０１：Ｎｏ）、ステップＳ３０４への移行が行われる。一方、入力ＩＤ（ＩＤｉ）が第２の登録ＩＤ（ＩＤｒ［２］）とみなされた場合（ステップＳ４０１：Ｙｅｓ）、ＩＤ検索部２５が、図４のステップＳ３０２等の場合と同様にしてディレクトリサーバ１３から第１の登録ＩＤ（ＩＤｒ［１］）を取得したのち（ステップＳ４０２）、ステップＳ３０４への移行が行われる。

ステップＳ３０４において、問い合わせ部２２は、第１の登録ＩＤ（ＩＤｒ［１］）と入力パスワードＰＷｉに対する認証成否を、ケルベロス認証方式を用いてディレクトリサーバ１３に問い合わせる。この際に、問い合わせ対象の第１の登録ＩＤ（ＩＤｒ［１］）は、ステップＳ４０１で第１の登録ＩＤ（ＩＤｒ［１］）とみなされた入力ＩＤ（ＩＤｉ）、または、ステップＳ４０２でディレクトリサーバ１３から取得された第１の登録ＩＤ（ＩＤｒ［１］）に該当する。

また、認証プロトコル判別部２０の判別結果がＭＳ－ＣＨＡＰｖ２である場合（ステップＳ３０６：Ｙｅｓ）、ＩＤフォーマット判別部３２は、ステップＳ４０１の場合と同様に、入力ＩＤ（ＩＤｉ）を第１の登録ＩＤ（ＩＤｒ［１］）とみなすか第２の登録ＩＤ（ＩＤｒ［２］）とみなす。すなわち、ＩＤフォーマット判別部３２は、認証プロトコル判別部２０の判別結果がＰＡＰであるか（ステップＳ３０１：Ｙｅｓ）、ＭＳ－ＣＨＡＰｖ２であるか（ステップＳ３０６：Ｙｅｓ）に関わらず、フォーマットの判別処理を行う。

入力ＩＤ（ＩＤｉ）が第１の登録ＩＤ（ＩＤｒ［１］）とみなされた場合（ステップＳ４０３：Ｎｏ）、ステップＳ３０９への移行が行われる。一方、入力ＩＤ（ＩＤｉ）が第２の登録ＩＤ（ＩＤｒ［２］）とみなされた場合（ステップＳ４０３：Ｙｅｓ）、ＩＤ検索部２５が、図４のステップＳ３０２等の場合と同様にしてディレクトリサーバ１３から第１の登録ＩＤ（ＩＤｒ［１］）を取得したのち（ステップＳ４０４）、ステップＳ３０９への移行が行われる。

ステップＳ３０９において、問い合わせ部２２は、第１の登録ＩＤ（ＩＤｒ［１］）と入力パスワードＰＷｉに対する認証成否を、ＮＴＬＭ認証方式を用いてディレクトリサーバ１３に問い合わせる。この際に、問い合わせ対象の第１の登録ＩＤ（ＩＤｒ［１］）は、ステップＳ４０３で第１の登録ＩＤ（ＩＤｒ［１］）とみなされた入力ＩＤ（ＩＤｉ）、または、ステップＳ４０４でディレクトリサーバ１３から取得された第１の登録ＩＤ（ＩＤｒ［１］）に該当する。

このような処理を用いると、図４の場合と同様に、原則として、第１の登録ＩＤ（ＩＤｒ［１］）を対象にディレクトリサーバ１３に対して認証成否を問い合わせることができる。さらに、図４の場合と比較して、ディレクトリサーバ１３に対する検索回数を減らすことができる。具体的には、ステップＳ４０２，Ｓ４０４において、ＩＤ検索部２５は、図４の場合と異なり、ＩＤフォーマット判別部３２によって入力ＩＤ（ＩＤｉ）が第２の登録ＩＤ（ＩＤｒ［２］）とみなされた場合に、ディレクトリサーバ１３に検索要求を送信すればよい。その結果、図４の場合と比較して、例えば、認証サーバ１２ｂとディレクトリサーバ１３との間の通信負荷を軽減することが可能になる。

《認証サーバの動作［２］》
図８は、図６の認証サーバにおける処理内容の他の一例を示すフロー図である。図８に示すフローは、図５に示したフローに対して、ＩＤフォーマット判別部３２の処理を追加したものとなっている。また、図８に示すフローは、図７に示したフローにおけるステップＳ４０１，Ｓ４０２，Ｓ３０４をステップＳ３０５に置き換えたものとなっている。

すなわち、認証プロトコル判別部２０の判別結果がＰＡＰである場合（ステップＳ３０１：Ｙｅｓ）、図７の場合と異なり、ＩＤフォーマット判別部３２はフォーマットの判別処理を行わず、ＩＤ検索部２５もディレクトリサーバ１３に検索要求を送信しない。この場合、問い合わせ部２２は、入力ＩＤ（ＩＤｉ）と入力パスワードＰＷｉに対する認証成否を、ケルベロス認証方式を用いてディレクトリサーバ１３に問い合わせる（ステップＳ３０５）。

このような処理を用いると、図７の場合と比較して、認証プロトコル判別部２０の判別結果がＰＡＰである場合に、ＩＤフォーマット判別部３２およびＩＤ検索部２５の処理を行わずに済む。その結果、認証サーバ１２ｂの処理負荷や、認証サーバ１２ｂとディレクトリサーバ１３との間の通信負荷を軽減することが可能になる。また、図５の場合と比較して、認証サーバ１２ｂとディレクトリサーバ１３との間の通信負荷を更に軽減することが可能になる。すなわち、図８のステップＳ４０４において、ＩＤ検索部２５は、図５の場合と異なり、ＩＤフォーマット判別部３２によって入力ＩＤ（ＩＤｉ）が第２の登録ＩＤ（ＩＤｒ［２］）とみなされた場合に、ディレクトリサーバ１３に検索要求を送信すればよい。

《実施の形態２の主要な効果》
以上、実施の形態２の認証サーバおよび認証システムを用いることで、実施の形態１で述べた各種効果に加えて、さらに、認証サーバ１２ｂとディレクトリサーバ１３との間の通信負荷を軽減すること等が可能になる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。例えば、前述した実施の形態は、本発明を分かり易く説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施の形態の構成の一部を他の実施の形態の構成に置き換えることが可能であり、また、ある実施の形態の構成に他の実施の形態の構成を加えることも可能である。また、各実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

１１ ユーザ
１２，１２ａ，１２ｂ 認証サーバ
１３ ディレクトリサーバ
１４ アカウントＤＢ
２０ 認証プロトコル判別部
２１，３１ 対象ＩＤ決定部
２２ 問い合わせ部
２５ ＩＤ検索部
３２ ＩＤフォーマット判別部
ＩＤｉ 入力ＩＤ
ＩＤｑ 対象ＩＤ
ＩＤｒ［１］ 第１の登録ＩＤ
ＩＤｒ［２］ 第２の登録ＩＤ
ＮＷ ネットワーク
ＰＷｉ 入力パスワード
ＰＷｒ 登録パスワード
ＳＷ 認証スイッチ
ＴＭ ユーザ端末

Claims (8)

1. ユーザによって入力された入力ＩＤおよび入力パスワードに対する認証要求を受信し、外部のディレクトリサーバに認証成否を問い合わせる認証サーバであって、
   前記ディレクトリサーバは、同一の前記ユーザに対して定められる第１の登録ＩＤと第２の登録ＩＤと登録パスワードとの対応関係を保持し、
   前記認証サーバは、
   前記入力ＩＤの属性を前記第２の登録ＩＤに定めた状態で前記ディレクトリサーバに前記第２の登録ＩＤに対応する前記第１の登録ＩＤの検索要求を送信し、前記ディレクトリサーバから前記第１の登録ＩＤを取得するＩＤ検索部と、
   前記ＩＤ検索部で取得した前記第１の登録ＩＤと、前記入力パスワードに対する認証成否を前記ディレクトリサーバに問い合わせる問い合わせ部と、
   を有する、
   認証サーバ。
2. 請求項１記載の認証サーバにおいて、
   前記入力パスワードに適用されている認証プロトコルが第１の認証プロトコルか第２の認証プロトコルかを判別する認証プロトコル判別部を有し、
   前記問い合わせ部は、前記認証プロトコル判別部の判別結果が前記第１の認証プロトコルである場合には前記ディレクトリサーバとの間で第１の認証方式を用いて認証成否を問い合わせ、前記第２の認証プロトコルである場合には前記ディレクトリサーバとの間で第２の認証方式を用いて認証成否を問い合わせ、
   前記第１の認証方式は、前記第１の登録ＩＤにも前記第２の登録ＩＤにも対応する方式であり、
   前記第２の認証方式は、前記第２の登録ＩＤに対応しない方式であり、
   前記認証プロトコル判別部の判別結果が前記第１の認証プロトコルである場合、前記ＩＤ検索部は、前記ディレクトリサーバに前記検索要求を送信せず、前記問い合わせ部は、前記入力ＩＤと前記入力パスワードに対する認証成否を前記ディレクトリサーバに問い合わせる、
   認証サーバ。
3. 請求項２記載の認証サーバにおいて、
   前記第２の認証方式は、ＮＴＬＭ（NT LAN Manager authentication）認証方式である、
   認証サーバ。
4. 請求項１～３のいずれか１項に記載の認証サーバにおいて、
   前記入力ＩＤのフォーマットが前記第１の登録ＩＤのフォーマットか前記第２の登録ＩＤのフォーマットかを判別するＩＤフォーマット判別部を有し、
   前記ＩＤ検索部は、前記ＩＤフォーマット判別部の判別結果が前記第１の登録ＩＤのフォーマットである場合には、前記ディレクトリサーバに前記検索要求を送信しない、
   認証サーバ。
5. 同一のユーザに対して定められる第１の登録ＩＤと第２の登録ＩＤと登録パスワードとの対応関係を保持するディレクトリサーバと、
   前記ディレクトリサーバとネットワークで接続され、前記ユーザによって入力された入力ＩＤおよび入力パスワードに対する認証要求を受信し、前記ディレクトリサーバに認証成否を問い合わせる認証サーバと、
   を有する認証システムであって、
   前記認証サーバは、
   前記入力ＩＤの属性を前記第２の登録ＩＤに定めた状態で前記ディレクトリサーバに前記第２の登録ＩＤに対応する前記第１の登録ＩＤの検索要求を送信し、前記ディレクトリサーバから前記第１の登録ＩＤを取得するＩＤ検索部と、
   前記ＩＤ検索部で取得した前記第１の登録ＩＤと、前記入力パスワードに対する認証成否を前記ディレクトリサーバに問い合わせる問い合わせ部と、
   を有する、
   認証システム。
6. 請求項５記載の認証システムにおいて、
   前記認証サーバは、
   前記入力パスワードに適用されている認証プロトコルが第１の認証プロトコルか第２の認証プロトコルかを判別する認証プロトコル判別部を有し、
   前記問い合わせ部は、前記認証プロトコル判別部の判別結果が前記第１の認証プロトコルである場合には前記ディレクトリサーバとの間で第１の認証方式を用いて認証成否を問い合わせ、前記第２の認証プロトコルである場合には前記ディレクトリサーバとの間で第２の認証方式を用いて認証成否を問い合わせ、
   前記第１の認証方式は、前記第１の登録ＩＤにも前記第２の登録ＩＤにも対応する方式であり、
   前記第２の認証方式は、前記第２の登録ＩＤに対応しない方式であり、
   前記認証プロトコル判別部の判別結果が前記第１の認証プロトコルである場合、前記ＩＤ検索部は、前記ディレクトリサーバに前記検索要求を送信せず、前記問い合わせ部は、前記入力ＩＤと前記入力パスワードに対する認証成否を前記ディレクトリサーバに問い合わせる、
   認証システム。
7. 請求項６記載の認証システムにおいて、
   前記第２の認証方式は、ＮＴＬＭ（NT LAN Manager authentication）認証方式である、
   認証システム。
8. 請求項５～７のいずれか１項に記載の認証システムにおいて、
   前記認証サーバは、
   前記入力ＩＤのフォーマットが前記第１の登録ＩＤのフォーマットか前記第２の登録ＩＤのフォーマットかを判別するＩＤフォーマット判別部を有し、
   前記ＩＤ検索部は、前記ＩＤフォーマット判別部の判別結果が前記第１の登録ＩＤのフォーマットである場合には、前記ディレクトリサーバに前記検索要求を送信しない、
   認証システム。

Images