特許 7221235 サーバ装置およびネットワークシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-02-03

(45)【発行日】2023-02-13

(54)【発明の名称】サーバ装置およびネットワークシステム

(51)【国際特許分類】

   G06F 21/41 20130101AFI20230206BHJP

   H04L 61/00 20220101ALI20230206BHJP

   H04L 61/5014 20220101ALI20230206BHJP

【ＦＩ】

G06F21/41

H04L61/00

H04L61/5014

【請求項の数】 9

(21)【出願番号】P 2020069563

(22)【出願日】2020-04-08

(65)【公開番号】P2021165977

(43)【公開日】2021-10-14

【審査請求日】2022-04-04

(73)【特許権者】

【識別番号】300059979

【氏名又は名称】エイチ・シー・ネットワークス株式会社

(74)【代理人】

【識別番号】110002066

【氏名又は名称】弁理士法人筒井国際特許事務所

(72)【発明者】

【氏名】小野 勝人

(72)【発明者】

【氏名】秋山 純哉

(72)【発明者】

【氏名】柴田 功克

(72)【発明者】

【氏名】西野宮 浩志

【審査官】岸野 徹

(56)【参考文献】

【文献】特開２００８－２４４８４０（ＪＰ，Ａ）

【文献】特開２００９－００３５５９（ＪＰ，Ａ）

【文献】特開２００８－１５２５９６（ＪＰ，Ａ）

【文献】特開２０１３－０７３４２１（ＪＰ，Ａ）

【文献】特開２０１７－２０４６９７（ＪＰ，Ａ）

【文献】国際公開第２０２０／０６１１５３（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／４１

Ｈ０４Ｌ ６１／００

(57)【特許請求の範囲】

【請求項1】

ユーザにユーザ端末を介して１回のログイン操作を行わせることで、内部ネットワークを介して前記ユーザ端末に接続される複数のサービスプロバイダへのログインを可能にするサーバ装置であって、
前記ユーザのユーザ識別子と、前記ユーザに対するログイン認証許可またはログイン認証拒否を定めるログイン認証可否情報と、前記ユーザがログイン中の前記サービスプロバイダとの対応関係を保持するログインデータベースと、
前記ログインデータベースに基づいて、前記ユーザの前記ログイン操作またはログアウト操作に応じた制御を行う制御部と、
を有し、
前記ユーザ識別子を、前記内部ネットワークの認証可否を判定する認証サーバでネットワーク認証拒否に定める場合に、前記ユーザ識別子を、前記ログインデータベースで前記ログイン認証拒否に定めるための認証拒否情報が作成され、
前記制御部は、前記認証拒否情報を受信した際に、前記ユーザ識別子に対応する前記ログイン認証可否情報が前記ログイン認証拒否となるように前記ログインデータベースを更新し、前記ログインデータベースに基づいて、前記ユーザがログイン中の前記サービスプロバイダへログアウト要求を送信する、
サーバ装置。

【請求項2】

請求項１記載のサーバ装置において、
前記制御部は、前記認証拒否情報を前記認証サーバから受信する、
サーバ装置。

【請求項3】

請求項１記載のサーバ装置において、
前記制御部は、前記ユーザの前記ログアウト操作に伴うログアウト命令を前記ユーザ端末から受信した際に、前記ログインデータベースに基づいて、前記ユーザがログイン中の前記サービスプロバイダへログアウト要求を送信する、
サーバ装置。

【請求項4】

内部ネットワークと、
複数のサービスプロバイダが接続される外部ネットワークと、
前記内部ネットワークと、ユーザによって使用されるユーザ端末との間に接続され、前記ユーザ端末から前記内部ネットワークの認証を求めるネットワーク認証要求を受信する認証クライアントと、
前記内部ネットワークに接続され、前記ネットワーク認証要求に伴う前記認証クライアントからの認証判定要求に応じて、認証データベースに基づいてネットワーク認証許可／ネットワーク認証拒否を判定し、前記ネットワーク認証許可／ネットワーク認証拒否の判定結果を前記認証クライアントへ応答する認証サーバと、
前記内部ネットワークに接続され、前記ユーザに前記ユーザ端末を介して１回のログイン操作を行わせることで、前記複数のサービスプロバイダへのログインを可能にするサーバ装置と、
を有するネットワークシステムであって、
前記サーバ装置は、
前記ユーザのユーザ識別子と、前記ユーザに対するログイン認証許可またはログイン認証拒否を定めるログイン認証可否情報と、前記ユーザがログイン中の前記サービスプロバイダとの対応関係を保持するログインデータベースと、
前記ログインデータベースに基づいて、前記ユーザの前記ログイン操作またはログアウト操作に応じた制御を行う制御部と、
を有し、
前記ユーザ識別子を前記認証データベースで前記ネットワーク認証拒否に定める場合に、前記ユーザ識別子を前記ログインデータベースで前記ログイン認証拒否に定めるための認証拒否情報が作成され、
前記制御部は、前記認証拒否情報を受信した際に、前記ユーザ識別子に対応する前記ログイン認証可否情報が前記ログイン認証拒否となるように前記ログインデータベースを更新し、前記ログインデータベースに基づいて、前記ユーザがログイン中の前記サービスプロバイダへログアウト要求を送信する、
ネットワークシステム。

【請求項5】

請求項４記載のネットワークシステムにおいて、
前記制御部は、前記認証拒否情報を前記認証サーバから受信する、
ネットワークシステム。

【請求項6】

請求項４記載のネットワークシステムにおいて、
前記制御部は、前記ユーザの前記ログアウト操作に伴うログアウト命令を前記ユーザ端末から受信した際に、前記ログインデータベースに基づいて、前記ユーザがログイン中の前記サービスプロバイダへログアウト要求を送信する、
ネットワークシステム。

【請求項7】

請求項４記載のネットワークシステムにおいて、
前記内部ネットワークに接続され、前記ユーザ端末にＩＰアドレスを割り当て、前記ＩＰアドレスを割り当てた場合に、前記ユーザ端末のＩＰアドレスおよびＭＡＣアドレスを含むＤＨＣＰ（Dynamic Host Configuration Protocol）ログを作成するＤＨＣＰサーバと、
前記内部ネットワークに接続され、前記ネットワーク認証許可の際に前記認証サーバまたは前記認証クライアントの一方によって作成される認証許可ログと、前記ＤＨＣＰサーバからの前記ＤＨＣＰログとを受けて、前記ユーザ識別子と前記ユーザ端末のＩＰアドレスとの対応関係を端末管理データベースに登録するログ管理サーバと、
前記内部ネットワークから前記外部ネットワークへ向けた通信を監視し、不正通信を検知した際に前記不正通信に伴う送信元のＩＰアドレスを含む不正通信検知ログを前記ログ管理サーバへ送信する不正通信検知装置と、
を有し、
前記認証許可ログは、前記ネットワーク認証許可の対象となる前記ユーザ識別子と、前記ユーザ端末のＭＡＣアドレスとを含み
前記ログ管理サーバは、前記不正通信検知ログと前記端末管理データベースとに基づいて、前記認証拒否情報を作成する、
ネットワークシステム。

