IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 日立電線ネットワークス株式会社の特許一覧

<>
  • 特許-認証サーバおよび認証システム 図1
  • 特許-認証サーバおよび認証システム 図2
  • 特許-認証サーバおよび認証システム 図3
  • 特許-認証サーバおよび認証システム 図4
  • 特許-認証サーバおよび認証システム 図5
  • 特許-認証サーバおよび認証システム 図6
  • 特許-認証サーバおよび認証システム 図7
  • 特許-認証サーバおよび認証システム 図8
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-02-14
(45)【発行日】2023-02-22
(54)【発明の名称】認証サーバおよび認証システム
(51)【国際特許分類】
   G06F 21/31 20130101AFI20230215BHJP
   G06F 21/45 20130101ALI20230215BHJP
【FI】
G06F21/31
G06F21/45
【請求項の数】 8
(21)【出願番号】P 2019225518
(22)【出願日】2019-12-13
(65)【公開番号】P2021096512
(43)【公開日】2021-06-24
【審査請求日】2022-04-04
(73)【特許権者】
【識別番号】300059979
【氏名又は名称】エイチ・シー・ネットワークス株式会社
(74)【代理人】
【識別番号】110002066
【氏名又は名称】弁理士法人筒井国際特許事務所
(72)【発明者】
【氏名】江藤 馨
(72)【発明者】
【氏名】西野宮 浩志
(72)【発明者】
【氏名】柴田 功克
(72)【発明者】
【氏名】益子 秀隆
【審査官】宮司 卓佳
(56)【参考文献】
【文献】特開2007-128208(JP,A)
【文献】特開2010-134797(JP,A)
【文献】特開2008-234210(JP,A)
【文献】特開2010-166365(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 21/31-21/46
(57)【特許請求の範囲】
【請求項1】
ユーザによって入力された入力IDおよび入力パスワードに対する認証要求を受信し、外部のディレクトリサーバに認証成否を問い合わせる認証サーバであって、
前記ディレクトリサーバは、同一の前記ユーザに対して定められる第1の登録IDと第2の登録IDと登録パスワードとの対応関係を保持し、
前記認証サーバは、
前記入力IDの属性を前記第2の登録IDに定めた状態で前記ディレクトリサーバに前記第2の登録IDに対応する前記第1の登録IDの検索要求を送信し、前記ディレクトリサーバから前記第1の登録IDを取得するID検索部と、
前記ID検索部で取得した前記第1の登録IDと、前記入力パスワードに対する認証成否を前記ディレクトリサーバに問い合わせる問い合わせ部と、
を有する、
認証サーバ。
【請求項2】
請求項1記載の認証サーバにおいて、
前記入力パスワードに適用されている認証プロトコルが第1の認証プロトコルか第2の認証プロトコルかを判別する認証プロトコル判別部を有し、
前記問い合わせ部は、前記認証プロトコル判別部の判別結果が前記第1の認証プロトコルである場合には前記ディレクトリサーバとの間で第1の認証方式を用いて認証成否を問い合わせ、前記第2の認証プロトコルである場合には前記ディレクトリサーバとの間で第2の認証方式を用いて認証成否を問い合わせ、
前記第1の認証方式は、前記第1の登録IDにも前記第2の登録IDにも対応する方式であり、
前記第2の認証方式は、前記第2の登録IDに対応しない方式であり、
前記認証プロトコル判別部の判別結果が前記第1の認証プロトコルである場合、前記ID検索部は、前記ディレクトリサーバに前記検索要求を送信せず、前記問い合わせ部は、前記入力IDと前記入力パスワードに対する認証成否を前記ディレクトリサーバに問い合わせる、
認証サーバ。
【請求項3】
請求項2記載の認証サーバにおいて、
前記第2の認証方式は、NTLM(NT LAN Manager authentication)認証方式である、
認証サーバ。
【請求項4】
請求項1~3のいずれか1項に記載の認証サーバにおいて、
前記入力IDのフォーマットが前記第1の登録IDのフォーマットか前記第2の登録IDのフォーマットかを判別するIDフォーマット判別部を有し、
前記ID検索部は、前記IDフォーマット判別部の判別結果が前記第1の登録IDのフォーマットである場合には、前記ディレクトリサーバに前記検索要求を送信しない、
認証サーバ。
【請求項5】
同一のユーザに対して定められる第1の登録IDと第2の登録IDと登録パスワードとの対応関係を保持するディレクトリサーバと、
前記ディレクトリサーバとネットワークで接続され、前記ユーザによって入力された入力IDおよび入力パスワードに対する認証要求を受信し、前記ディレクトリサーバに認証成否を問い合わせる認証サーバと、
を有する認証システムであって、
前記認証サーバは、
前記入力IDの属性を前記第2の登録IDに定めた状態で前記ディレクトリサーバに前記第2の登録IDに対応する前記第1の登録IDの検索要求を送信し、前記ディレクトリサーバから前記第1の登録IDを取得するID検索部と、
前記ID検索部で取得した前記第1の登録IDと、前記入力パスワードに対する認証成否を前記ディレクトリサーバに問い合わせる問い合わせ部と、
を有する、
認証システム。
【請求項6】
請求項5記載の認証システムにおいて、
前記認証サーバは、
前記入力パスワードに適用されている認証プロトコルが第1の認証プロトコルか第2の認証プロトコルかを判別する認証プロトコル判別部を有し、
前記問い合わせ部は、前記認証プロトコル判別部の判別結果が前記第1の認証プロトコルである場合には前記ディレクトリサーバとの間で第1の認証方式を用いて認証成否を問い合わせ、前記第2の認証プロトコルである場合には前記ディレクトリサーバとの間で第2の認証方式を用いて認証成否を問い合わせ、
前記第1の認証方式は、前記第1の登録IDにも前記第2の登録IDにも対応する方式であり、
前記第2の認証方式は、前記第2の登録IDに対応しない方式であり、
前記認証プロトコル判別部の判別結果が前記第1の認証プロトコルである場合、前記ID検索部は、前記ディレクトリサーバに前記検索要求を送信せず、前記問い合わせ部は、前記入力IDと前記入力パスワードに対する認証成否を前記ディレクトリサーバに問い合わせる、
認証システム。
【請求項7】
請求項6記載の認証システムにおいて、
前記第2の認証方式は、NTLM(NT LAN Manager authentication)認証方式である、
認証システム。
【請求項8】
請求項5~7のいずれか1項に記載の認証システムにおいて、
前記認証サーバは、
前記入力IDのフォーマットが前記第1の登録IDのフォーマットか前記第2の登録IDのフォーマットかを判別するIDフォーマット判別部を有し、
前記ID検索部は、前記IDフォーマット判別部の判別結果が前記第1の登録IDのフォーマットである場合には、前記ディレクトリサーバに前記検索要求を送信しない、
認証システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、認証サーバおよび認証システムに関し、例えば、RADIUS(Remote Authentication Dial In User Service)サーバを用いた認証技術に関する。
【背景技術】
【0002】
特許文献1には、認証サーバに対してユーザ認証を求める画像処理装置が示される。当該画像処理装置は、ユーザによって入力されたユーザIDを検索キーとしてディレクトリサーバに検索要求を送信することで認証用ユーザIDを取得し、当該認証用ユーザIDを用いて認証サーバに対してユーザ認証を求める。これにより、ユーザは、ディレクトリサーバ上で認証用ユーザIDに対応付けられる各種ユーザ属性(電話番号、社員番号等)の中の予め定めた一つ属性をユーザIDとして入力すればよく、認証用ユーザIDが長い場合等でユーザIDの入力操作を簡単にすることができる。
【先行技術文献】
【特許文献】
【0003】
【文献】特開2007-128208号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
ネットワーク認証を行う認証サーバとして、RADIUSサーバが広く知られている。このような認証サーバは、正しいID(ユーザ識別子)およびパスワードが予め登録されたアカウントデータベース(アカウントDBと略す)に基づいて、IDおよびパスワードを入力したユーザに対するネットワーク認証を行う。アカウントDBは、認証サーバ内に設けられる場合の他に、Active Directory(登録商標)サーバ(ADサーバと略す)を代表とする外部のディレクトリサーバに設けられる場合がある。後者の場合、認証サーバは、ディレクトリサーバと連携してネットワーク認証を行う。
【0005】
一方、ユーザは、例えば、“samAccountName”や“UserPrincipalName”といったように、異なる2種類のIDを有する場合がある。ただし、特に、認証サーバがディレクトリサーバと連携してネットワーク認証を行う場合、各種条件に応じて、例えば、2種類のIDの両方を使用できる場合や、一方のみを使用できる場合がある。その結果、ユーザに、IDの使い分けを要求することになり、ユーザの利便性が低下する恐れがある。
【0006】
本発明は、このようなことに鑑みてなされたものであり、その目的の一つは、ユーザの利便性を向上させることが可能な認証サーバおよび認証システムを提供することにある。
【0007】
本発明の前記並びにその他の目的と新規な特徴は、本明細書の記述及び添付図面から明らかになるであろう。
【課題を解決するための手段】
【0008】
本願において開示される発明のうち、代表的な実施の形態の概要を簡単に説明すれば、次のとおりである。
【0009】
一実施の形態による認証サーバは、ID検索部と、問い合わせ部とを有し、ユーザによって入力された入力IDおよび入力パスワードに対する認証要求を受信し、外部のディレクトリサーバに認証成否を問い合わせる。ディレクトリサーバは、同一のユーザに対して定められる第1の登録IDと第2の登録IDと登録パスワードとの対応関係を保持する。ID検索部は、入力IDの属性を第2の登録IDに定めた状態でディレクトリサーバに第2の登録IDに対応する第1の登録IDの検索要求を送信し、ディレクトリサーバから第1の登録IDを取得する。問い合わせ部は、ID検索部で取得した第1の登録IDと、入力パスワードに対する認証成否をディレクトリサーバに問い合わせる。
【発明の効果】
【0010】
本願において開示される発明のうち、代表的な実施の形態によって得られる効果を簡単に説明すると、ユーザの利便性を向上させることが可能になる。
【図面の簡単な説明】
【0011】
図1】(a)は、本発明の実施の形態1による認証システムの主要部の構成例および動作例を示す概略図であり、(b)は、(a)におけるディレクトリサーバが備えるアカウントDBの構成例を示す概略図である。
図2図1の認証システムの概略的な動作例を示すシーケンス図である。
図3図1(a)における認証サーバの主要部の構成例を示すブロック図である。
図4図3の認証サーバにおける処理内容の一例を示すフロー図である。
図5図3の認証サーバにおける処理内容の他の一例を示すフロー図である。
図6】本発明の実施の形態2による認証システムにおいて、図1(a)における認証サーバの主要部の構成例を示すブロック図である。
図7図6の認証サーバにおける処理内容の一例を示すフロー図である。
図8図6の認証サーバにおける処理内容の他の一例を示すフロー図である。
【発明を実施するための形態】
【0012】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。
【0013】
(実施の形態1)
《認証システムの概略》
図1(a)は、本発明の実施の形態1による認証システムの主要部の構成例および動作例を示す概略図であり、図1(b)は、図1(a)におけるディレクトリサーバが備えるアカウントDBの構成例を示す概略図である。図1(a)に示す認証システムは、ネットワークNWに接続される認証スイッチSW、認証サーバ12およびディレクトリサーバ13と、認証スイッチSWに接続されるユーザ端末TMとを備える。ネットワークNWは、例えば、OSI参照モデルのレイヤ3(L3)のネットワーク等である。
【0014】
認証サーバ12は、例えば、RADIUSサーバである。認証スイッチSWは、RADIUSクライアントの機能を搭載したイーサネット(登録商標)スイッチ等である。ただし、RADIUSクライアントとして、認証スイッチSWの代わりに無線LANアクセスポイント等が設けられてもよい。認証スイッチSWは、例えば、ユーザ端末TMにログインページを提供する機能(Web認証機能)や、IEEE802.1Xのオーセンティケータ機能等を有する。
【0015】
ディレクトリサーバ13は、例えば、ADサーバ等を代表とするLDAP(Lightweight Directory Access Protocol)サーバである。ディレクトリサーバ13は、アカウントDB14を備える。アカウントDB14は、図1(b)に示されるように、同一のユーザ11に対して定められる第1の登録ID(IDr[1])と第2の登録ID(IDr[2])と登録パスワードPWrとの対応関係を保持する。例えば、ADサーバを用いる場合、第1の登録ID(IDr[1])は、“samAccountName”である。一方、第2の登録ID(IDr[2])は、“UserPrincipalName”であり、“ユーザ名@ドメイン名”のフォーマットを有する。
【0016】
このような構成において、認証サーバ12は、ユーザ11に対するネットワーク認証(RADIUS認証)を行う場合、ユーザ11によって入力された入力ID(IDi)および入力パスワードPWiに対する認証要求を受信し、外部のディレクトリサーバ13に認証成否を問い合わせる。
【0017】
具体的には、まず、ユーザ端末TMは、例えばログインページを介してユーザ11によって入力された入力ID(IDi)および入力パスワードPWiを、認証スイッチSWに送信する(ステップS103)。これを受けて、認証スイッチSWは、入力ID(IDi)および入力パスワードPWiの認証要求を、認証サーバ12に送信する(ステップS104)。
【0018】
続いて、認証サーバ12は、認証要求に応じて、アカウントDB14を有するディレクトリサーバ13に、IDおよびパスワードに対する認証成否を問い合わせる(ステップS105)。ディレクトリサーバ13は、ステップS105に伴うIDおよびパスワードがアカウントDB14の登録情報と一致する場合には認証成功と判定し、不一致の場合には認証失敗と判定する。そして、ディレクトリサーバ13は、認証成否の判定結果を、問い合わせ結果として認証サーバ12に送信する(ステップS106)。
【0019】
認証サーバ12は、ディレクトリサーバ13からの問い合わせ結果(ステップS106)を認証結果として認証スイッチSWに送信する(ステップS107)。認証スイッチSWは、認証結果が認証成功を表す場合には、ユーザ端末TMのネットワークNWへの接続を許可し、認証失敗を表す場合には、ユーザ端末TMのネットワークNWへの接続を禁止する。
【0020】
ここで、ステップS103,S104に際し、ユーザ端末TM(例えばIEEE802.1Xのサプリカントソフト)または認証スイッチSWは、ネットワーク認証で用いる認証プロトコルを予め設定によって定めることができる。認証プロトコルの選択肢として、例えば、PAP(Password Authentication Protocol)や、CHAP(Challenge Handshake Authentication Protocol)の一種であるMS-CHAPv2(MicroSoft(登録商標) CHAP version2)等が挙げられる。
【0021】
PAPは、入力パスワードPWiを平文で送信する方式を用いている。一方、MS-CHAPv2は、チャレンジ/レスポンス方式を用いている。この場合、入力パスワードPWiは、規定のハッシュ関数、および予め受信した乱数(チャレンジ情報)等によって暗号化された上で、レスポンス情報としてユーザ端末TMから送信される。
【0022】
また、ステップS105に際し、認証サーバ12は、ステップS104での入力パスワードPWiに適用されている認証プロトコルがPAPの場合、当該入力パスワードPWiを含むアカウントの認証成否をケルベロス認証方式、またはLDAP_bindコマンドを用いたLDAP認証方式等を用いてディレクトリサーバ13に問い合わせる。このような認証プロトコルと認証方式との対応関係は、パスワードが平文であることが要因となっている。
【0023】
一方、認証サーバ12は、ステップS104での入力パスワードPWiに適用されている認証プロトコルがMS-CHAPv2の場合、当該入力パスワードPWiを含むアカウントの認証成否をNTLM(NT LAN Manager authentication)認証方式等を用いてディレクトリサーバ13に問い合わせる。このような認証プロトコルと認証方式との対応関係は、パスワードが暗号化されていることが要因となっている。NTLM認証方式では、MS-CHAPv2と同様のチャレンジ/レスポンス方式が用いられる。
【0024】
《前提となる問題点》
ここで、例えば、ADサーバ等のディレクトリサーバ13において、ケルベロス認証方式は、“samAccountName”といった第1の登録ID(IDr[1])にも、“UserPrincipalName”といった第2の登録ID(IDr[2])にも対応する方式となっている。一方、NTLM認証方式は、第1の登録ID(IDr[1])に対応し、第2の登録ID(IDr[2])に対応しない方式となっている。
【0025】
このため、ネットワーク認証で用いる認証プロトコルとしてPAPが設定されている場合(ひいては、認証サーバ12がケルベロス認証方式でADサーバに問い合わせる場合)には、特に問題は生じない。すなわち、ユーザ11がログインページに入力する入力ID(IDi)として、第1の登録ID(IDr[1])と第2の登録ID(IDr[2])のいずれを入力した場合でも、ADサーバは、ネットワーク認証の認証成否を正しく判定することができる。
【0026】
しかし、ネットワーク認証で用いる認証プロトコルとしてMS-CHAPv2が設定されている場合(ひいては、認証サーバ12がNTLM認証方式でADサーバに問い合わせる場合)には、問題が生じる。すなわち、ユーザ11がログインページに入力する入力ID(IDi)として第2の登録ID(IDr[2])を入力した場合、ADサーバは、ネットワーク認証の認証可否を正しく判定することができない。
【0027】
その結果、ユーザ11の利便性が低下する恐れがある。具体的には、ネットワーク認証において、MS-CHAPv2は、ケルベロス認証方式等と比較して古い方式であるが、実用上、例えば、ユーザ端末TMが旧式である場合を代表に、様々な場合で多く用いられている。一方、ユーザ11は、このような認証プロトコルの違いに伴うIDの使い分けを行うことなく、第1の登録ID(IDr[1])と第2の登録ID(IDr[2])のいずれを用いてもネットワーク認証が正しく行われることを望む。
【0028】
また、近年では、ユーザ11は、例えば、ディレクトリサーバ13に対するドメイン認証等の際に、“UserPrincipalName”といった第2の登録ID(IDr[2])を使用する機会が多い。このような状況のもと、ユーザ11は、MS-CHAPv2が適用されている場合には、例えば、ネットワーク認証時のみでログインページに第1の登録ID(IDr[1])を入力しなければならない。
【0029】
《認証システムの概略動作(実施の形態1)》
図2は、図1の認証システムの概略的な動作例を示すシーケンス図である。図2において、ステップS103,S104およびステップS106,S107に関しては、図1の場合と同様である。図2において、認証スイッチSWは、ユーザ端末TMからの未知の通信接続を検知すると(ステップS101)、ユーザ端末TMに、ログインページのURLを応答することでユーザ端末TMにログインページを表示させる(ステップS102)。
【0030】
これに応じて、ユーザ11は、ユーザ端末TMに表示されたログインページに自身のアカウント(すなわち、入力ID(IDi)および入力パスワードPWi)を入力し、ユーザ端末TMは、当該入力されたアカウントを認証スイッチSWに送信する(ステップS103)。認証スイッチSWは、入力されたアカウントの認証要求を認証サーバ12に送信する(ステップS104)。ここで、認証サーバ12は、認証スイッチSWからの認証要求を受けて、ディレクトリサーバ13に認証成否を問い合わせる(ステップS105)。
【0031】
このステップS105の際に、認証サーバ12は、まず、入力ID(IDi)の属性を第2の登録ID(IDr[2])に定めた状態で、当該入力ID(IDi)を検索キーとして、ディレクトリサーバ13(すなわちアカウントDB14)に第2の登録ID(IDr[2])に対応する第1の登録ID(IDr[1])の検索要求を送信する(ステップS201)。この要求に対する応答によって、認証サーバ12は、ディレクトリサーバ13から第1の登録ID(IDr[1])を取得する(ステップS202)。
【0032】
この検索要求には、例えば、LDAP検索(具体的にはldapsearchコマンド等)が用いられる。そして、認証サーバ12は、取得した第1の登録ID(IDr[1])と、入力パスワードPWiに対する認証成否を、所定の認証方式(例えば、ケルベロス認証方式またはNTLM認証方式)を用いてディレクトリサーバ13に問い合わせる(ステップS203)。
【0033】
なお、ステップS201において、認証サーバ12は、入力ID(IDi)の属性(LDAP属性)を第2の登録ID(IDr[2])に定めた状態でディレクトリサーバ13に検索要求を送信した。ただし、例えば、入力ID(IDi)が第1の登録ID(IDr[1])である場合等で、ディレクトリサーバ13から第1の登録ID(IDr[1])を取得できないことがある。このような場合(例えば、ディレクトリサーバ13からエラーが応答された場合)、認証サーバ12は、入力ID(IDi)を第1の登録ID(IDr[1])とみなしてステップS203の処理を行えばよい。
【0034】
続いて、ディレクトリサーバ13は、ステップS105(ステップS203)での認証成否の問い合わせに応じて、アカウントDB14の登録内容に基づいて認証成否を判定し、その判定結果を問い合わせ結果として認証サーバ12に応答する(ステップS106)。認証サーバ12は、ステップS104での認証要求に対する認証結果として、ディレクトリサーバ13からの問い合わせ結果を認証スイッチSWに応答する(ステップS107)。
【0035】
ステップS108において、認証スイッチSWは、認証サーバ12からの認証結果が認証成功を表す場合には、例えば、ユーザ端末TMが接続されているポートを開放すること等でネットワークNWへの接続を許可する。一方、認証スイッチSWは、認証サーバ12からの認証結果が認証失敗を表す場合には、例えば、ユーザ端末TMが接続されているポートを閉塞すること等でネットワークNWへの接続を禁止する。
【0036】
このように、認証サーバ12は、ステップS201,S202においてディレクトリサーバ13から第1の登録ID(IDr[1])を取得することで、仮に、入力ID(IDi)が第2の登録ID(IDr[2])であったとしても、対応する第1の登録ID(IDr[1])を用いて認証成否を問い合わせることができる(ステップS203)。その結果、この認証成否の問い合わせがケルベロス認証方式に限らずNTLM認証方式で行われる場合であっても、ディレクトリサーバ13は、正しく認証成否を判定することが可能になる。
【0037】
《認証サーバの構成》
図3は、図1(a)における認証サーバの主要部の構成例を示すブロック図である。図3に示す認証サーバ12aは、認証プロトコル判別部20と、対象ID決定部21と、問い合わせ部22とを有する。これらの各部は、例えば、認証サーバ12a内のCPU(Central Processing Unit)を用いたプログラム処理によって実装される。ただし、場合によっては、これらの一部または全ては、FPGA(Field Programmable Gate Array)やASIC(Application Specific Integrated Circuit)等のハードウェアで実装されてもよい。すなわち、これらの各部は、ハードウェアまたはソフトウェアあるいはその組合せを用いて適宜実装されればよい。
【0038】
認証プロトコル判別部20は、入力パスワードPWiに適用されている認証プロトコルが第1の認証プロトコル(例えばPAP)か第2の認証プロトコル(例えばMS-CHAPv2)かを判別する。具体的には、認証プロトコル判別部20は、例えば、受信したフレームに含まれるPPP(Point to Point Protocol)ヘッダの情報等に基づいて認証プロトコルを判別する。
【0039】
対象ID決定部21は、問い合わせ部22の問い合わせ対象となる対象ID(IDq)を決定する。具体的には、対象ID決定部21は、ID検索部25を備える。ID検索部25は、前述したように、入力ID(IDi)の属性を第2の登録ID(IDr[2])に定めた状態でディレクトリサーバ13(アカウントDB14)に第1の登録ID(IDr[1])の検索要求を送信することで、第1の登録ID(IDr[1])を取得する。すなわち、ID検索部25は、例えば、認証プロトコル判別部20の判別結果に関わらず、常に、ディレクトリサーバ13に検索要求を送信する。そして、対象ID決定部21は、ID検索部25で取得した第1の登録ID(IDr[1])を対象ID(IDq)に定める。
【0040】
一方、対象ID決定部21は、認証プロトコル判別部20の判別結果に基づいて対象ID(IDq)を定めてもよい。具体的には、ID検索部25は、認証プロトコル判別部20の判別結果が第1の認証プロトコル(PAP)である場合には、ディレクトリサーバ13に検索要求を送信しない構成であってもよい。この場合、対象ID決定部21は、入力ID(IDi)を対象ID(IDq)に定める。すなわち、PAPに対応するケルベロス認証方式等では、対象ID(IDq)として、第1の登録ID(IDr[1])と第2の登録ID(IDr[2])のいずれを用いることも可能である。
【0041】
問い合わせ部22は、対象ID決定部21で定められた対象ID(IDq)と、入力パスワードPWiに対する認証成否をディレクトリサーバ13に問い合わせる。この際に、問い合わせ部22は、認証プロトコル判別部20の判別結果が第1の認証プロトコル(PAP)である場合にはディレクトリサーバ13との間で第1の認証方式(ケルベロス認証方式等)を用いて認証成否を問い合わせる。一方、問い合わせ部22は、認証プロトコル判別部20の判別結果が第2の認証プロトコル(MS-CHAPv2)である場合にはディレクトリサーバ13との間で第2の認証方式(NTLM認証方式等)を用いて認証成否を問い合わせる。
【0042】
この際に、対象ID(IDq)は、前述した対象ID決定部21の処理に伴い、第2の認証方式(NTLM認証方式等)を用いて認証成否の問い合わせが行われる場合には、第1の登録ID(IDr[1])に定められる。一方、対象ID(IDq)は、第1の認証方式(ケルベロス認証方式等)を用いて認証成否の問い合わせが行われる場合には、ID検索部25を介して第1の登録ID(IDr[1])に定められるか、または、ID検索部25を介さずに入力ID(IDi)に定められる。
【0043】
《認証サーバの動作[1]》
図4は、図3の認証サーバにおける処理内容の一例を示すフロー図である。図4において、認証サーバ12aは、ユーザ11によって入力されたアカウント(入力ID(IDi)および入力パスワードPWi)に対する認証スイッチSWからの認証要求を受信する(ステップS104)。これを受けて、認証プロトコル判別部20は、入力パスワードPWiに適用されている認証プロトコルがPAP(第1の認証プロトコル)かMS-CHAPv2(第2の認証プロトコル)かを判別する(ステップS301,S306)。
【0044】
認証プロトコル判別部20の判別結果がPAPである場合(ステップS301:Yes)、ID検索部25は、入力ID(IDi)の属性を第2の登録ID(IDr[2])に定めた状態で、ディレクトリサーバ13に、対応する第1の登録ID(IDr[1])の検索要求を送信することで第1の登録ID(IDr[1])を取得する(ステップS302)。そして、第1の登録ID(IDr[1])を取得できた場合(ステップS303:Yes)、問い合わせ部22は、取得された第1の登録ID(IDr[1])と、入力パスワードPWiに対する認証成否を、ケルベロス認証方式を用いてディレクトリサーバ13に問い合わせる(ステップS304)。
【0045】
一方、ステップS302で第1の登録ID(IDr[1])を取得できなかった場合(ステップS303:No)、問い合わせ部22は、入力ID(IDi)と入力パスワードPWiに対する認証成否を、ケルベロス認証方式を用いてディレクトリサーバ13に問い合わせる(ステップS305)。第1の登録ID(IDr[1])を取得できなかった場合とは、例えば、入力ID(IDi)が第1の登録ID(IDr[1])である場合や、入力ID(IDi)が第1の登録ID(IDr[1])および第2の登録ID(IDr[2])のいずれにも該当しない場合等である。
【0046】
また、認証プロトコル判別部20の判別結果がMS-CHAPv2である場合(ステップS306:Yes)、ID検索部25は、ステップS302の場合と同様、ディレクトリサーバ13に、入力ID(IDi)に対応する第1の登録ID(IDr[1])の検索要求を送信することで第1の登録ID(IDr[1])を取得する(ステップS307)。すなわち、ID検索部25は、認証プロトコル判別部20の判別結果がPAPであるか(ステップS301:Yes)、MS-CHAPv2であるか(ステップS306:Yes)に関わらず、常に、ディレクトリサーバ13に検索要求を送信する。
【0047】
ステップS307で第1の登録ID(IDr[1])を取得できた場合(ステップS308:Yes)、問い合わせ部22は、取得された第1の登録ID(IDr[1])と、入力パスワードPWiに対する認証成否を、NTLM認証方式を用いてディレクトリサーバ13に問い合わせる(ステップS309)。一方、ステップS307で第1の登録ID(IDr[1])を取得できなかった場合(ステップS308:No)、問い合わせ部22は、入力ID(IDi)と入力パスワードPWiに対する認証成否を、NTLM認証方式を用いてディレクトリサーバ13に問い合わせる(ステップS310)。
【0048】
なお、認証プロトコル判別部20の判別結果がPAPでもMS-CHAPv2でもない場合(ステップS306:No)、認証サーバ12aは、例えば、所定のエラー処理等を実行する(ステップS311)。
【0049】
このような処理を用いると、原則として、第1の登録ID(IDr[1])を対象に、ディレクトリサーバ13に対する認証成否の問い合わせが行われる。その結果、ユーザが入力ID(IDi)として第1の登録ID(IDr[1])または第2の登録ID(IDr[2])のいずれを入力した場合でも、ネットワーク認証の認証可否を正しく判定することができ、ユーザの利便性を向上させることが可能になる。
【0050】
《認証サーバの動作[2]》
図5は、図3の認証サーバにおける処理内容の他の一例を示すフロー図である。図5に示すフローは、図4に示したフローと比較して、ステップS302~S304が削除されたものとなっている。すなわち、認証プロトコル判別部20の判別結果がPAPである場合(ステップS301:Yes)、ID検索部25は、図4の場合と異なりディレクトリサーバ13に検索要求を送信しない。この場合、問い合わせ部22は、入力ID(IDi)と入力パスワードPWiに対する認証成否を、ケルベロス認証方式を用いてディレクトリサーバ13に問い合わせる(ステップS305)。
【0051】
このような処理を用いると、認証プロトコル判別部20の判別結果がPAPである場合に、ディレクトリサーバ13に対する検索を行わずに済む。その結果、例えば、認証サーバ12aとディレクトリサーバ13との間の通信負荷を軽減すること等が可能になる。
【0052】
《実施の形態1の主要な効果》
以上、実施の形態1の認証サーバおよび認証システムを用いることで、代表的には、ユーザの利便性を向上させることが可能になる。具体的には、ユーザは、認証プロトコルの違い意識する必要がなく、入力ID(IDi)として第1の登録ID(IDr[1])と第2の登録ID(IDr[2])のいずれを用いた場合であってもネットワーク認証を正しく行わせることが可能になる。特に、ユーザは、“UserPrincipalName”といった使用頻度が高い第2の登録ID(IDr[2])を常時用いてネットワーク認証を正しく行わせることが可能になる。言い換えれば、ユーザは、ネットワーク認証時のみで第1の登録ID(IDr[1])を入力するといったような使い分けをする必要がない。
【0053】
(実施の形態2)
《認証サーバの構成》
図6は、本発明の実施の形態2による認証システムにおいて、図1(a)における認証サーバの主要部の構成例を示すブロック図である。図6に示す認証サーバ12bは、図3に示した認証サーバ12aと比較して、対象ID決定部31の構成が異なっている。対象ID決定部31は、図3に示したようなID検索部25に加えて、IDフォーマット判別部32を備える。
【0054】
IDフォーマット判別部32は、入力ID(IDi)のフォーマットが第1の登録ID(IDr[1])のフォーマットか第2の登録IDのフォーマット(IDr[2])かを判別する。具体的には、“UserPrincipalName”といった第2の登録IDは、“samAccountName”といった第1の登録ID(IDr[1])と異なり、“@ドメイン名”を含んだフォーマットになっている。このため、IDフォーマット判別部32は、例えば、入力ID(IDi)に“@ドメイン名”が含まれる場合には、入力ID(IDi)を第2の登録ID(IDr[2])とみなし、“@ドメイン名”が含まれない場合には、入力ID(IDi)を第1の登録ID(IDr[1])とみなせばよい。
【0055】
ここで、IDフォーマット判別部32の判別結果が第1の登録ID(IDr[1])のフォーマットである場合には、ID検索部25は、ディレクトリサーバ13に検索要求を送信しない。この場合、対象ID決定部31は、対象ID(IDq)を入力ID(IDi)に定める。一方、IDフォーマット判別部32の判別結果が第2の登録ID(IDr[2])のフォーマットである場合には、ID検索部25は、ディレクトリサーバ13に常に検索要求を送信するか、または、認証プロトコル判別部20の判別結果に基づいて検索要求の送信有無を使い分ける。
【0056】
《認証サーバの動作[1]》
図7は、図6の認証サーバにおける処理内容の一例を示すフロー図である。図7に示すフローは、図4に示したフローに対して、IDフォーマット判別部32の処理を追加したものとなっている。図7において、ステップS104,S301,S306,S311に関しては、図4の場合と同様である。
【0057】
図7において、認証プロトコル判別部20の判別結果がPAPである場合(ステップS301:Yes)、IDフォーマット判別部32は、入力ID(IDi)のフォーマットが第1の登録ID(IDr[1])のフォーマットか第2の登録ID(IDr[2])のフォーマット(IDr[2])かを判別する(ステップS401)。言い換えれば、IDフォーマット判別部32は、入力ID(IDi)を第1の登録ID(IDr[1])とみなすか第2の登録ID(IDr[2])とみなす。
【0058】
入力ID(IDi)が第1の登録ID(IDr[1])とみなされた場合(ステップS401:No)、ステップS304への移行が行われる。一方、入力ID(IDi)が第2の登録ID(IDr[2])とみなされた場合(ステップS401:Yes)、ID検索部25が、図4のステップS302等の場合と同様にしてディレクトリサーバ13から第1の登録ID(IDr[1])を取得したのち(ステップS402)、ステップS304への移行が行われる。
【0059】
ステップS304において、問い合わせ部22は、第1の登録ID(IDr[1])と入力パスワードPWiに対する認証成否を、ケルベロス認証方式を用いてディレクトリサーバ13に問い合わせる。この際に、問い合わせ対象の第1の登録ID(IDr[1])は、ステップS401で第1の登録ID(IDr[1])とみなされた入力ID(IDi)、または、ステップS402でディレクトリサーバ13から取得された第1の登録ID(IDr[1])に該当する。
【0060】
また、認証プロトコル判別部20の判別結果がMS-CHAPv2である場合(ステップS306:Yes)、IDフォーマット判別部32は、ステップS401の場合と同様に、入力ID(IDi)を第1の登録ID(IDr[1])とみなすか第2の登録ID(IDr[2])とみなす。すなわち、IDフォーマット判別部32は、認証プロトコル判別部20の判別結果がPAPであるか(ステップS301:Yes)、MS-CHAPv2であるか(ステップS306:Yes)に関わらず、フォーマットの判別処理を行う。
【0061】
入力ID(IDi)が第1の登録ID(IDr[1])とみなされた場合(ステップS403:No)、ステップS309への移行が行われる。一方、入力ID(IDi)が第2の登録ID(IDr[2])とみなされた場合(ステップS403:Yes)、ID検索部25が、図4のステップS302等の場合と同様にしてディレクトリサーバ13から第1の登録ID(IDr[1])を取得したのち(ステップS404)、ステップS309への移行が行われる。
【0062】
ステップS309において、問い合わせ部22は、第1の登録ID(IDr[1])と入力パスワードPWiに対する認証成否を、NTLM認証方式を用いてディレクトリサーバ13に問い合わせる。この際に、問い合わせ対象の第1の登録ID(IDr[1])は、ステップS403で第1の登録ID(IDr[1])とみなされた入力ID(IDi)、または、ステップS404でディレクトリサーバ13から取得された第1の登録ID(IDr[1])に該当する。
【0063】
このような処理を用いると、図4の場合と同様に、原則として、第1の登録ID(IDr[1])を対象にディレクトリサーバ13に対して認証成否を問い合わせることができる。さらに、図4の場合と比較して、ディレクトリサーバ13に対する検索回数を減らすことができる。具体的には、ステップS402,S404において、ID検索部25は、図4の場合と異なり、IDフォーマット判別部32によって入力ID(IDi)が第2の登録ID(IDr[2])とみなされた場合に、ディレクトリサーバ13に検索要求を送信すればよい。その結果、図4の場合と比較して、例えば、認証サーバ12bとディレクトリサーバ13との間の通信負荷を軽減することが可能になる。
【0064】
《認証サーバの動作[2]》
図8は、図6の認証サーバにおける処理内容の他の一例を示すフロー図である。図8に示すフローは、図5に示したフローに対して、IDフォーマット判別部32の処理を追加したものとなっている。また、図8に示すフローは、図7に示したフローにおけるステップS401,S402,S304をステップS305に置き換えたものとなっている。
【0065】
すなわち、認証プロトコル判別部20の判別結果がPAPである場合(ステップS301:Yes)、図7の場合と異なり、IDフォーマット判別部32はフォーマットの判別処理を行わず、ID検索部25もディレクトリサーバ13に検索要求を送信しない。この場合、問い合わせ部22は、入力ID(IDi)と入力パスワードPWiに対する認証成否を、ケルベロス認証方式を用いてディレクトリサーバ13に問い合わせる(ステップS305)。
【0066】
このような処理を用いると、図7の場合と比較して、認証プロトコル判別部20の判別結果がPAPである場合に、IDフォーマット判別部32およびID検索部25の処理を行わずに済む。その結果、認証サーバ12bの処理負荷や、認証サーバ12bとディレクトリサーバ13との間の通信負荷を軽減することが可能になる。また、図5の場合と比較して、認証サーバ12bとディレクトリサーバ13との間の通信負荷を更に軽減することが可能になる。すなわち、図8のステップS404において、ID検索部25は、図5の場合と異なり、IDフォーマット判別部32によって入力ID(IDi)が第2の登録ID(IDr[2])とみなされた場合に、ディレクトリサーバ13に検索要求を送信すればよい。
【0067】
《実施の形態2の主要な効果》
以上、実施の形態2の認証サーバおよび認証システムを用いることで、実施の形態1で述べた各種効果に加えて、さらに、認証サーバ12bとディレクトリサーバ13との間の通信負荷を軽減すること等が可能になる。
【0068】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。例えば、前述した実施の形態は、本発明を分かり易く説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施の形態の構成の一部を他の実施の形態の構成に置き換えることが可能であり、また、ある実施の形態の構成に他の実施の形態の構成を加えることも可能である。また、各実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【符号の説明】
【0069】
11 ユーザ
12,12a,12b 認証サーバ
13 ディレクトリサーバ
14 アカウントDB
20 認証プロトコル判別部
21,31 対象ID決定部
22 問い合わせ部
25 ID検索部
32 IDフォーマット判別部
IDi 入力ID
IDq 対象ID
IDr[1] 第1の登録ID
IDr[2] 第2の登録ID
NW ネットワーク
PWi 入力パスワード
PWr 登録パスワード
SW 認証スイッチ
TM ユーザ端末
図1
図2
図3
図4
図5
図6
図7
図8