(57)【要約】【課題】既存環境を置き換えることなく、ネットワークに接続するための認証及び認可とサービスへアクセスするための認証及び認可とを統合する。【解決手段】授受部１２が、ユーザ及び該ユーザが利用する端末の少なくとも一方の状態を表し、かつサービスへのアクセスに必要なチケット３６が付加された、既存のネットワーク接続の認証及び認可方式に従った証明書から抽出されたチケット３６を受け取る。接続可否判定部１４が、サービスへのアクセスに必要なチケット３６の種類を定めたサービス認可ポリシ７１に基づくネットワーク接続のための条件と、受け取ったチケット３６の種類とを照合して、ユーザ端末２０からサービスが稼動するサービスサーバ８０を含むネットワーク５０への接続の可否を判定する。【選択図】図９
2016062337.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータに、
ユーザ及び該ユーザが利用する端末の少なくとも一方の状態を表し、かつサービスへのアクセスに必要なチケットが付加された、既存のネットワーク接続の認証及び認可方式に従った証明書から抽出された前記チケットを受け取り、
サービスへのアクセスに必要なチケットの種類を定めたサービス認可ポリシに基づくネットワーク接続のための条件と、受け取ったチケットの種類とを照合して、前記端末から前記サービスが稼動する情報処理装置を含むネットワークへの接続の可否を判定する
ことを含む処理を実行させるための認可判定プログラム。
【請求項２】
前記ネットワーク接続のための条件を、前記サービス認可ポリシと、該サービス認可ポリシを前記ネットワーク接続のための条件として共通化するための共通化ルールとに基づいて生成する請求項１記載の認可判定プログラム。
【請求項３】
ユーザが保持するチケットによりアクセスが許可されるサービスと、各サービスが稼動する情報処理装置毎に予め割り当てられた仮想ネットワークとに基づいて求まる前記ユーザと前記仮想ネットワークとの対応関係を、前記既存のネットワーク接続の認証及び認可方式で参照するように設定する
ことをさらに含む処理を実行させるための請求項１または請求項２記載の認可判定プログラム。
【請求項４】
コンピュータに、
ユーザ及び該ユーザが利用する端末の少なくとも一方の状態を表し、かつサービスへのアクセスに必要なチケットが付加された、既存のネットワーク接続の認証及び認可方式に従った証明書から抽出された前記チケットを受け取り、
サービスへのアクセスに必要なチケットの種類を定めたサービス認可ポリシに基づくネットワーク接続のための条件と、受け取ったチケットの種類とを照合して、前記端末から前記サービスが稼動する情報処理装置を含むネットワークへの接続の可否を判定する
ことを含む処理を実行させる認可判定方法。
【請求項５】
ユーザ及び該ユーザが利用する端末の少なくとも一方の状態を表し、かつサービスへのアクセスに必要なチケットが付加された、既存のネットワーク接続の認証及び認可方式に従った証明書から抽出された前記チケットを受け取る授受部と、
サービスへのアクセスに必要なチケットの種類を定めたサービス認可ポリシに基づくネットワーク接続のための条件と、受け取ったチケットの種類とを照合して、前記端末から前記サービスが稼動する情報処理装置を含むネットワークへの接続の可否を判定する判定部と、
を含む認可判定装置。
【発明の詳細な説明】
【技術分野】
【０００１】
開示の技術は、認可判定プログラム、認可判定方法、及び認可判定装置に関する。
【背景技術】
【０００２】
近年、スマートフォンなどのモバイル端末の普及や、無線ＬＡＮやキャリアネットワークの普及、高速化に伴い、場所を選ばず業務を遂行することが求められている。
【０００３】
一方、セキュリティに対する意識も高まっており、安全性の高いネットワークの運用管理も求められている。例えば、あるユーザが立ち回り先のネットワーク毎に、サービスへアクセスするための認証及び認可を行う場合、セキュリティの観点から、立ち回り先の各々でユーザの認証情報を管理する必要がある。しかし、これは、管理面から見て現実的ではない。
【０００４】
また、今後はユーザの置かれている状況に応じて必要な情報やサービスを提供できるＩＣＴ（Information and Communication Technology）システムも求められている。
【０００５】
上記のような立ち回り先毎にユーザの認証情報を管理することを回避することと、ユーザの状況に応じたサービスの提供との両方を実現するためには、ユーザまたはユーザが利用する端末の“状態”に応じたアクセス制御が必要となる。
【０００６】
ユーザまたはユーザが利用する端末の状態に応じたアクセス制御に関して、複数の種類の複数の状態の各々毎にターゲット情報へのアクセス権限を規定しているアクセスチケットを各アクセス者に発行する情報アクセス制御方法が提案されている。この方法では、アクセス者からのアクセス要求を受け付けると、この要求とともに入力されたアクセスチケットの種類および状態に対応するアクセス権限をアクセスチケット権限情報格納手段から読み出す。そして、このアクセス権限に基づいてアクセス要求を許可するか否かを判定する。また、アクセス者からの状態遷移要求を受け付けると、この要求とともに入力されたアクセスチケットの種類および状態に基づいて遷移先状態を状態遷移情報格納手段から読み出し、この遷移先状態でアクセスチケットの状態を更新する。
【０００７】
一方、ユーザの端末から、ネットワーク上のサービスへアクセスする際には、まず、ネットワークに接続した後、サービスへアクセスするためのパケットを送出することになる。この場合、ネットワークへ接続するための認証及び認可と、サービスサーバへアクセスするための認証及び認可とが行われる。
【０００８】
認証及び認可に関して、例えば、認証機構が、ユーザ情報をデータベースに蓄積されたユーザ情報とユーザがアクセスしたい情報リソースとの対応情報と比較してユーザを認証するネットワークセキュリティシステムが提案されている。このシステムでは、ユーザの送信元情報と情報リソースへのアクセス権限とから、ファイアウォール機構で使用するセキュリティポリシを動的に生成し、ユーザからの通信の通過制御を行う。
【０００９】
また、ネットワーク上のコンテンツサーバへアクセスする端末と、認証鍵を生成する認証鍵生成サーバと、認証鍵を配布するポータルサーバと、アクセス管理サーバとを備えるネットワークアクセス認証システムが提案されている。認証鍵は、ネットワークへアクセスするためのネットワーク設定情報と、ネットワークへのアクセス認可に使用される認証トークンと、ネットワークにおいて特定のアクセス先以外へのアクセスを制限するアクセスポリシーとを含む。アクセス管理サーバは、認証トークンに応じてアクセス認可要求を認可するか否かを判定し、アクセス認可要求を認可する場合、ネットワークに設けられたアクセスポリシー設定部にアクセスポリシーを設定する。
【００１０】
また、サーバ収容ネットワークとインターネットの接続点に置かれたゲートウェイが、ユーザ端末がサーバ収容ネットワークに接続するためのリモートアクセス認証の処理を行うサービス提供システムが提案されている。このシステムでは、認証が成功であることを確認すると、ゲートウェイはリモートアクセス認証結果を認証確認サーバに転送する。この後、ユーザ端末はサービスサーバにサービス要求を送る。サービスサーバはサービス要求を受信すると、認証確認サーバに対し認証確認を送信し、認証確認サーバは認証済みの通知をサービスサーバに返送する。サービスサーバは認証済みであることの確認がとれると、要求されたサービス情報をユーザ端末に対し送付する。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２０００−２１５１６５号公報
【特許文献２】特開２００４−２２０１２０号公報
【特許文献３】特開２００８−２１９２６６号公報
【特許文献４】特開２００４−１３３８２４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１２】
しかしながら、従来の認証及び認可に関する技術は、ネットワークへ接続するための認証及び認可と、サービスへアクセスするための認証及び認可とがそれぞれ別に行われるため、各々で管理工数が発生してしまう。なお、従来技術のリモートアクセス認証の処理を行うサービス提供システムでは、ネットワークへ接続するための認証と、サービスサーバへアクセスするための認証とは、共通化されている。しかし、ネットワーク接続の認可判定と、サービスへのアクセスの認可判定とでは、それぞれに応じた認可ポリシに基づいて認可判定を行う。そのため、ネットワーク接続の認可判定用の認可ポリシと、サービスへのアクセスの認可判定用の認可ポリシとをそれぞれ管理する必要がある。
【００１３】
そこで、管理工数を軽減するために、ネットワークに接続するための認証及び認可とサービスへアクセスするための認証及び認可とを統合することが考えられる。例えば、ネットワークの入り口であるＷＬＡＮ−ＡＰ（Wireless LAN access point）で、両方の認証及び認可を担うことが考えられる。
【００１４】
しかし、この場合、ＷＬＡＮ−ＡＰに両方の認証及び認可を行うための機能を追加する必要がある。また、ユーザが利用する端末の状態に応じたサービスの提供のために、チケットを用いたアクセス制御を行う場合では、ユーザの端末とＷＬＡＮ−ＡＰとの間のやり取りも新規のプロトコルになる。そのため、両方の認証及び認可を行うためには、既に広く敷設されている既存のＷＬＡＮ−ＡＰを置き換える必要があり、新たなコストが発生し、現実的ではない。
【００１５】
一つの側面として、開示の技術は、既存環境を置き換えることなく、ネットワークに接続するための認証及び認可とサービスへアクセスするための認証及び認可とを統合することを目的とする。
【課題を解決するための手段】
【００１６】
一つの態様では、開示の技術は、ユーザ及び該ユーザが利用する端末の少なくとも一方の状態を表し、かつサービスへのアクセスに必要なチケットが付加された、既存のネットワーク接続の認証及び認可方式に従った証明書から抽出された前記チケットを受け取る。そして、サービスへのアクセスに必要なチケットの種類を定めたサービス認可ポリシに基づくネットワーク接続のための条件と、受け取ったチケットの種類とを照合する。そして、前記端末から前記サービスが稼動する情報処理装置を含むネットワークへの接続の可否を判定する。
【発明の効果】
【００１７】
一つの側面として、開示の技術は、既存環境を置き換えることなく、ネットワークに接続するための認証及び認可とサービスへアクセスするための認証及び認可とを統合することができる、という効果を有する。
【図面の簡単な説明】
【００１８】
【図１】第１の参照形態に係るサービス提供システムの概略構成を示すブロック図である。
【図２】チケットの一例を示す図である。
【図３】第１の参照形態に係るサービス提供システムにおける処理の流れを示すシーケンス図である。
【図４】第２の参照形態に係るサービス提供システムの概略構成を示すブロック図である。
【図５】第２の参照形態に係るサービス提供システムにおける処理の流れを示すシーケンス図である。
【図６】第１実施形態に係るサービス提供システムの概略構成を示すブロック図である。
【図７】ユーザ端末及び既存認証サーバにおける、チケットの受け渡しに関連する機能を説明するための図である。
【図８】チケット付証明書の一例を示す図である。
【図９】第１実施形態に係る認可判定装置の機能ブロック図である。
【図１０】サービス認可ポリシの一例を示す図である。
【図１１】第１及び第２実施形態に係る認可判定装置として機能するコンピュータの概略構成を示すブロック図である。
【図１２】第１実施形態に係るサービス提供システムにおける処理の流れを示すシーケンス図である。
【図１３】第１実施形態における認可判定処理の一例を示すフローチャートである。
【図１４】第３の参照形態に係るサービス提供システムの概略構成を示すブロック図である。
【図１５】第３の参照形態に係るサービス提供システムにおける処理の流れを示すシーケンス図である。
【図１６】第２実施形態に係る認可判定装置の機能ブロック図である。
【図１７】サーバ−ＶＬＡＮテーブル１８の一例を示す図である。
【図１８】第２実施形態に係るサービス提供システムにおける処理の流れを示すシーケンス図である。
【図１９】第２実施形態における認可判定処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００１９】
以下、図面を参照して開示の技術に係る実施形態の一例を詳細に説明する。
【００２０】
本実施形態では、ユーザ及びユーザが利用する端末（以下、「ユーザ端末」という）の少なくとも一方の状態（以下、単に「ユーザの状態」という）を表すチケットを用いて、サービスへアクセスするための認証及び認可の判定を行うことを前提とする。そして、本実施形態では、このようなチケットを用いたサービスへアクセスするための認証及び認可と、目的のサービスが稼動するサービスサーバを含むネットワークへ接続するための認証及び認可とを、既存環境を置き換えることなく統合することを目的とする。この目的を明確にするため、まず、チケットを用いて、目的のサービスへアクセスするまでの手順を説明する。なお、以下では、サービスへのアクセスを「サービス接続」、ネットワークへの接続を「ネットワーク接続」ともいう。
【００２１】
図１に、第１の参照形態に係るサービス提供システム１００Ａを示す。図１に示すように、サービス提供システム１００Ａは、ユーザ端末２０と、チケット管理サーバと３０、ユーザ端末２０とネットワーク５０との接続点となるＷＬＡＮ−ＡＰ（Wireless LAN access point）４０とを含む。また、ネットワーク５０には、既存認証サーバ６０と、チケット検証プロキシサーバ７０と、複数のサービスサーバ８０Ａ、８０Ｂ、８０Ｃとが接続されている。なお、複数のサービスサーバ８０Ａ、８０Ｂ、８０Ｃの各々を区別なく説明する場合には、単に「サービスサーバ８０」と表記する。
【００２２】
ユーザ端末２０は、ユーザが利用する情報処理装置であり、例えば、ノート型パーソナルコンピュータ（ＰＣ）、スマートフォン、タブレット端末、携帯電話等である。なお、本実施形態では、ユーザが複数の立ち回り先の各々からネットワーク５０に接続する場合を想定し、ユーザ端末２０は可搬型のものとしているが、デスクトップ型のＰＣなどにも適用可能である。ユーザ端末２０には、ＧＰＳ（Global Positioning System）センサ、ＮＦＣ（Near Field Communication）通信機、温度センサ、湿度センサ、カメラ、マイク等、ユーザの状態をセンシング可能な各種センサ２１が搭載されている。
【００２３】
チケット管理サーバ３０は、状態認証部３１とチケット発行部３２とを含む。状態認証部３１は、ユーザ端末２０に搭載されセンサ２１によりセンシングされたセンサデータが示すユーザの状態を認証する。この認証は、センサ２１毎のセンサデータ、または複数のセンサデータの組み合わせが表すユーザの状態を予め定義したテーブルを用意しておき、取得したセンサデータとこのテーブルとを照合することにより行うことができる。
【００２４】
チケット発行部３２は、状態認証部３１の認証結果に基づいて、ユーザの状態を示すチケットを発行する。図２に、チケット発行部３２が発行するチケットの一例を示す。図２の例では、暗号化及びエンコード前のチケット３５は、チケットの識別子であるチケットＩＤ３５Ａと、チケットの種別３５Ｂと、種別を含まないチケットの名前３５Ｃと、有効期限３５Ｄと、発行元のＵＲＬ３５Ｅとを含む。チケットの種別３５Ｂは、チケットの名前を区別するためのもので、チケットの名前３５Ｃが同じでも、チケットの種別３５Ｂが異なれば違うチケットとして扱う。有効期限３５Ｄは、１９７０年１月１日  ００：００：００からのミリ秒で表した時刻である。発行元のＵＲＬ３５Ｅは、チケットの有効性を検証可能なＵＲＬであり、チケット管理サーバ３０のＵＲＬである。この暗号化及びエンコード前のチケット３５を暗号化及びエンコードしたチケット３６が発行される。
【００２５】
既存認証サーバ６０は、例えば、ＩＥＥＥ８０２．１Ｘプロトコルのような既存のプロトコルを利用してネットワーク接続時の認証及び認可を行う。既存認証サーバ６０は、例えばＲＡＤＩＵＳ（Remote Authentication Dial In User Service）サーバである。既存認証サーバ６０は、ユーザの認証及びネットワーク接続の認可判定を行うためのユーザ情報６１を保持している。
【００２６】
チケット検証プロキシサーバ７０は、チケットに基づいてサービスへのアクセス制御を行う。チケット検証プロキシサーバ７０は、ユーザ端末２０から送信されたサービス要求に付加されたチケット３６と、サービスへのアクセスを許可するためのチケットの種類を予め定義したサービス認可ポリシ７１とを照合して、サービス接続の認可判定を行う。
【００２７】
サービスサーバ８０は、例えば画像、映像、音楽等のコンテンツの提供、照明や空調設備等の制御などの各種サービスを提供するサーバである。
【００２８】
図３を参照して、サービス提供システム１００Ａにおける処理の流れを説明する。まず、ユーザ端末２０は、ユーザ端末２０のセンサ２１でセンシングされたセンサデータと共に、チケット要求をチケット管理サーバ３０へ送信する（図３中の１２１）。チケット管理サーバ３０では、取得したセンサデータに基づいて、ユーザの状態認証を行って（図３中の１２２）、ユーザの状態を表すチケット３６を発行し、ユーザ端末２０へ送信する（図３中の１２３）。
【００２９】
ユーザ端末２０は、ネットワーク接続用の証明書をインストールしたり、ユーザの識別情報であるユーザＩＤ及びユーザＩＤに対応するパスワードを入力したりするなど、ユーザの本人確認（認証）に必要な情報を用意する（図３中の１２４）。そして、ユーザ端末２０からＷＬＡＮ−ＡＰ４０へ、用意した証明書等を付加したネットワーク接続要求を送信する（図３中の１２５）。ＷＬＡＮ−ＡＰ４０は、ユーザ端末２０からのネットワーク５０に対する接続の認証及び認可の判定を要求する認証認可要求に、ネットワーク接続要求と共に受信した証明書等を付加して、既存認証サーバ６０へ送信する（図３中の１２６）。
【００３０】
既存認証サーバ６０では、認証認可要求に付加された証明書等の本人確認に必要な情報と、予めユーザ情報６１として保持している証明書に関する情報やユーザＩＤ及びパスワードとを照合して、ユーザの本人確認（認証）を行う。さらに、既存認証サーバ６０は、認証されたユーザからのネットワーク接続要求を許可するか否かを、ユーザ情報６１として保持しているユーザの所属部署などの属性情報を参照して判定する（図３中の１２７）。ネットワーク接続を許可する場合には、接続許可をＷＬＡＮ−ＡＰ４０を経由して、ユーザ端末２０に応答する。さらに、必要に応じてＤＨＣＰ（Dynamic Host Configuration Protocol）サーバによるＩＰアドレスの配布が行われたのち、ユーザ端末２０はネットワーク５０内の機器に対してＩＰ通信が可能となる。
【００３１】
そして、ユーザ端末２０は、例えばｈｔｔｐリクエストのヘッダに、発行されたチケット３６を付加したサービス要求を、チケット検証プロキシサーバ７０へ送信する（図３中の１３０）。チケット検証プロキシサーバ７０は、ユーザ情報６１とは別に管理されるサービス認可ポリシ７１を参照し、要求されているサービスへのアクセスを許可するための条件を満たすチケット３６が付加されているか否かを検証する（図３中の１３１）。チケット検証プロキシサーバ７０は、条件を満たすチケット３６が付加されている場合には、サービス接続を許可し、サービス要求を該当のサービスサーバ８０へ転送する（図３中の１３２）。
【００３２】
例えば、ユーザが存在する場所の不快指数が予め定めた閾値以上の場合に、そのユーザに対して、空調を制御するためのサービスへのアクセスを可能とするようなサービスの提供を考える。この場合、ユーザは、温度センサや湿度センサでセンシングしたセンサデータをチケット管理サーバ３０へ送信する。チケット管理サーバ３０では、センサデータに基づいて不快指数を計算し、予め定めた閾値以上であれば、ユーザが存在する場所の不快指数が予め定めた閾値以上であることを表すチケット３６を発行する。ユーザは、このチケット３６を付加したサービス要求を行う。チケット検証プロキシサーバ７０で用いるサービス認可ポリシ７１には、ユーザが存在する場所の不快指数が予め定めた閾値以上であることを表すチケット３６が付加されている場合には、空調を制御するためのサービスへのアクセスを許可する旨が定義されている。チケット検証プロキシサーバ７０は、このサービス認可ポリシ７１と、サービス要求に付加されたチケット３６とを照合し、サービスへのアクセス制御を行う。
【００３３】
また、他の例として、ＧＰＳセンサのセンサデータや、ＮＦＣ通信機の通信記録などから得られるユーザ端末２０の位置が、例えば予め定めた店舗内等の特定の領域に存在することを表すチケット３６を発行することができる。そして、このチケット３６が付加されたサービス要求に応じて、割引クーポンを取得するためのサービスへアクセスできるようなアクセス制御を行うこともできる。
【００３４】
第１の参照形態に係るサービス提供システム１００Ａにおいては、ユーザの状態に応じたチケットを発行することで、ユーザまたはユーザ端末２０に対して認証済みとしている。従って、チケットを付加してサービス要求を行うことで、サービス接続の認証に対して、証明書やユーザＩＤ及びパスワード等の情報を用意するなどのユーザの作業は発生しない。しかし、ネットワーク接続時には、サービス接続とは別に、従来通りの証明書やユーザＩＤ及びパスワード等による本人確認が行われるため、証明書のインストール、ユーザＩＤ及びパスワードの入力や管理など、ユーザの手間がその分増えることになる。また、既存認証サーバ６０では、サービス認可ポリシ７１とは別に、ユーザ情報６１の管理も必要となり、管理工数も増加する。
【００３５】
そこで、ユーザ及び管理者の手間や管理工数を軽減するために、サービス接続の認証及び認可と、ネットワーク接続の認証及び認可とを統合する場合を考える。図４に、両者を統合する場合の第２の参照形態に係るサービス提供システム１００Ｂを示す。第２の参照形態に係るサービス提供システム１００Ｂは、第１の参照形態に係るサービス提供システム１００Ａとは、既存認証サーバ６０を含まない点、及びＷＬＡＮ−ＡＰ４０に認可判定部４１を設けた点が異なる。
【００３６】
ＷＬＡＮ−ＡＰ４０に設けられた認可判定部４１は、ユーザ端末２０から送信されたチケット３６が付加されたネットワーク接続要求に基づいて、ネットワーク接続の認証及び認可を判定する。
【００３７】
図５を参照して、第２の参照形態に係るサービス提供システム１００Ｂにおける処理の流れを説明する。なお、図３に示した第１の参照形態に係るサービス提供システム１００Ａの処理と同様の処理については、同一符号を付して詳細な説明を省略する。
【００３８】
チケット管理サーバ３０からチケット３６が発行されると（図５中の１２３）、ユーザ端末２０では、そのチケット３６を付加したネットワーク接続要求をＷＬＡＮ−ＡＰ４０に送信する（図５中の１３４）。ＷＬＡＮ−ＡＰ４０の認可判定部４１は、チケット検証プロキシサーバ７０で管理するサービス認可ポリシ７１を参照して、ネットワーク接続の認可判定を行う。例えば、付加されたチケット３６で、ネットワーク５０内で提供されるサービスへのアクセスが可能な場合には、ネットワーク接続を許可するように判定することができる。
【００３９】
その後は、第１の参照形態と同様に、ＷＬＡＮ−ＡＰ４０からユーザ端末２０へ接続許可を応答し（図５中の１２９）、ユーザ端末２０から、チケット３６を付加したサービス要求が行われる（図５中の１３０〜１３２）。
【００４０】
この場合、ＷＬＡＮ−ＡＰ４０に、第２の参照形態に係るサービス提供システム１００Ｂ独自の機能である認可判定部４１を追加する必要がある。また、ユーザ端末２０とＷＬＡＮ−ＡＰ４０との間のやり取りも新規のプロトコルになるため、その実装が必要である。このように、第２の参照形態に係るサービス提供システム１００Ｂでは、既に広く敷設されている既存のＷＬＡＮ−ＡＰ４０を置き換える必要があり、新たなコストが発生し、現実的ではない、という問題がある。
【００４１】
そこで、本実施形態では、サービス接続の認証及び認可とネットワーク接続の認証及び認可とを、既存環境を置き換えることなく統合することを目的としている。以下、開示の技術に係る各実施形態について詳細に説明する。
【００４２】
＜第１実施形態＞
図６に、第１実施形態に係るサービス提供システム１００を示す。なお、第１の参照形態に係るサービス提供システム１００Ａ及び第２の参照形態に係るサービス提供システム１００Ｂと同一の部分については、同一符号を付して詳細な説明を省略する。
【００４３】
第１実施形態に係るサービス提供システム１００は、ユーザ端末２０と、チケット管理サーバと３０、ユーザ端末２０とネットワーク５０との接続点となるＷＬＡＮ−ＡＰ４０とを含む。また、ネットワーク５０には、認証サーバ１１と、チケット検証プロキシサーバ７０と、複数のサービスサーバ８０Ａ、８０Ｂ、８０Ｃとが接続されている。
【００４４】
認証サーバ１１は、既存認証サーバ６０と、第１実施形態に係る認可判定装置１０とを含む。既存認証サーバ６０は、第１及び第２の参照形態と同様に、ＲＡＤＩＵＳサーバ等の既存方式でネットワーク接続の認証及び認可を行うサーバである。
【００４５】
図７を参照して、ユーザ端末２０及び既存認証サーバ６０における、チケット３６の受け渡しに関連する機能について説明する。
【００４６】
図７に示すように、ユーザ端末２０は、既存方式のネットワーク接続の認証のための証明書を作成する証明書作成部２２と、接続先となるＷＬＡＮ−ＡＰ４０を管理し、ＷＬＡＮ−ＡＰ４０を経由した通信を制御する通信部２３とを含む。また、既存認証サーバ６０は、証明書の拡張領域に格納されたデータを抽出する抽出部６２と、外部機能との間でデータの授受を行うインターフェースである授受部６３とを含む。ユーザ端末２０の証明書作成部２２及び通信部２３の機能は、いずれもユーザ端末２０が一般的に有する機能である。また、既存認証サーバ６０の抽出部６２及び授受部６３の機能は、いずれも既存認証サーバ６０が一般的に有する機能である。
【００４７】
証明書作成部２２は、ＯｐｅｎＳＳＬ（Secure Sockets Layer）などの機能を使って実現することができる。証明書作成部２２は、キーストア２４に格納されたＣＡ（Certification Authority）証明書、クライアント証明書、及びクライアント秘密鍵を取得して、ネットワーク接続の認証に用いる既存方式による証明書を作成する。この際、証明書作成部２２は、チケット管理サーバ３０から発行されたチケット３６を証明書に付加する。例えば、証明書作成部２２は、既存の証明書に設けられた拡張領域にチケット３６を内包させる。
【００４８】
図８に、チケット３６が付加されたチケット付証明書３７の一例を示す。図８の例は、ＯｐｅｎＳＳＬで作成されたｘ．５０９証明書の一例であり、ｘ．５０９証明書のｖ３拡張領域３７Ａにチケット３６を内包している。拡張領域３７Ａにチケット３６を内包する方法は、ｈｔｔｐリクエストのヘッダにチケット３６を付加する方法と同様である。図８の例では、チケット３６を複数のフラグメントに分割し、分割したフラグメントの個数と、各フラグメントのデータとが、拡張領域３７Ａに格納されている。各フラグメントのデータは、例えば、各フラグメントにＯＩＤ（オブジェクトＩＤ）を付与し、各フラグメントのデータをＡＳＮ．１（Abstract Syntax Notation One）で記述し、ＯＩＤに対応する属性値として格納している。既存認証サーバ６０がＲＡＤＩＵＳサーバの場合、属性値のサイズの上限は２５３ｂｙｔｅであるため、各フラグメントのサイズはそれ以下になるように設定する。
【００４９】
通信部２３は、チケット付証明書３７を付加したネットワーク接続要求を、ＷＬＡＮ−ＡＰ４０を経由して、認証サーバ１１へ送信する。
【００５０】
認証サーバ１１では、既存認証サーバ６０が、チケット付証明書３７が付加されたネットワーク接続要求を受け付ける。既存認証サーバ６０の抽出部６２は、チケット付証明書３７の拡張領域３７Ａからチケット３６を抽出し、証明書の作成者であるユーザのユーザＩＤと共に、授受部６３へ受け渡す。授受部６３は、ユーザＩＤを含むチケット検証依頼をチケット３６と共に認可判定装置１０へ送信する。また、授受部６３は、認可判定装置１０から検証結果（詳細は後述）を受け取る。
【００５１】
このように、既存の証明書が有する拡張領域３７Ａなどの自由に使える領域にチケット３６を付加することで、簡単な設定のみで、既存の証明書にチケット３６を付加することができる。また、拡張領域３７Ａにチケット３６が付加されたチケット付証明書３７も、証明書自体は既存のものであるため、ユーザ端末２０とＷＬＡＮ−ＡＰ４０間のプロトコルの変更も必要ない。なお、証明書へのチケット３６の付加方法は上記の例に限定されず、既存の認証方式を利用可能な方法であればよい。
【００５２】
図９に示すように、認可判定装置１０は、授受部１２と、ＮＷ認可ポリシ生成部１３と、接続可否判定部１４とを含む。
【００５３】
授受部１２は、既存認証サーバ６０から、ユーザＩＤを含むチケット検証依頼をチケット３６と共に受け取る。また、授受部１２は、後述する接続可否判定部１４で判定された検証結果を既存認証サーバ６０へ受け渡す。
【００５４】
ＮＷ認可ポリシ生成部１３は、チケット検証プロキシサーバ７０で管理されるサービス認可ポリシ７１と、後述する共通化ルール１７とから、ネットワーク接続の認可判定を行うためのネットワーク接続ポリシを生成する。
【００５５】
ここで、サービス認可ポリシ７１は、図１０に示すように、サービスにアクセスする際に必要なチケット３６の種類（チケット条件）を、サービス毎に予め定義したものである。図１０の例では、サービスへのアクセス先を示すＵＲＬ（以下、「サービスＵＲＬ」という）が「ｈｔｔｐ：／／ａ．ａ／ａ」のサービスにアクセスするためには、チケットＡが必要であることを表している。また、サービスＵＲＬが「ｈｔｔｐ：／／ｂ．ｂ／ｂ」のサービスにアクセスするためには、チケットＢが必要であることを表している。また、サービスＵＲＬが「ｈｔｔｐ：／／ｃ．ｃ／ｃ」のサービスにアクセスするためには、チケットＣ及びチケットＤが必要であることを表している。なお、「チケットＸ」は、種類が「Ｘ」のチケット３６を表す。また、以下では、サービスＵＲＬが「ｈｔｔｐ：／／ｘ．ｘ／ｘ」のサービスを「サービスＸ」とも表記する。
【００５６】
共通化ルール１７は、サービス認可ポリシ７１と共通化したネットワーク認可ポリシを生成するためのルールであり、管理者の方針により予め定義されたものである。サービス認可ポリシ７１に基づいてネットワーク認可ポリシを生成するのは、ネットワーク接続はサービスを利用するための手段であるため、サービスにアクセス可能であれば、ネットワーク接続は許可して問題ない、との考え方に基づくものである。
【００５７】
例えば、下記のいずれかのような共通化ルール１７を定義しておくことができる。
（１）ネットワーク５０内にアクセス可能なサービスが一つでも存在する場合には、ネットワーク接続可
（２）ネットワーク５０内の全てのサービスにアクセス可能な場合には、ネットワーク接続可
（３）サービス要求の対象となるサービスにアクセス可能な場合には、ネットワーク接続可
【００５８】
上記（１）または（２）の共通化ルール１７によれば、１度ネットワーク接続したら、接続を維持したまま他のサービスへアクセスすることが可能である。上記（３）の共通化ルールによれば、異なるサービスにアクセスする毎に、ネットワーク接続を行う必要がある。
【００５９】
ＮＷ認可ポリシ生成部１３は、例えば、図１０に示すサービス認可ポリシ７１と上記（１）の共通化ルール１７とに基づいて、「ＡｏｒＢｏｒ（Ｃ＆Ｄ）」というネットワーク認可ポリシを生成する。同様に、例えば、図１０に示すサービス認可ポリシ７１と上記（２）の共通化ルール１７とからは、「Ａ＆Ｂ＆Ｃ＆Ｄ」というネットワーク認可ポリシが生成される。また、同様に、例えば、図１０に示すサービス認可ポリシ７１と上記（３）の共通化ルール１７とからは、以下のネットワーク認可ポリシが生成される。
「（ｈｔｔｐ：／／ａ．ａ／ａ＆Ａ）ｏｒ（ｈｔｔｐ：／／ｂ．ｂ／ｂ＆Ｂ）ｏｒ（ｈｔｔｐ：／／ｃ．ｃ／ｃ＆（Ｃ＆Ｄ））」・・・（ｉ）
【００６０】
接続可否判定部１４は、ＮＷ認可ポリシ生成部１３で生成されたネットワーク認可ポリシと、授受部１２が受け取ったチケット３６の種類とを照合し、ネットワーク接続の可否を判定する。「ＡｏｒＢｏｒ（Ｃ＆Ｄ）」というネットワーク認可ポリシが生成されている場合には、受け取ったチケット３６がチケットＡ、チケットＢ、またはチケットＣとチケットＤであれば接続許可と判定する。例えば、受け取ったチケット３６がチケットＤのみの場合には、接続拒否と判定する。また、「Ａ＆Ｂ＆Ｃ＆Ｄ」というネットワーク認可ポリシが生成されている場合には、チケットＡ、チケットＢ、チケットＣ、及びチケットＤの全てを受け取っている場合には、接続許可、いずれか一つでもチケット３６が不足している場合には、接続拒否と判定する。
【００６１】
また、上記（ｉ）に示すネットワーク認可ポリシが生成されている場合には、サービスＡへのアクセスに対して、チケットＡが付加されている場合には、接続許可と判定する。また、サービスＢへのアクセスに対して、チケットＢが付加されている場合には、接続許可と判定する。また、サービスＣへのアクセスに対して、チケットＣとチケットＤが付加されている場合には、接続許可と判定する。その他の場合には、接続拒否と判定する。
【００６２】
接続可否判定部１４は、ネットワーク接続の可否を、チケット検証依頼に対する検証結果として授受部１２に受け渡す。
【００６３】
認可判定装置１０は、例えば図１１に示すコンピュータ９０で実現することができる。コンピュータ９０はＣＰＵ９１、一時記憶領域としてのメモリ９２、及び不揮発性の記憶部９３を備える。また、コンピュータ９０は、表示装置及び入力装置等の入出力装置９８が接続される入出力インターフェース（Ｉ／Ｆ）９４を備える。また、コンピュータ９０は、記録媒体９９に対するデータの読み込み及び書き込みを制御するｒｅａｄ／ｗｒｉｔｅ（Ｒ／Ｗ）部９５、及びインターネット等のネットワークに接続されるネットワークＩ／Ｆ９６を備える。ＣＰＵ９１、メモリ９２、記憶部９３、入出力Ｉ／Ｆ９４、Ｒ／Ｗ部９５、及びネットワークＩ／Ｆ９６は、バス９７を介して互いに接続される。
【００６４】
記憶部９３はＨＤＤ（Hard Disk Drive）、ＳＳＤ（solid state drive）、フラッシュメモリ等によって実現できる。記憶媒体としての記憶部９３には、コンピュータ９０を認可判定装置１０として機能させるための認可判定プログラム１１０が記憶される。ＣＰＵ９１は、認可判定プログラム１１０を記憶部９３から読み出してメモリ９２に展開し、認可判定プログラム１１０が有するプロセスを順次実行する。
【００６５】
認可判定プログラム１１０は、授受プロセス１１２と、ＮＷ認可ポリシ生成プロセス１１３と、接続可否判定プロセス１１４とを有する。ＣＰＵ９１は、授受プロセス１１２を実行することで、図９に示す授受部１２として動作する。また、ＣＰＵ９１は、ＮＷ認可ポリシ生成プロセス１１３を実行することで、図９に示すＮＷ認可ポリシ生成部１３として動作する。また、ＣＰＵ９１は、接続可否判定プロセス１１４を実行することで、図９に示す接続可否判定部１４として動作する。これにより、認可判定プログラム１１０を実行したコンピュータ９０が、認可判定装置１０として機能することになる。
【００６６】
なお、認可判定装置１０は、例えば半導体集積回路、より詳しくはＡＳＩＣ（Application Specific Integrated Circuit）等で実現することも可能である。
【００６７】
次に、第１実施形態に係るサービス提供システム１００の作用について、図１２のシーケンス図を参照して説明する。なお、図３に示す第１の参照形態における処理、及び図５に示す第２の参照形態における処理と同様の処理については、同一符号を付して詳細な説明を省略する。
【００６８】
チケット管理サーバ３０からチケット３６が発行されると（図１２中の１２３）、ユーザ端末２０の証明書作成部２２が、ネットワーク接続の認証に用いる既存の証明書の拡張領域３７Ａにチケット３６を内包させたチケット付証明書３７を作成する（図１２中の１５１）。そして、ユーザ端末２０の通信部２３が、チケット付証明書３７を付加したネットワーク接続要求を、ＷＬＡＮ−ＡＰ４０を経由して、認証サーバ１１へ送信する（図１２中の１５２、１５３）。
【００６９】
認証サーバ１１では、既存認証サーバ６０が、チケット付証明書３７が付加されたネットワーク接続要求を受け付ける。そして、既存認証サーバ６０の抽出部６２が、チケット付証明書３７の拡張領域３７Ａからチケット３６を抽出し、授受部６３へ受け渡す（図１２中の１５４）。授受部６３は、ユーザＩＤを含むチケット検証依頼をチケット３６と共に認可判定装置１０へ送信する（図１２中の１５５）。認可判定装置１０では、図１３に示す認可判定処理が実行される（図１２中の１５６）。
【００７０】
図１３に示す認可判定処理のステップＳ１１で、授受部１２が、チケット検証依頼を受信したか否かを判定する。受信していない場合には、本ステップの判定を繰り返し、受信した場合には、処理はステップＳ１２へ移行する。
【００７１】
ステップＳ１２では、授受部１２が、受信したチケット検証依頼に含まれるユーザＩＤ、及び共に受信したチケット３６を、所定の記憶領域に保存する。
【００７２】
次に、ステップＳ１３で、ＮＷ認可ポリシ生成部１３が、チケット検証プロキシサーバ７０からサービス認可ポリシ７１を取得すると共に、共通化ルール１７を取得する。次に、ステップＳ１４で、ＮＷ認可ポリシ生成部１３が、取得したサービス認可ポリシ７１と共通化ルール１７とに基づいて、ネットワーク接続の認可判定を行うためのネットワーク接続ポリシを生成する。
【００７３】
次に、ステップＳ１５で、接続可否判定部１４が、上記ステップＳ１４で生成されたネットワーク認可ポリシと、上記ステップＳ１２で所定の記憶領域に記憶したチケット３６の種類とを照合する。そして、接続可否判定部１４は、検証依頼の対象であるチケット３６が、ネットワーク認可ポリシで定める条件を満たすか否かを判定する。条件を満たす場合には、処理はステップＳ１６へ移行し、満たさない場合には、処理はステップＳ１７へ移行する。
【００７４】
ステップＳ１６では、接続可否判定部１４が、検証結果として「接続許可」を授受部１２に受け渡す。一方、ステップＳ１７では、接続可否判定部１４が、検証結果として「接続拒否」を授受部１２に受け渡す。次に、ステップＳ１８で、授受部１２が、既存認証サーバ６０に検証結果を応答して（図１２中の１５７）、認可判定処理を終了する。なお、図１２では、検証結果が「接続許可」の場合を記載し、検証結果が「接続拒否」の場合は記載を省略している。
【００７５】
その後は、第１及び第２の参照形態と同様に、ＷＬＡＮ−ＡＰ４０からユーザ端末２０へ接続許可を応答し（図１２中の１２８、１２９）、ユーザ端末２０から、チケット３６を付加したサービス要求が行われる（図１２中の１３０〜１３２）。
【００７６】
以上説明したように、第１実施形態に係るサービス提供システム１００によれば、チケット管理サーバ３０から発行されたチケット３６を付加したチケット付証明書３７をユーザ端末２０にて生成する。そして、ユーザ端末２０が、チケット付証明書３７を既存のプロトコルで既存認証サーバ６０へ送信する。既存認証サーバ６０では、チケット付証明書３７からチケット３６を抽出し、外部インターフェースである授受部６３を介して、認可判定装置１０へ送信する。認可判定装置１０では、サービス認可ポリシ７１と共通化ルール１７とから生成したネットワーク認可ポリシと、受信したチケット３６とに基づいて、ネットワーク接続の可否を判定する。
【００７７】
このように、ネットワーク接続の可否判定で用いるネットワーク接続ポリシを、サービス認可ポリシから生成するため、ネットワーク接続の認可とサービス接続の認可とを統合することができる。また、ユーザの状態を認証して発行されたチケット、すなわち認証済みであることを示すチケットを用いることで、ネットワーク接続の認証とサービス接続の認証とを統合することができる。さらに、既存のネットワーク接続方式の証明書にチケット３６を付加するため、既存認証サーバ６０及び既存のプロトコルをそのまま利用することができる。すなわち、既存環境を置き換えることなく、ネットワークに接続するための認証及び認可とサービスへアクセスするための認証及び認可とを統合することができる。
【００７８】
これにより、ユーザは、サービス接続及びネットワーク接続のために、それぞれの認証用の情報（ユーザＩＤ及びパスワード、証明書等）を取得及び管理する必要がなく、ユーザの状態に応じたチケット３６を入手するだけでよいため、ユーザの手間を軽減できる。また、管理者はサービス認可ポリシと、ネットワーク認可ポリシとをそれぞれ設定及び管理する必要がない。管理者は、サービス認可ポリシのみを設定及び管理し、サービス認可ポリシと共通化したネットワーク認可ポリシを生成するための共通化ルールを定義しておけばよいため、設定及び管理の手間を軽減できる。
【００７９】
＜第２実施形態＞
第１実施形態では、ネットワーク接続が許可された場合には、ユーザ端末２０から、同一ネットワーク５０内の各サービスに対してＩＰ通信が可能になる。そのため、サービス毎のアクセス制限がかかっていても、ネットワークレベルでは接続可能な場合があり、セキュリティ上問題がある場合がある。
【００８０】
そこで、ユーザ毎にアクセス可能な範囲を設定するために、ユーザ毎に仮想ネットワークを割り当てることを考える。この場合の参照形態として、図１４に、第３の参照形態に係るサービス提供システム１００Ｃを示す。
【００８１】
サービス提供システム１００Ｃでは、各サービスが稼動する各サービスサーバ８０をそれぞれ別のＶＬＡＮ（Virtual LAN）に対応付けている。図１４の例では、サービスサーバ８０Ａは、ＶＬＡＮの識別子であるＶＬＡＮ−ＩＤが１０のＶＬＡＮ（以下、「ＶＬＡＮ１０」と表記する。他のＶＬＡＮについても同様）に属している。また、サービスサーバ８０ＢはＶＬＡＮ２０に、サービスサーバ８０ＣはＶＬＡＮ３０に属している。ＶＬＡＮの設定は、ＬＡＮスイッチにタグＶＬＡＮを設定し、ＬＡＮスイッチにおいて、ユーザ端末２０から送信されるパケットにタグ情報として付与されたＶＬＡＮ−ＩＤに従ったルーティングを行うことで実現できる。
【００８２】
サービス提供システム１００Ｃにおける既存認証サーバ６０は、ユーザ端末２０毎にＶＬＡＮを割り当て、ユーザ端末２０のＭＡＣアドレスとＶＬＡＮ−ＩＤとを対応付けて記録したユーザ−ＶＬＡＮテーブル６４を保持する。ユーザ−ＶＬＡＮテーブル６４は、管理者により事前に設定される。既存認証サーバ６０は、ネットワーク接続を許可するユーザ端末２０に対して割り当てられているＶＬＡＮ−ＩＤをＷＬＡＮ−ＡＰ４０に通知する。
【００８３】
ＷＬＡＮ−ＡＰ４０では、ユーザ端末２０のＭＡＣアドレスと、通知されたＶＬＡＮ−ＩＤとを対応付けてＭＡＣ−ＶＬＡＮテーブル４２に保持する。そして、ＷＬＡＮ−ＡＰ４０は、ユーザ端末２０からのパケットのＭＡＣフレームのヘッダ部分に、ＶＬＡＮ−ＩＤを示すタグ情報を付加してネットワーク５０内に転送する。
【００８４】
タグＶＬＡＮが設定されたＬＡＮスイッチは、ユーザ端末２０からのパケットを、タグ情報として付加されたＶＬＡＮ−ＩＤで識別されるＶＬＡＮに属するサービスサーバ８０のみへ転送する。
【００８５】
図１５を参照して、第３の参照形態にかかるサービス提供システム１００Ｃの処理の流れを説明する。ユーザ端末２０から、ＷＬＡＮ−ＡＰ４０へ証明書を添付したネットワーク接続要求を送信する（図１５中の１２５）。そして、ＷＬＡＮ−ＡＰ４０から既存認証サーバ６０へ認証認可要求を送信する（図１５中の１２６）。既存認証サーバ６０は、証明書によりユーザの認証を行う。そして、認証されたユーザに対応するユーザ端末２０のＭＡＣアドレスに割り当てられたＶＬＡＮ−ＩＤを、ユーザ−ＶＬＡＮテーブル６４から取得する（図１５中の１３６）。
【００８６】
既存認証サーバ６０は、取得したＶＬＡＮ−ＩＤと共に、接続許可をＷＬＡＮ−ＡＰ４０に送信する（図１５中の１３７）。ＷＬＡＮ−ＡＰ４０では、接続許可と共に受信したＶＬＡＮ−ＩＤと、ネットワーク接続要求を送信したユーザ端末２０のＭＡＣアドレスとを対応付けて、ＭＡＣ−ＶＬＡＮテーブル４２に記録する（図１５中の１３８）。ユーザ端末２０からサービス要求が送信されると（図１５中の１４０）、ＷＬＡＮ−ＡＰ４０が、ＭＡＣ−ＶＬＡＮテーブル４２からユーザ端末２０のＭＡＣアドレスに対応したＶＬＡＮ−ＩＤを取得し、ＭＡＣフレームのヘッダ部分にタグ情報として付加する。そして、目的のサービスサーバ８０へ転送する（図１５中の１４１）。
【００８７】
上記のような、ユーザ端末２０に対するＶＬＡＮ割り当てによるアクセス制御は、既存認証サーバ６０が有する既存の機能である。このＶＬＡＮの割り当てによるアクセス制御を行うことで、サービスレベルのアクセス制限を、ネットワーク接続にも適用することができる。さらに、このＶＬＡＮの割り当てによるアクセス制限を、チケットを用いたサービスへのアクセス制御に適用することが考えられる。例えば、ユーザ端末２０がサービスＡにアクセスするためのチケットＡを保持している場合、サービスＡが稼動するサービスサーバ８０が属するＶＬＡＮと同一のＶＬＡＮにユーザ端末２０を割り当てる。そして、ユーザ端末２０から他のＶＬＡＮへのアクセスを禁止すればよい。
【００８８】
しかし、チケットを用いたサービスへのアクセス制御を行う場合、ユーザの状態に応じてユーザ端末２０が保持するチケット３６は変わり、これに伴いユーザ端末２０からアクセス可能なサービスも変わる。従って、事前にユーザ端末２０毎に割り当てるＶＬＡＮを決定することが困難であるという問題がある。
【００８９】
そこで、第２実施形態では、ユーザ端末２０に対するＶＬＡＮの割り当てを、ユーザ端末２０が保持するチケット３６に応じて動的に変更する。以下、第２実施形態について詳述する。なお、第１の参照形態に係るサービス提供システム１００Ａ、第２の参照形態に係るサービス提供システム１００Ｂ、及び第１実施形態に係るサービス提供システム１００と同一の部分については、同一符号を付して詳細な説明を省略する。
【００９０】
第２実施形態では、第１実施形態に係るサービス提供システム１００と認証サーバの構成が異なるため、図１６を参照して、第２実施形態に係る認証サーバ２１１について説明する。図１６に示すように、認証サーバ２１１は、既存認証サーバ６０と認可判定装置２１０とを含む。既存認証サーバ６０は、ユーザ−ＶＬＡＮテーブル６４を保持する。
【００９１】
認可判定装置２１０は、授受部１２と、ＮＷ認可ポリシ生成部１３と、接続可否判定部１４と、ＶＬＡＮ割当決定部１５と、ＶＬＡＮ割当更新部１６とを含む。
【００９２】
ＶＬＡＮ割当決定部１５は、サービス認可ポリシ７１を参照して、接続可否判定部１４によりネットワーク接続が許可されたユーザ端末２０から受信したチケット３６に基づいてアクセス可能なサービスを判定する。例えば、授受部１２によりチケットＢが受け取られている場合には、図１０に示すようなサービス認可ポリシ７１を参照して、該当のサービスは、サービスＵＲＬが「ｈｔｔｐ：／／ｂ．ｂ／ｂ」のサービス（サービスＢ）であると判定する。
【００９３】
また、ＶＬＡＮ割当決定部１５は、予め設定されたサービスサーバ８０とＶＬＡＮとの対応関係を示すサーバ−ＶＬＡＮテーブル１８を参照する。図１７に、サーバ−ＶＬＡＮテーブル１８の一例を示す。図１７の例では、各サービスのサービスＵＲＬと、そのサービスＵＲＬで示されるサービスが稼動するサービスサーバ８０の識別情報と、各サービスサーバ８０に割り当てられたＶＬＡＮのＶＬＡＮ−ＩＤとが対応付けて記録されている。サービスサーバ８０の識別情報は、例えばサーバＩＤやサーバ名とすることができる。なお、図１７の例では、「サーバＡ」はサービスサーバ８０Ａのサーバ名、「サーバＢ」はサービスサーバ８０Ｂのサーバ名、「サーバＣ」はサービスサーバ８０Ｃのサーバ名であるとする。
【００９４】
ＶＬＡＮ割当決定部１５は、サーバ−ＶＬＡＮテーブル１８から、ユーザ端末２０から受信したチケットに基づいてアクセス可能なサービスが稼動するサービスサーバ８０に割り当てられているＶＬＡＮのＶＬＡＮ−ＩＤを取得する。そして、ＶＬＡＮ割当決定部１５は、取得したＶＬＡＮ−ＩＤを、ユーザ端末２０に割り当てるＶＬＡＮのＶＬＡＮ−ＩＤとして決定する。例えば、上記のように、ユーザ端末２０から、ネットワーク接続要求と共にチケットＢを受信した場合には、そのユーザ端末２０に対して、サービスサーバ８０Ｂに割り当てられているＶＬＡＮと同じＶＬＡＮ２０が割り当てられる。
【００９５】
ＶＬＡＮ割当更新部１６は、ＶＬＡＮ割当決定部１５により決定されたユーザ端末２０に割り当てるＶＬＡＮに基づいて、既存認証サーバ６０が参照するユーザ−ＶＬＡＮテーブル６４を更新する。具体的には、ＶＬＡＮ割当更新部１６は、ユーザ−ＶＬＡＮテーブル６４において、該当のユーザ端末２０のＭＡＣアドレスに割り当てられたＶＬＡＮ−ＩＤを、ＶＬＡＮ割当決定部１５により決定したＶＬＡＮ−ＩＤに書き換える。ＶＬＡＮ割当更新部１６は、ユーザ−ＶＬＡＮテーブル６４の更新が終了すると、その旨を授受部１２に通知する。授受部１２は、ＶＬＡＮ割当更新部１６によるユーザ−ＶＬＡＮテーブル６４の更新が終了した後で、接続可否判定部１４によるチケット３６の検証結果を、既存認証サーバ６０に応答する。
【００９６】
認可判定装置２１０は、例えば図１１に示すコンピュータ９０で実現することができる。記憶媒体としての記憶部９３には、コンピュータ９０を認可判定装置２１０として機能させるための認可判定プログラム３１０が記憶される。ＣＰＵ９１は、認可判定プログラム３１０を記憶部９３から読み出してメモリ９２に展開し、認可判定プログラム３１０が有するプロセスを順次実行する。
【００９７】
認可判定プログラム３１０は、授受プロセス１１２と、ＮＷ認可ポリシ生成プロセス１１３と、接続可否判定プロセス１１４と、ＶＬＡＮ割当決定プロセス１１５と、ＶＬＡＮ割当更新プロセス１１６とを有する。ＣＰＵ９１は、ＶＬＡＮ割当決定プロセス１１５を実行することで、図１６に示すＶＬＡＮ割当決定部１５として動作する。また、ＣＰＵ９１は、ＶＬＡＮ割当更新プロセス１１６を実行することで、図１６に示すＶＬＡＮ割当更新部１６として動作する。他のプロセスについては、第１実施形態と同様である。これにより、認可判定プログラム３１０を実行したコンピュータ９０が、認可判定装置２１０として機能することになる。
【００９８】
なお、認可判定装置２１０は、例えば半導体集積回路、より詳しくはＡＳＩＣ等で実現することも可能である。
【００９９】
次に、第２実施形態に係るサービス提供システムの作用について、図１８のシーケンス図を参照して説明する。なお、図３に示す第１の参照形態における処理、図５に示す第２の参照形態における処理、及び図１２に示す第１実施形態における処理と同様の処理については、同一符号を付して詳細な説明を省略する。
【０１００】
既存認証サーバ６０の授受部６３から、チケット検証依頼がチケット３６と共に認可判定装置２１０へ送信されると（図１８中の１５５）、認可判定装置２１０において、図１９に示す認可判定処理が実行される（図１８中の１６１）。なお、図１９に示す第２実施形態における認可判定処理において、図１３に示す第１実施形態における認可判定処理と同一の処理については、同一符号を付して詳細な説明を省略する。
【０１０１】
図１９に示す認可判定処理のステップＳ１１〜ステップＳ１４を経て、次のステップＳ１５で肯定判定されると、処理はステップＳ１６を経て、ステップＳ２０へ移行する。
【０１０２】
ステップＳ２０では、ＶＬＡＮ割当決定部１５が、サービス認可ポリシ７１を参照して、上記ステップＳ１５で、接続可否判定部１４によりネットワーク接続が許可されたユーザ端末２０から受信したチケット３６に基づいてアクセス可能なサービスを判定する。そして、ＶＬＡＮ割当決定部１５は、サーバ−ＶＬＡＮテーブル１８を参照して、判定したサービスが稼動するサービスサーバ８０に割り当てられているＶＬＡＮのＶＬＡＮ−ＩＤを取得する。そして、ＶＬＡＮ割当決定部１５は、取得したＶＬＡＮ−ＩＤを、ユーザ端末２０に割り当てるＶＬＡＮのＶＬＡＮ−ＩＤとして決定する。
【０１０３】
次に、ステップＳ２１で、ＶＬＡＮ割当更新部１６が、ＶＬＡＮ割当決定部１５により決定されたユーザ端末２０に割り当てるＶＬＡＮ−ＩＤに基づいて、既存認証サーバ６０が参照するユーザ−ＶＬＡＮテーブル６４を更新する。そして、ＶＬＡＮ割当更新部１６は、ユーザ−ＶＬＡＮテーブル６４の更新が終了すると、その旨を授受部１２に通知し、処理はステップＳ１８へ移行する。
【０１０４】
一方、上記ステップＳ１５で否定判定されると、処理はステップＳ１７を経て、ステップＳ１８へ移行する。
【０１０５】
ステップＳ１８では、授受部１２が、既存認証サーバ６０に検証結果を応答して（図１８中の１５７）、認可判定処理を終了する。なお、図１８では、検証結果が「接続許可」の場合を記載し、検証結果が「接続拒否」の場合は記載を省略している。
【０１０６】
既存認証サーバ６０は、認可判定装置２１０から接続許可の検証結果を受信すると、ユーザ−ＶＬＡＮテーブル６４から、ネットワーク接続要求を送信したユーザ端末２０のＭＡＣアドレスに割り当てられたＶＬＡＮ−ＩＤを取得する。この段階では、ユーザ−ＶＬＡＮテーブル６４に登録されているユーザ端末２０毎のＶＬＡＮ−ＩＤは、ユーザ端末２０が保持するチケット３６でアクセス可能なサービスが稼動するサービスサーバ８０と同じＶＬＡＮのＶＬＡＮ−ＩＤに更新されている。そして、既存認証サーバ６０は、取得したＶＬＡＮ−ＩＤと共に、接続許可をＷＬＡＮ−ＡＰ４０へ応答する（図１８中の１６３）。
【０１０７】
ＷＬＡＮ−ＡＰ４０は、ユーザ端末２０から送信されたチケット３６が付加されたサービス要求を受信すると（図１８中の１６４）、サービス要求のパケットに、ユーザ端末２０に割り当てられたＶＬＡＮ−ＩＤをタグ情報として付加する。そして、タグ情報が付加されたサービス要求を、チケット３６と共にチケット検証プロキシサーバ７０へ転送する（図１８中の１６５）。
【０１０８】
チケット検証プロキシサーバ７０でチケット３６に基づいてサービスへのアクセスが許可されると、サービス要求は、タグ情報として付加されたＶＬＡＮ−ＩＤが示すＶＬＡＮが割り当てられたサービスサーバ８０へ転送される（図１８中の１６６）。
【０１０９】
以上説明したように、第２実施形態に係るサービス提供システムによれば、認可判定装置２１０が、ネットワーク接続要求に付加されたチケット３６によりアクセス可能なサービスが稼働するサービスサーバ８０に割り当てられたＶＬＡＮ−ＩＤを取得する。そして、取得したＶＬＡＮ−ＩＤをユーザ端末２０に割り当てるＶＬＡＮのＶＬＡＮ−ＩＤとして決定する。これにより、第１実施形態の効果に加え、サービス認可ポリシとネットワーク認可ポリシとを個別に設定する場合に生じ得るセキュリティ上の問題も回避することができる。
【０１１０】
また、第２実施形態を応用して、例えば、同一のチケットを保持しているユーザを１つのユーザグループとして管理し、グループ毎にアクセス先を制限するような構成を実現することができる。例えば、貸店舗ビルにおける無線ＬＡＮのインフラとして第２実施形態のシステムを提供することで、店舗毎にＡＰを立てることなく、店舗毎にネットワークをグルーピングすることができる。また、サービスサーバとしてＳＩＰ（Session Initiation Protocol）を備えておき、ユーザ端末がグループを識別するチケットさえ保持していれば、ユーザ個人の持ち込みのユーザ端末であっても、内線化することができる。
【０１１１】
なお、第１及び第２実施形態では、既存認証サーバ６０と認可判定装置１０または２１０とで認証サーバ１１または２１１を構成する場合について説明したが、これに限定されない。認可判定装置１０または２１０に既存認証サーバ６０の機能も併せて持たせるようにしてもよい。
【０１１２】
また、認証サーバ１１または２１１において、チケット３６が付加されていない既存方式によるネットワーク接続要求を受信した場合には、既存認証サーバ６０に直接認証及び認可の処理を実行させることができる。これにより、既存方式と本実施形態の方式とを併用することができる。
【０１１３】
また、上記では、認可判定プログラム１１０または３１０が記憶部９３に予め記憶（インストール）されている態様を説明したが、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の記憶媒体に記録された形態で提供することも可能である。
【０１１４】
以上の上記各実施形態に関し、更に以下の付記を開示する。
【０１１５】
（付記１）
コンピュータに、
ユーザ及び該ユーザが利用する端末の少なくとも一方の状態を表し、かつサービスへのアクセスに必要なチケットが付加された、既存のネットワーク接続の認証及び認可方式に従った証明書から抽出された前記チケットを受け取り、
サービスへのアクセスに必要なチケットの種類を定めたサービス認可ポリシに基づくネットワーク接続のための条件と、受け取ったチケットの種類とを照合して、前記端末から前記サービスが稼動する情報処理装置を含むネットワークへの接続の可否を判定する
ことを含む処理を実行させるための認可判定プログラム。
【０１１６】
（付記２）
前記ネットワーク接続のための条件を、前記サービス認可ポリシと、該サービス認可ポリシを前記ネットワーク接続のための条件として共通化するための共通化ルールとに基づいて生成する付記１記載の認可判定プログラム。
【０１１７】
（付記３）
前記ネットワーク接続のための条件を、ネットワークへの接続を許可するチケットの種類で定めた付記２記載の認可判定プログラム。
【０１１８】
（付記４）
ユーザが保持するチケットによりアクセスが許可されるサービスと、各サービスが稼動する情報処理装置毎に予め割り当てられた仮想ネットワークとに基づいて求まる前記ユーザと前記仮想ネットワークとの対応関係を、前記既存のネットワーク接続の認証及び認可方式で参照するように設定する
ことをさらに含む処理を実行させるための付記１〜付記３のいずれか１項記載の認可判定プログラム。
【０１１９】
（付記５）
コンピュータに、
ユーザ及び該ユーザが利用する端末の少なくとも一方の状態を表し、かつサービスへのアクセスに必要なチケットが付加された、既存のネットワーク接続の認証及び認可方式に従った証明書から抽出された前記チケットを受け取り、
サービスへのアクセスに必要なチケットの種類を定めたサービス認可ポリシに基づくネットワーク接続のための条件と、受け取ったチケットの種類とを照合して、前記端末から前記サービスが稼動する情報処理装置を含むネットワークへの接続の可否を判定する
ことを含む処理を実行させる認可判定方法。
【０１２０】
（付記６）
前記ネットワーク接続のための条件を、前記サービス認可ポリシと、該サービス認可ポリシを前記ネットワーク接続のための条件として共通化するための共通化ルールとに基づいて生成する付記５記載の認可判定方法。
【０１２１】
（付記７）
前記ネットワーク接続のための条件を、ネットワークへの接続を許可するチケットの種類で定めた付記６記載の認可判定方法。
【０１２２】
（付記８）
ユーザが保持するチケットによりアクセスが許可されるサービスと、各サービスが稼動する情報処理装置毎に予め割り当てられた仮想ネットワークとに基づいて求まる前記ユーザと前記仮想ネットワークとの対応関係を、前記既存のネットワーク接続の認証及び認可方式で参照するように設定する
ことをさらに含む処理を実行させるための付記５〜付記７のいずれか１項記載の認可判定方法。
【０１２３】
（付記９）
ユーザ及び該ユーザが利用する端末の少なくとも一方の状態を表し、かつサービスへのアクセスに必要なチケットが付加された、既存のネットワーク接続の認証及び認可方式に従った証明書から抽出された前記チケットを受け取る授受部と、
サービスへのアクセスに必要なチケットの種類を定めたサービス認可ポリシに基づくネットワーク接続のための条件と、受け取ったチケットの種類とを照合して、前記端末から前記サービスが稼動する情報処理装置を含むネットワークへの接続の可否を判定する判定部と、
を含む認可判定装置。
【０１２４】
（付記１０）
前記判定部は、前記ネットワーク接続のための条件を、前記サービス認可ポリシと、該サービス認可ポリシを前記ネットワーク接続のための条件として共通化するための共通化ルールとに基づいて生成する付記９記載の認可判定装置。
【０１２５】
（付記１１）
前記ネットワーク接続のための条件を、ネットワークへの接続を許可するチケットの種類で定めた付記１０記載の認可判定装置。
【０１２６】
（付記１２）
ユーザが保持するチケットによりアクセスが許可されるサービスと、各サービスが稼動する情報処理装置毎に予め割り当てられた仮想ネットワークとに基づいて求まる前記ユーザと前記仮想ネットワークとの対応関係を、前記既存のネットワーク接続の認証及び認可方式で参照するように設定する設定部
をさらに含む付記９〜付記１１のいずれか１項記載の認可判定装置。
【０１２７】
（付記１３）
コンピュータに、
ユーザ及び該ユーザが利用する端末の少なくとも一方の状態を表し、かつサービスへのアクセスに必要なチケットが付加された、既存のネットワーク接続の認証及び認可方式に従った証明書から抽出された前記チケットを受け取り、
サービスへのアクセスに必要なチケットの種類を定めたサービス認可ポリシに基づくネットワーク接続のための条件と、受け取ったチケットの種類とを照合して、前記端末から前記サービスが稼動する情報処理装置を含むネットワークへの接続の可否を判定する
ことを含む処理を実行させるための認可判定プログラムを記録した記録媒体。
【０１２８】
（付記１４）
ユーザ及び該ユーザが利用する端末の少なくとも一方の状態を表し、かつサービスへのアクセスに必要なチケットを、既存のネットワーク接続の認証及び認可方式に従った証明書に付加して送信する前記端末と、
前記チケットが付加された証明書から前記チケットを抽出する抽出部と、抽出した前記チケットを外部機能に受け渡す第１授受部とを含む既存認証装置と、
前記既存認証装置から前記チケットを受け取る第２授受部と、サービスへのアクセスに必要なチケットの種類を定めたサービス認可ポリシに基づくネットワーク接続のための条件と、受け取ったチケットの種類とを照合して、前記端末から前記サービスが稼動する情報処理装置を含むネットワークへの接続の可否を判定する判定部とを含む認可判定装置と、
を含む認可判定システム。
【符号の説明】
【０１２９】
１０、２１０  認可判定装置
１１、２１１  認証サーバ
１２   授受部
１３   ＮＷ認可ポリシ生成部
１４   接続可否判定部
１５   ＶＬＡＮ割当決定部
１６   ＶＬＡＮ割当更新部
１７   共通化ルール
１８   サーバ−ＶＬＡＮテーブル
２０   ユーザ端末
２１   センサ
３０   チケット管理サーバ
３６   チケット
３７   チケット付証明書
４０   ＷＬＡＮ−ＡＰ
５０   ネットワーク
６０   既存認証サーバ
６１   ユーザ情報
６２   抽出部
６３   授受部
６４   ユーザ−ＶＬＡＮテーブル
７０   チケット検証プロキシサーバ
７１   サービス認可ポリシ
８０   サービスサーバ
９０   コンピュータ
９１   ＣＰＵ
９２   メモリ
９３   記憶部
１００ サービス提供システム
１１０、３１０       認可判定プログラム
【図１】
2016062337.tif 000003
【図２】
2016062337.tif 000004
【図３】
2016062337.tif 000005
【図４】
2016062337.tif 000006
【図５】
2016062337.tif 000007
【図６】
2016062337.tif 000008
【図７】
2016062337.tif 000009
【図８】
2016062337.tif 000010
【図９】
2016062337.tif 000011
【図１０】
2016062337.tif 000012
【図１１】
2016062337.tif 000013
【図１２】
2016062337.tif 000014
【図１３】
2016062337.tif 000015
【図１４】
2016062337.tif 000016
【図１５】
2016062337.tif 000017
【図１６】
2016062337.tif 000018
【図１７】
2016062337.tif 000019
【図１８】
2016062337.tif 000020
【図１９】
2016062337.tif 000021