【請求項8】

請求項７記載のネットワークシステムにおいて、
前記ログ管理サーバは、前記認証拒否情報を前記認証サーバと前記サーバ装置とへ送信する、
ネットワークシステム。

【請求項9】

請求項７記載のネットワークシステムにおいて、
前記ログ管理サーバは、前記認証拒否情報を前記認証サーバへ送信し、
前記サーバ装置は、前記認証拒否情報を前記認証サーバから受信する、
ネットワークシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、サーバ装置およびネットワークシステムに関し、例えば、ＳＳＯ（Single Sign On）に伴う認証技術に関する。

【背景技術】

【0002】

特許文献１には、ログ管理サーバや不正通信検知装置等を用いて、不正通信を遮断するネットワークシステムが示される。具体的には、ログ管理サーバは、認証サーバ等からのアカウントＩＤを含む認証許可ログと、ＤＨＣＰサーバからのＤＨＣＰログとを受けて、アカウントＩＤとＩＰアドレスとの対応関係をＤＢに登録する。そして、ログ管理サーバは、不正通信検知装置からＩＰアドレスを含む不正通信検知ログを受けた際に、対応するアカウントＩＤを認証拒否にする命令を、認証サーバへ送信する。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１７－２０４６９７号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

例えば、特許文献１のような方式を用いると、不正通信を行ったこと等により悪意があるとみなされたユーザ（明細書では、不正なユーザと呼ぶ）のユーザＩＤを、認証サーバの管理範囲であるネットワーク認証レベルで認証拒否に定めることが可能である。認証サーバは、例えば、ＲＡＤＩＵＳ(Remote Authentication Dial In User Service）サーバ等である。ただし、このような方式のみでは、不正なユーザが、アプリケーションレベルで所定のサービスプロバイダにログインし、サービスを利用できるような事態が生じ得る。

【0005】

具体的には、例えば、不正なユーザが、ネットワーク認証レベルで認証許可されているユーザ端末や共用端末等を不正に使って、自身のユーザＩＤでサービスプロバイダにログインするような場合が挙げられる。しかし、本来、当該不正なユーザに対するネットワークの認証は拒否されているため、当該ネットワークを使ったサービスの利用も拒否されることが望ましい。

【0006】

本発明は、このようなことに鑑みてなされたものであり、その目的の一つは、ネットワークのセキュリティを高めることが可能なサーバ装置およびネットワークシステムを提供することにある。

【0007】

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

【課題を解決するための手段】

【0008】

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

【0009】

一実施の形態によるサーバ装置は、ユーザにユーザ端末を介して１回のログイン操作を行わせることで、内部ネットワークを介してユーザ端末に接続される複数のサービスプロバイダへのログインを可能にするものであり、ログインデータベースと、制御部と、を有する。ログインデータベースは、ユーザのユーザ識別子と、ユーザに対するログイン認証許可またはログイン認証拒否を定めるログイン認証可否情報と、ユーザがログイン中のサービスプロバイダとの対応関係を保持する。制御部は、ログインデータベースに基づいて、ユーザのログイン操作またはログアウト操作に応じた制御を行う。ここで、ユーザ識別子を、内部ネットワークの認証可否を判定する認証サーバでネットワーク認証拒否に定める場合に、ユーザ識別子を、ログインデータベースでログイン認証拒否に定めるための認証拒否情報が作成される。制御部は、当該認証拒否情報を受信した際に、ユーザ識別子に対応するログイン認証可否情報がログイン認証拒否となるようにログインデータベースを更新し、ログインデータベースに基づいて、ユーザがログイン中のサービスプロバイダへログアウト要求を送信する。

【発明の効果】

【0010】

本願において開示される発明のうち、代表的な実施の形態によって得られる効果を簡単に説明すると、ネットワークのセキュリティを高めることが可能になる。

【図面の簡単な説明】

【0011】

【図1】本発明の実施の形態１によるネットワークシステムにおける主要部の構成例を示す概略図である。

【図2】図１におけるログインサーバが有するログインＤＢの構成例を示す概略図である。

【図3】図１において、ログインサーバを用いてＳＳＯを行う際の処理内容の一例を示すシーケンス図である。

【図4】図３とは異なる処理内容の一例を示すシーケンス図である。

【図5】図１において、ログインサーバの主要部の構成例を示すブロック図である。

【図6】図１および図５のログインサーバを用いて行われる主要な処理内容の一例を示すシーケンス図である。

【図7】本発明の実施の形態２によるネットワークシステムにおける主要部の構成例および動作例を示す概略図である。

【図8】図７に続く構成例および動作例を示す概略図である。

【発明を実施するための形態】

【0012】

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

【0013】

（実施の形態１）
《ネットワークシステムの構成》
図１は、本発明の実施の形態１によるネットワークシステムにおける主要部の構成例を示す概略図である。図１に示すネットワークシステムは、イントラネット等の内部ネットワーク１０と、インターネット等の外部ネットワーク１１と、ルータ１３と、認証サーバ１７と、ログインサーバ（サーバ装置）１８と、認証スイッチＳＷとを備える。外部ネットワーク１１には、所定のサービス（言い換えればアプリケーション）を提供する複数のサービスプロバイダ（言い換えればアプリケーションサーバ）ＳＰａ，ＳＰｂが接続される。

【0014】

内部ネットワーク１０は、例えば、ＯＳＩ参照モデルのレイヤ３（Ｌ３）やレイヤ２（Ｌ２）のネットワークである。ルータ１３は、内部ネットワーク１０と外部ネットワーク１１との間に接続される。認証スイッチＳＷは、内部ネットワーク１０と、ユーザによって使用されるユーザ端末ＴＭ１０との間に接続される。認証サーバ１７およびログインサーバ１８は、内部ネットワーク１０に接続される。

【0015】

認証スイッチＳＷは、認証サーバ１７に対する認証クライアント（例えば、ＲＡＤＩＵＳクライアント）である。認証スイッチＳＷは、例えば、レイヤ２（Ｌ２）の中継処理を行うＬ２スイッチであり、ポートＰ１，…を備える。この例では、ポートＰ１には、正規のユーザ１４ａによって使用されるユーザ端末ＴＭ１０が接続される。ユーザ端末ＴＭ１０には、ＩＰアドレス“ＩＰＡ１０”およびＭＡＣアドレス“ＭＡ１０”が設定される。

【0016】

認証サーバ１７は、例えば、認証クライアントからの認証判定要求に応じて内部ネットワーク１０の認証可否を判定するＲＡＤＩＵＳサーバ等である。明細書では、認証サーバ１７によって行われる認証をネットワーク認証と呼ぶ。認証サーバ１７は、記憶部２３に保持される認証データベース（明細書では、データベースをＤＢと略す）２４を有する。認証ＤＢ２４は、例えば、ユーザのユーザ識別子（明細書では、識別子をＩＤと略す）およびパスワード（ＰＷ）と、ユーザＩＤ毎のネットワーク認証許可／ネットワーク認証拒否を表すネットワーク認証可否情報２７との対応関係を保持する。

【0017】

なお、認証ＤＢ２４は、外部のディレクトリサーバが有してもよい。この場合、認証サーバ１７は、ディレクトリサーバとの間でＬＤＡＰ（Lightweight Directory Access Protocol）等に基づく通信を行うことで、認証ＤＢ２４にアクセスすればよい。

【0018】

ログインサーバ（サーバ装置）１８は、ＳＳＯサーバであり、ユーザにユーザ端末ＴＭ１０を介して１回のログイン操作を行わせることで、外部ネットワーク１１に接続される複数のサービスプロバイダＳＰａ，ＳＰｂへのログインを可能にするものである。言い換えれば、ログインサーバ１８は、１回のログイン操作に基づいて、各サービスプロバイダへのログインに伴う認証可否を判定する。明細書では、ログインサーバ１８によって行われる認証をログイン認証と呼ぶ。ログインサーバ１８は、例えば、ＳＡＭＬ（Security Assertion Markup Language）規格ではＩｄｐ（Identity provider）と呼ばれる。

【0019】

ログインサーバ１８は、記憶部２５に保持されるログインＤＢ２６を有する。図２は、図１におけるログインサーバが有するログインＤＢの構成例を示す概略図である。図２に示すログインＤＢ２６は、ユーザのユーザＩＤおよびパスワード（ＰＷ）と、当該ユーザのログイン権限情報３０と、当該ユーザのログイン認証可否情報３１と、当該ユーザのログインセッション情報３２との対応関係を保持する。この内、ユーザＩＤおよびパスワード（ＰＷ）と、ログイン権限情報３０は、例えば、予め管理者等によって登録される。

【0020】

ログイン権限情報３０は、複数のサービスプロバイダＳＰａ，ＳＰｂのそれぞれに対するログイン権限の有無を表す。ログイン認証可否情報３１は、ユーザに対するログイン認証許可またはログイン認証拒否を定める。ログインセッション情報３２は、ユーザがログイン中のサービスプロバイダＳＰａ，ＳＰｂを表す。すなわち、ログインサーバ１８は、ユーザがログイン権限を有するサービスプロバイダに対してログイン中であるか否か（言い換えれば、ログインセッションを確立しているか未確立であるか）を逐次管理する。

【0021】

《ネットワークシステムの概略動作および前提となる問題点》
ここで、図１において、内部ネットワーク１０のネットワーク認証について簡単に説明する。まず、認証ＤＢ２４には、予め管理者等によって、認証の対象となるユーザＩＤおよびパスワード（ＰＷ）が登録されている。この例では、ＭＡＣアドレス認証に対応するユーザＩＤ“ＭＡ１０”と、ユーザＩＤおよびパスワード（ＰＷ）を用いた認証に対応するユーザＩＤ“ＵＩＤ２０”およびパスワード“ｐｐ２０”とが登録されている。また、初期状態では、認証ＤＢ２４内の各ユーザＩＤのネットワーク認証可否情報２７は、ネットワーク認証許可に設定されているものとする。

【0022】

続いて、認証スイッチＳＷ（認証クライアント）は、ポートＰ１と内部ネットワーク１０との通信経路を遮断した状態で、ユーザ端末ＴＭ１０から内部ネットワーク１０の認証を求めるネットワーク認証要求を受信する。認証スイッチＳＷは、このネットワーク認証要求に応じて、認証サーバ１７へ認証判定要求を送信する。認証サーバ１７は、認証スイッチＳＷからの認証判定要求に応じて、認証データベースＤＢに基づいてネットワーク認証許可／ネットワーク認証拒否を判定し、その判定結果を認証スイッチＳＷへ応答する。

【0023】

この例では、認証サーバ１７は、認証ＤＢ２４内で、ユーザＩＤ“ＭＡ１０”（すなわちユーザ端末ＴＭ１０のＭＡＣアドレス）がネットワーク認証許可に設定されているため、ネットワーク認証許可と判定し、その旨を認証スイッチＳＷへ応答する。認証スイッチＳＷは、このネットワーク認証許可の応答を受けて、ポートＰ１と内部ネットワーク１０との通信経路を開放する。これによって、ユーザ端末ＴＭ１０は、内部ネットワーク１０を使用することが可能になる。

【0024】

一方、ユーザＩＤ“ＵＩＤ２０”を有するユーザ１４ｂは、例えば、過去に何らかの不正な通信を行った結果として、図１に示されるように、認証ＤＢ２４内でネットワーク認証拒否に定められているものとする。また、ユーザ端末ＴＭ１０は、本来、単数または複数の正規のユーザ１４ａによって使用される端末または共通端末であるものとする。この場合、ユーザ端末ＴＭ１０が正規のユーザ１４ａによって使用される際には問題が生じないが、不正なユーザ１４ｂによって使用される際には問題が生じ得る。すなわち、本来、内部ネットワーク１０を使用することが禁止されている不正なユーザ１４ｂであっても、ユーザ端末ＴＭ１０を介して内部ネットワーク１０を使用可能となる。

【0025】

この場合、不正なユーザ１４ｂは、ユーザ端末ＴＭ１０および内部ネットワーク１０を介してログインサーバ１８へログイン命令を送信することができる。図２のログインＤＢ２６の例では、ユーザＩＤ“ＵＩＤ２０”のログイン認証可否情報３１は、ログイン認証許可に設定されている。この場合、不正なユーザ１４ｂが、ログインサーバ１８に対して自身のユーザＩＤ“ＵＩＤ２０”およびパスワード“ｐｐ２０”を用いてログイン認証を要求すると、ログインサーバ１８は、当該要求に対してログイン認証許可と判定する。

【0026】

その結果、不正なユーザ１４ｂは、ユーザ端末ＴＭ１０および内部ネットワーク１０を介して、外部ネットワーク１１に接続されるサービスプロバイダＳＰａ，ＳＰｂへログインし、所定のサービスを利用することが可能になる。しかし、本来、当該不正なユーザ１４ｂによる内部ネットワーク１０の使用は、認証ＤＢ２４によって禁止されているため、当該内部ネットワーク１０を使ったサービスの利用も禁止されることが望ましい。

【0027】

《ログインサーバを用いたＳＳＯの概略動作》
図３は、図１において、ログインサーバを用いてＳＳＯを行う際の処理内容の一例を示すシーケンス図である。図４は、図３とは異なる処理内容の一例を示すシーケンス図である。図３は、ログインサーバ（Ｉｄｐ）１８を起点としてＳＳＯを実現する際の処理シーケンスであり、図４は、サービスプロバイダ（ここではＳＰａ）を起点としてＳＳＯを実現する際の処理シーケンスである。

【0028】

図３において、まず、ユーザは、ユーザ端末ＴＭ１０のブラウザを介してログインサーバ１８へログイン命令ＬＩＮを送信する（ステップＳ１０１）。具体的には、ユーザは、例えば、ログインサーバ１８から提供されるブラウザのログイン／ログアウト画面上で、ユーザＩＤおよびパスワード（ＰＷ）の入力を含めたログイン操作を行う。このログイン操作に応じて、ブラウザは、ログインサーバ１８へログイン命令ＬＩＮを送信する。

【0029】

続いて、ログインサーバ１８は、ログイン命令ＬＩＮに伴うユーザＩＤおよびパスワード（ＰＷ）をログインＤＢ２６に基づいて検証する。そして、ログインサーバ１８は、当該ユーザＩＤに対してログイン権限が与えられているサービスプロバイダの中から、いずれかのサービスプロバイダを選択させるためのＳＰ選択画面を、ユーザ端末ＴＭ１０のブラウザに表示させる（ステップＳ１０２）。

【0030】

次いで、ユーザが、ＳＰ選択画面上で例えばサービスプロバイダＳＰａを選択すると、ユーザ端末ＴＭ１０は、ログインサーバ１８へサービスプロバイダＳＰａの選択命令を送信する（ステップＳ１０３）。ログインサーバ１８は、当該選択命令を受けて、ユーザ端末ＴＭ１０へサービスプロバイダＳＰａへのＨＴＴＰリダイレクト要求を送信し（ステップＳ１０４）、これに応じて、ユーザ端末ＴＭ１０は、サービスプロバイダＳＰａへのＨＴＴＰリダイレクトを実行する（ステップＳ１０５）。

【0031】

続いて、サービスプロバイダＳＰａは、ログイン認証要求ＡＲＱを作成し、それをユーザ端末ＴＭ１０を介してログインサーバ１８へ送信する（ステップＳ１０６）。具体的には、サービスプロバイダＳＰａは、例えば、予め設定されたログインサーバ１８のＵＲＬ（Uniform Resource Locator）を用いて、ユーザ端末ＴＭ１０のブラウザに当該ＵＲＬへのＨＴＴＰリダイレクト等を行わせることで、ログイン認証の認証可否を含めた認証情報を問い合わせる。なお、例えば、ＳＡＭＬ規格では、当該ログイン認証要求ＡＲＱは、“ＡｕｔｈｎＲｅｑｕｅｓｔ”と呼ばれる。

【0032】

次いで、ログインサーバ１８は、認証情報を秘密鍵で電子署名し、それを含んだログイン認証応答ＡＲＳをＨＴＭＬフォームに配置して、ユーザ端末ＴＭ１０へ送信する（ステップＳ１０７）。また、この際に、ログインサーバ１８は、例えば、ＨＴＭＬフォームに対して、サービスプロバイダＳＰａへ自動送信するためのスクリプトを付加する。なお、例えば、ＳＡＭＬ規格では、当該認証情報は“Ａｓｓｅｒｔｉｏｎ”と呼ばれ、当該ログイン認証応答ＡＲＳは“Ｒｅｓｐｏｎｓｅ”と呼ばれる。

【0033】

続いて、ユーザ端末ＴＭ１０のブラウザは、受信したログイン認証応答ＡＲＳを含むＨＴＭＬフォームを、ＨＴＴＰ ＰＯＳＴメソッド（ＰＯＳＴバインディングとも呼ばれる）を用いてサービスプロバイダＳＰａへ送信する（ステップＳ１０８）。サービスプロバイダＳＰａは、ＨＴＭＬフォームからログイン認証応答ＡＲＳを取得し、その中の認証情報をログインサーバ１８の公開鍵で復号する。そして、サービスプロバイダＳＰａは、復号した認証情報に基づいて、ユーザのログインを許可すると共に、アクセス権限を検証した上で、所定のリソースをユーザへ提供する（ステップＳ１０９）。

【0034】

その後、ユーザは、ステップＳ１０３の場合と同様に、ＳＰ選択画面上で例えばサービスプロバイダＳＰｂを選択すると、ユーザ端末ＴＭ１０は、ログインサーバ１８へサービスプロバイダＳＰｂの選択命令を送信する（ステップＳ１１０）。その後は、ステップＳ１１１～Ｓ１１６において、ステップＳ１０４～Ｓ１０９の場合と同様の処理がサービスプロバイダＳＰｂを対象として行われる。

【0035】

ここで、ログインサーバ１８は、例えば、ステップＳ１０７の段階でサービスプロバイダＳＰａへのログインセッションが確立された（すなわち、サービスプロバイダＳＰａにログイン中）と判断し、図２のログインＤＢ２６内のログインセッション情報３２を更新する。同様に、ログインサーバ１８は、例えば、ステップＳ１１４の段階でサービスプロバイダＳＰｂへのログインセッションが確立された（すなわち、サービスプロバイダＳＰｂにログイン中）と判断し、ログインセッション情報３２を更新する。

【0036】

その後、ユーザは、ユーザ端末ＴＭ１０のブラウザを介してログインサーバ１８へログアウト命令ＬＯＵＴを送信する（ステップＳ１１７）。具体的には、ユーザは、例えば、ログインサーバ１８から提供されるブラウザのログイン／ログアウト画面上でログアウト操作を行う。これに応じて、ブラウザは、ログインサーバ１８へログアウト命令ＬＯＵＴを送信する。

【0037】

ログインサーバ１８は、ログアウト命令ＬＯＵＴをユーザ端末ＴＭ１０から受信した際に、図２のログインＤＢ２６に基づいて、ユーザがログイン中のサービスプロバイダへログアウト要求ＬＯＲＱを送信する（ステップＳ１１８，Ｓ１１９）。図３の例では、ログインサーバ１８は、サービスプロバイダＳＰａ，ＳＰｂの両方に対して、それぞれ、ログアウト要求ＬＯＲＱを送信する。これにより、サービスプロバイダＳＰａ，ＳＰｂは、ユーザを自身からログアウトさせる。なお、例えば、ＳＡＭＬ規格では、当該ログアウト要求ＬＯＲＱは、“ＬｏｇｏｕｔＲｅｑｕｅｓｔ”と呼ばれる。

【0038】

また、ログインサーバ１８は、例えば、ステップＳ１１８の段階でサービスプロバイダＳＰａへのログインセッションが未確立になった（すなわち、サービスプロバイダＳＰａからログアウトされた）と判断し、図２のログインＤＢ２６内のログインセッション情報３２を更新する。同様に、ログインサーバ１８は、例えば、ステップＳ１１９の段階でサービスプロバイダＳＰｂへのログインセッションが未確立になった（すなわち、サービスプロバイダＳＰｂからログアウトされた）と判断し、ログインセッション情報３２を更新する。

【0039】

このように、ユーザによる１回のログアウト操作でログイン中の複数のサービスプロバイダＳＰａ，ＳＰｂへのログアウトを実現する機能は、シングルログアウト（ＳＬＯ）と呼ばれる。シングルログアウト（ＳＬＯ）機能は、例えば、ＳＡＭＬ ２．０規格等で規定される。なお、ログインＤＢ２６内のログインセッション情報３２が確立から未確立に変更されるケースとして、ステップＳ１１７のようにログアウト命令ＬＯＵＴを受けたケースの他に、主に、次のようなケースが挙げられる。一つ目は、ステップＳ１０１でのログイン命令ＬＩＮに伴うユーザ端末ＴＭ１０とログインサーバ１８との間のログインセッションがタイムアウトに達したケースであり、二つ目は、ユーザ端末ＴＭ１０のブラウザが閉じられたケースである。

【0040】

図４において、まず、ユーザは、ユーザ端末ＴＭ１０のブラウザを介してサービスプロバイダＳＰａへアクセスする（ステップＳ２０１）。続いて、サービスプロバイダＳＰａは、図３のステップＳ１０６の場合と同様に、ログイン認証要求ＡＲＱを作成し、それをユーザ端末ＴＭ１０を介してログインサーバ１８へ送信する（ステップＳ２０２）。続いて、図３の場合と異なり、ログインサーバ１８は、ログイン認証要求ＡＲＱを受けてユーザ端末ＴＭ１０へログイン情報を要求する（ステップＳ２０３）。これに応じて、ユーザ端末ＴＭ１０は、ログインサーバ１８へログイン命令ＬＩＮを送信する（ステップＳ２０４）。

【0041】

ステップＳ２０３，Ｓ２０４において、具体的には、図３のステップＳ１０１の場合と同様に、ログインサーバ１８は、ユーザ端末ＴＭ１０のブラウザにログイン／ログアウト画面を提供する（ステップＳ２０３）。ユーザは、当該ログイン／ログアウト画面上で、ユーザＩＤおよびパスワード（ＰＷ）の入力を含めたログイン操作を行うことでログインサーバ１８へログイン命令ＬＩＮを送信する（ステップＳ２０４）。

【0042】

その後は、ステップＳ２０５～Ｓ２０７において、図３のステップＳ１０７～Ｓ１０９の場合と同様の処理が行われる。簡単に説明すると、ログインサーバ１８は、認証情報を秘密鍵で電子署名し、それを含んだログイン認証応答ＡＲＳをＨＴＭＬフォームに配置して、ユーザ端末ＴＭ１０へ送信する（ステップＳ２０５）。この際に、ログインサーバ１８は、例えば、ＨＴＭＬフォームに対して、ステップＳ２０２の要求元であるサービスプロバイダＳＰａへ自動送信するためのスクリプトを付加する。

【0043】

続いて、ユーザ端末ＴＭ１０のブラウザは、受信したログイン認証応答ＡＲＳを含むＨＴＭＬフォームを、ＨＴＴＰ ＰＯＳＴメソッドを用いてサービスプロバイダＳＰａへ送信する（ステップＳ２０６）。サービスプロバイダＳＰａは、ＨＴＭＬフォームからログイン認証応答ＡＲＳを取得し、その中の認証情報を復号した後、当該認証情報に基づいて、ユーザのログインを許可すると共に、アクセス権限を検証した上で所定のリソースをユーザへ提供する（ステップＳ２０７）。

【0044】

その後、ユーザは、ユーザ端末ＴＭ１０のブラウザを介してサービスプロバイダＳＰｂへアクセスする（ステップＳ２０８）。これに応じて、ステップＳ２０９～Ｓ２１２において、ステップＳ２０２，Ｓ２０５～Ｓ２０７の場合と同様の処理がサービスプロバイダＳＰｂを対象として行われる。すなわち、サービスプロバイダＳＰａの場合と異なり、ユーザ端末１０からログインサーバ１８へのログイン認証（ひいてはサービスプロバイダＳＰｂにログインするための認証）はステップＳ２０３，Ｓ２０４で既に完了しているため、これらの処理は行われない。

【0045】

その後、ユーザは、ユーザ端末ＴＭ１０のブラウザを介してサービスプロバイダＳＰａへログアウト命令ＬＯＵＴを送信する（ステップＳ２１３）。ここで、例えば、シングルログアウト（ＳＬＯ）機能に対応したサービスプロバイダでは、このログアウト命令ＬＯＵＴ（例えば、サービスプロバイダＳＰａからの提供画面上でのログアウト操作）をシングルログアウト（ＳＬＯ）として取り扱うことが可能である。

【0046】

この場合、サービスプロバイダＳＰａは、自身からユーザをログアウトすると共に、例えば、ＨＴＴＰリダイレクトを用いて、ユーザ端末ＴＭ１０のブラウザを介してログインサーバ１８へログアウト要求ＬＯＲＱを送信する（ステップＳ２１４）。ログインサーバ１８は、サービスプロバイダＳＰａからのログアウト要求ＬＯＲＱを受け、ログインＤＢ２６に基づいて、ユーザがログイン中の他のサービスプロバイダＳＰｂへログアウト要求ＬＯＲＱを送信する（ステップＳ２１５）。これを受けて、サービスプロバイダＳＰｂも、自身からユーザをログアウトさせる。

【0047】

ここで、ログインサーバ１８は、例えば、ステップＳ２０５の段階でサービスプロバイダＳＰａへのログインセッションが確立された（すなわち、サービスプロバイダＳＰａにログイン中）と判断し、図２のログインＤＢ２６内のログインセッション情報３２を更新する。同様に、ログインサーバ１８は、例えば、ステップＳ２１０の段階でサービスプロバイダＳＰｂへのログインセッションが確立された（すなわち、サービスプロバイダＳＰｂにログイン中）と判断し、ログインセッション情報３２を更新する。

【0048】

また、ログインサーバ１８は、例えば、ステップＳ２１４の段階でサービスプロバイダＳＰａへのログインセッションが未確立になった（すなわち、サービスプロバイダＳＰａからログアウトされた）と判断し、図２のログインＤＢ２６内のログインセッション情報３２を更新する。さらに、ログインサーバ１８は、例えば、ステップＳ２１５の段階でサービスプロバイダＳＰｂへのログインセッションが未確立になった（すなわち、サービスプロバイダＳＰｂからログアウトされた）と判断し、ログインセッション情報３２を更新する。

【0049】

《ログインサーバの詳細》
図５は、図１において、ログインサーバの主要部の構成例を示すブロック図である。図５に示すログインサーバ（Ｉｄｐ）１８は、制御部３５と、記憶部２５とを備える。記憶部２５は、例えば、ＲＡＭ（Random access memory）、不揮発性メモリ、ハードディスクドライブ、ＳＳＤ（Solid State Drive）等の組み合わせで構成され、図２に示したようなログインＤＢ２６を保持する。制御部３５は、例えば、記憶部２５に格納された所定のプログラムをＣＰＵ（Central Processing Unit）等が実行することで実装される。ただし、このような実装形態に限らず、一部または全ての構成要素を、ＦＰＧＡ（Field Programmable Gate Array）やＡＳＩＣ（Application Specific Integrated Circuit）等のデバイスで実装してもよい。

【0050】

制御部３５は、ログイン制御部３６と、画面提供部３７と、ログアウト制御部３８と、認証拒否情報設定部３９とを備え、ログインＤＢ２６に基づいて、ユーザのログイン操作またはログアウト操作に応じた各種制御を行う。ログイン制御部３６は、ユーザ端末ＴＭからのログイン命令ＬＩＮ（図３のステップＳ１０１等）や、サービスプロバイダＳＰからのログイン認証要求ＡＲＱ（図４のステップＳ２０２等）を受けて、ログイン認証の可否判定や、認証情報の作成を行う。

【0051】

また、ログイン制御部３６は、作成した認証情報をログイン認証応答ＡＲＳに包含し、当該ログイン認証応答ＡＲＳをユーザ端末ＴＭのブラウザを介して要求元のサービスプロバイダＳＰへ送信する（図３のステップＳ１０７，Ｓ１０８等）。この際に、ログイン制御部３６は、ログインＤＢ２６内のログインセッション情報３２を更新する。さらに、ログイン制御部３６は、必要に応じて、画面提供部３７を介してログイン／ログアウト画面や、ＳＰ選択画面をユーザ端末ＴＭのブラウザに表示させる（図３のステップＳ１０１，Ｓ１０２等）。

【0052】

ログアウト制御部３８は、ユーザ端末ＴＭからのログアウト命令ＬＯＵＴ（図３のステップＳ１１７等）や、サービスプロバイダＳＰからのログアウト要求ＬＯＲＱ（図４のステップＳ２１４等）を受信した際に、ログインＤＢ２６内のログインセッション情報３２を参照する。そして、ログアウト制御部３８は、ログインセッション情報３２に基づいて、ユーザがログイン中のサービスプロバイダＳＰへログアウト要求ＬＯＲＱ（図３のステップＳ１１８，Ｓ１１９等）を送信する。この際に、ログイン制御部３６は、ログインＤＢ２６内のログインセッション情報３２を更新する。また、ログイン制御部３６は、必要に応じて、画面提供部３７を介してログイン／ログアウト画面をユーザ端末ＴＭのブラウザに表示させる（図３のステップＳ１１７等）。

【0053】

さらに、ログアウト制御部３８は、認証拒否情報ＡＲＩを受信した際にも、ログインＤＢ２６内のログインセッション情報３２に基づいて、ユーザがログイン中のサービスプロバイダＳＰへログアウト要求ＬＯＲＱを送信する。認証拒否情報ＡＲＩは、所定のユーザＩＤをログインＤＢ２６内のログイン認証可否情報３１等でログイン認証拒否に定めるための情報である。これにより、認証拒否情報ＡＲＩの対象となるユーザＩＤ（すなわち不正なユーザ）からのサービスプロバイダＳＰへのアクセスは、現在アクセス中であったとしても、認証拒否情報ＡＲＩを受信した時点で、サービスプロバイダＳＰによって強制的に遮断される。

【0054】

認証拒否情報設定部３９は、認証拒否情報ＡＲＩを受信した際に、対象となるユーザＩＤに対応するログインＤＢ２６内のログイン認証可否情報３１がログイン認証拒否となるようにログインＤＢ２６を更新する。これにより、仮にアクセスを強制的に遮断された不正なユーザが、再度、サービスプロバイダＳＰへのログイン認証を試みたとしても、当該ログイン認証は、ログインサーバ１８（ログアウト制御部３８）によって拒否される。

【0055】

図６は、図１および図５のログインサーバを用いて行われる主要な処理内容の一例を示すシーケンス図である。図６では、まず、ユーザＩＤ“ＵＩＤ２０”を有するユーザがサービスプロバイダＳＰａ又はＳＰｂにログイン中となっている（ステップＳ３０１）。この状態で、例えば、当該ユーザが不正なユーザとみなされた場合、認証サーバ１７は、認証ＤＢ２４内で、ユーザＩＤ“ＵＩＤ２０”のネットワーク認証可否情報２７をネットワーク認証拒否に変更する（ステップＳ３０２）。

【0056】

また、ステップＳ３０２に伴い、ログインサーバ１８は、ネットワーク認証拒否のユーザＩＤ“ＵＩＤ２０”を含む認証拒否情報ＡＲＩを受信する（ステップＳ３０３）。この際には、認証サーバ１７が、ステップＳ３０２の処理の際に、認証拒否情報ＡＲＩを作成してログインサーバ１８へ送信する方式を用いることができる。または、ログインサーバ１８が、認証サーバ１７の認証ＤＢ２４内でネットワーク認証拒否に定められているユーザＩＤを、認証拒否情報ＡＲＩとして認証サーバ１７との定期的な通信を介して取得するような方式を用いてもよい。ただし、処理負荷および通信負荷の観点や、認証拒否情報ＡＲＩを迅速に反映させる観点では、前者の方式を用いる方が望ましい。

【0057】

また、ここでは、認証拒否情報ＡＲＩは認証サーバ１７によって作成されたが、場合によっては、管理者等が認証拒否情報ＡＲＩを手動で作成し、ログインサーバ１８（および認証サーバ１７）に手動で反映させることも可能である。いずれの場合であっても、認証拒否情報ＡＲＩは、ユーザＩＤを認証サーバ１７内でネットワーク認証拒否に定める場合に、併せて、ログインＤＢ２６内でもログイン認証拒否に定めるために作成される。

【0058】

ログインサーバ１８（認証拒否情報設定部３９）は、ステップＳ３０３での認証拒否情報ＡＲＩを受け、ログインＤＢ２６内のユーザＩＤ“ＵＩＤ２０”に対応するログイン認証可否情報３１をログイン認証拒否に変更する（ステップＳ３０４）。さらに、ログインサーバ１８（ログアウト制御部３８）は、ユーザＩＤ“ＵＩＤ２０”のユーザ（すなわち不正なユーザ）がログイン中のサービスプロバイダＳＰａ又はＳＰｂへ、ログアウト要求ＬＯＲＱを送信する（ステップＳ３０５）。

【0059】

その結果、サービスプロバイダＳＰａ又はＳＰｂは、不正なユーザがログイン中であっても、当該不正なユーザを自身から強制的にログアウトさせることが可能になる（ステップＳ３０６）。これに伴い、当該不正なユーザは、その後に、ログインサーバ１８へログイン命令ＬＩＮを送信し、再度のログイン認証を試みる（ステップＳ３０７）。この場合であっても、ログインサーバ１８は、ステップＳ３０４の処理が既に行われているため、当該ログイン認証を拒否することが可能になる（ステップＳ３０８）。

【0060】

《実施の形態１の主要な効果》
以上、実施の形態１のサーバ装置およびネットワークシステムを用いることで、代表的には、ネットワークのセキュリティを高めることが可能になる。具体的には、ネットワーク認証で認証拒否に定められたユーザをログイン認証でも認証拒否に定めることが可能になる。これにより、例えば、不正なユーザが、ネットワーク認証が許可されたユーザ端末を不正に用いてログイン認証を試みたとしても、当該ログイン認証を拒否することが可能になる。さらに、既にサービスプロバイダにログイン中のユーザであっても、当該ユーザが不正なユーザとみなされた時点で、当該ユーザを迅速かつ強制的にログアウトさせることが可能になる。

【0061】

なお、ここでは、説明の簡素化のため、同一ユーザに対する認証ＤＢ２４内のユーザＩＤとログインＤＢ２６内のユーザＩＤとは、同一の値であるものとした。ただし、当該２個のユーザＩＤは、必ずしも同一の値である必要はなく、２個のユーザＩＤの対応関係を表すテーブル等をログインサーバ１８内に設ければ、異なる値であってもよい。

【0062】

（実施の形態２）
《ネットワークシステムの概略》
図７は、本発明の実施の形態２によるネットワークシステムにおける主要部の構成例および動作例を示す概略図である。図８は、図７に続く構成例および動作例を示す概略図である。図７に示すネットワークシステムは、図１に示した構成例に加えて、不正通信検知装置１２と、ログ管理サーバ１５、ＤＨＣＰ（Dynamic Host Configuration Protocol）サーバ１６とを有する。また、認証クライアント（例えば、ＲＡＤＩＵＳクライアント）として、図１に示した認証スイッチＳＷの他に、無線ＬＡＮコントローラＷＬＣが追加されている。

【0063】

無線ＬＡＮコントローラＷＬＣは、無線通信のアクセスポイントの機能とＬ２スイッチの機能とを備える。無線ＬＡＮコントローラＷＬＣは、認証スイッチＳＷの場合と同様に、内部ネットワーク１０と、ユーザ端末ＴＭ２０との間に接続され、ユーザ端末ＴＭ２０から内部ネットワーク１０の認証を求めるネットワーク認証要求を受信する。ユーザ端末ＴＭ２０は、ＩＰアドレス“ＩＰＡ２０”およびＭＡＣアドレス“ＭＡ２０”が設定され、この例では、ユーザＩＤ“ＵＩＤ２０”を有するユーザ１４ｂによって使用される。

【0064】

ＤＨＣＰサーバ１６は、内部ネットワーク１０に接続され、記憶部２１に保持されるＩＰ管理ＤＢ２２を有する。ＤＨＣＰサーバ１６は、ユーザ端末ＴＭ１０，ＴＭ２０からのＩＰアドレスの割り当て要求に応じてＩＰアドレスを割り当て、当該ＩＰアドレスと当該ユーザ端末のＭＡＣアドレスとの対応関係をＩＰ管理ＤＢ２２に登録する。さらに、ＤＨＣＰサーバ１６は、ユーザ端末にＩＰアドレスを割り当てた場合に、当該ユーザ端末のＩＰアドレスおよびＭＡＣアドレスを含むＤＨＣＰログＬＧ２を作成し、ログ管理サーバ１５へ送信する。

【0065】

また、認証サーバ１７または認証クライアント（ＳＷまたはＷＬＣ）の一方（この例では認証サーバ１７）は、ネットワーク認証許可の際に認証許可ログＬＧ１を作成し、ログ管理サーバ１５へ送信する。認証許可ログＬＧ１は、ネットワーク認証許可の対象となるユーザＩＤと、ネットワーク認証要求の送信元であるユーザ端末のＭＡＣアドレスとを含む。

【0066】

ログ管理サーバ１５は、記憶部１９に保持される端末管理ＤＢ２０を有する。ログ管理サーバ１５は、認証サーバ１７または認証クライアント（ＳＷまたはＷＬＣ）からの認証許可ログＬＧ１と、ＤＨＣＰサーバ１６からのＤＨＣＰログＬＧ２とを受けて、端末管理ＤＢ２０に所定の情報を登録する。具体的には、ログ管理サーバ１５は、認証許可ログＬＧ１およびＤＨＣＰログＬＧ２を、その中に含まれるＭＡＣアドレスで対応付けることで、図８に示されるように、ユーザＩＤとユーザ端末のＩＰアドレスおよびＭＡＣアドレスとの対応関係を端末管理ＤＢ２０に登録する。

【0067】

不正通信検知装置１２は、ＩＰＳ（Intrusion Prevention System）装置やＩＤＳ（Intrusion Detection System）装置等である。不正通信検知装置１２は、図８に示されるように、内部ネットワーク１０から外部ネットワーク１１へ向けた通信を監視し、不正通信を検知した際に不正通信に伴う送信元のＩＰアドレスを含む不正通信検知ログＬＧ３をログ管理サーバ１５へ送信する。なお、各種ログ（ＬＧ１～ＬＧ３）は、例えば、ｓｙｓｌｏｇや、ＳＮＭＰ（Simple Network Management Protocol） Ｔｒａｐ等を用いて送信される。

【0068】

図８の例では、不正通信検知装置１２は、ユーザＩＤ“ＵＩＤ２０”のユーザ１４ｂからのユーザ端末ＴＭ２０を介した通信（ユーザフレームＵＦ）を不正通信として検知している。なお、不正通信検知装置１２は、予め通信手順や通信内容等を含む不正通信条件が設定されており、この不正通信条件を満たした通信を不正通信とみなす。

【0069】

一方、ログ管理サーバ１５は、図８に示されるように、不正通信検知装置１２からの不正通信検知ログＬＧ３と端末管理ＤＢ２０とに基づいて、不正通信を行ったユーザＩＤ（この例では“ＵＩＤ２０”）を含む認証拒否情報ＡＲＩを作成する。また、図８の例では、ログ管理サーバ１５は、作成した認証拒否情報ＡＲＩを、認証クライアント（この例ではＷＬＣ）と認証サーバ１７とログインサーバ１８へ、それぞれ、認証拒否情報ＡＲＩ１，ＡＲＩ２，ＡＲＩ３として送信している。

【0070】

認証クライアント（ＷＬＣ）は、認証拒否情報ＡＲＩ１を受けて、ユーザ端末ＴＭ２０と内部ネットワーク１０との間の通信経路を遮断する。認証サーバ１７は、認証拒否情報ＡＲＩ２を受けて、認証ＤＢ２４内の対象のユーザＩＤ“ＵＩＤ２０”に対応するネットワーク認証可否情報２７をネットワーク認証拒否に変更する。それ以降、ユーザＩＤ“ＵＩＤ２０”を用いたネットワーク認証要求は、認証サーバ１７によって拒否される。

【0071】

ログインサーバ（サーバ装置）１８は、認証拒否情報ＡＲＩ３を受けて、ログインＤＢ２６内の対象のユーザＩＤ“ＵＩＤ２０”に対応するログイン認証可否情報３１をログイン認証拒否に変更する。それ以降、ユーザＩＤ“ＵＩＤ２０”を用いたログイン認証は、ログインサーバ１８によって拒否される。さらに、ログインサーバ１８は、ユーザ１４ｂがユーザ端末ＴＭ２０を介してサービスプロバイダＳＰａ，ＳＰｂにログイン中の場合には、認証拒否情報ＡＲＩ３に応じて、ユーザ１４ｂを強制的にサービスプロバイダからログアウトさせる。

【0072】

一方、このような状況を受けて、不正なユーザ１４ｂは、例えば、実施の形態１で述べたように、ネットワーク認証が許可されているユーザ端末ＴＭ１０を不正に用いて、サービスプロバイダＳＰａ，ＳＰｂに、再度、ログイン認証を試みる場合がある。この場合、ログインサーバ１８は、既に、図８の認証拒否情報ＡＲＩ３に応じて、ログインＤＢ２６内でユーザＩＤ“ＵＩＤ２０”をログイン認証拒否に定めているため、不正なユーザ１４ｂからのログイン認証を拒否することができる。また、不正なユーザ１４ｂがユーザ端末ＴＭ１０を用いてサービスプロバイダＳＰａ，ＳＰｂにログイン済みであっても、当該不正なユーザ１４ｂを迅速かつ強制的にログアウトさせることができる。

【0073】

なお、ここでは、ログ管理サーバ１５が、ログインサーバ１８へ認証拒否情報ＡＲＩ３を送信した。ただし、これに限らず、ログ管理サーバ１５は、認証拒否情報ＡＲＩを認証サーバ１７へ送信し、ログインサーバ１８は、図６の場合と同様に、認証サーバ１７によって作成された認証拒否情報ＡＲＩを認証サーバ１７から受信してもよい。

【0074】

《実施の形態２の主要な効果》
以上、実施の形態２のサーバ装置およびネットワークシステムを用いることで、実施の形態１で述べた各種効果と同様の効果が得られる。加えて、不正通信を行ったユーザを検知し、当該検知結果をネットワーク認証およびログイン認証に即座に反映させることが可能になる。その結果、ネットワークのセキュリティをより高めることが可能になる。

【0075】

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

【0076】

例えば、ここでは、ＳＳＯのプロトコルとして、主に、ＳＡＭＬを用いる場合を例としたが、これに限らず、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ等であってもよい。

【符号の説明】

【0077】

１０ 内部ネットワーク
１１ 外部ネットワーク
１２ 不正通信検知装置
１３ ルータ
１４ａ，１４ｂ ユーザ
１５ ログ管理サーバ
１６ ＤＨＣＰサーバ
１７ 認証サーバ
１８ ログインサーバ
１９，２１，２３，２５ 記憶部
２０ 端末管理ＤＢ
２２ ＩＰ管理ＤＢ
２４ 認証ＤＢ
２６ ログインＤＢ
２７ ネットワーク認証可否情報
３０ ログイン権限情報
３１ ログイン認証可否情報
３２ ログインセッション情報
３５ 制御部
３６ ログイン制御部
３７ 画面提供部
３８ ログアウト制御部
３９ 認証拒否情報
ＡＲＩ 認証拒否情報
ＡＲＱ ログイン認証要求
ＡＲＳ ログイン認証応答
ＬＧ１ 認証許可ログ
ＬＧ２ ＤＨＣＰログ
ＬＧ３ 不正通信検知ログ
ＬＩＮ ログイン命令
ＬＯＲＱ ログアウト要求
ＬＯＵＴ ログアウト命令
ＳＰ，ＳＰａ，ＳＰｂ サービスプロバイダ
ＳＷ 認証スイッチ
ＴＭ，ＴＭ１０，ＴＭ２０ ユーザ端末
ＵＦ ユーザフレーム
ＷＬＣ 無線ＬＡＮコントローラ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】