JP5268785B2 - Ｗｅｂサーバシステムへのログイン制限方法 - Google Patents

Description

本発明は、Ｗｅｂサーバシステムにおけるユーザのログインの制御技術に関し、特に、システムの負荷の状況に応じてユーザのログイン可能数を制限してアクセスの流量制限を行うＷｅｂサーバシステムへのログイン制限方法に適用して有効な技術に関するものである。

Ｗｅｂサーバシステムを構築する際には、各サーバやネットワーク、データベースなどのキャパシティプランニングを行い、ピーク時等においてシステムの負荷が高くなった場合であっても応答時間やＴＡＴ（Turn Around Time）、スループットなどにおいて所定のパフォーマンスを維持できるようにシステム設計が行われる。しかし、予想外の突発的なイベントによるアクセスの集中やシステム障害などにより、想定した以上にシステムが高負荷となり、応答時間の増加やエラーの発生など正常なサービスの提供ができなくなる場合も起こり得る。

このような状況に対して通常は、システムの負荷の状況を常時監視し、負荷が増大した場合にはシステムの資源を増強したりすることが行われている。また、システムの負荷が正常なサービスの継続が困難となるような所定の閾値を超えたことを検知した際には、Ｗｅｂサーバに対する新たなユーザのログインを拒否するとともに、例えばＷｅｂサイトのトップ画面に「しばらく待ってから再度ログインして下さい」などと表示された閉塞画面を提示して混雑していることを通知し、不必要なアクセスが行われることを抑止することが行われている。

さらに、例えば、特開２００１−２６５６９３号公報（特許文献１）には、整理券発行機能を有し、Ｗｅｂサーバが混雑した場合に、混雑の度合いや待ち時間に関する情報をユーザに提供し、また、アクセス順序に応じてトラフィックの制御を行うことにより、利便性を向上させ、また、ユーザからのアクセスのリトライによるさらなる混雑状態の悪化を防ぐＷｅｂサーバシステムが開示されている。

特開２００１−２６５６９３号公報

従来技術のＷｅｂサーバシステムでは、システムの負荷（各種ハードウェア資源の使用率やネットワーク負荷、ログインセッション数など）が、正常なサービスの継続が困難となるような所定の閾値を超えたことを検知した場合にログインを制限し、それ以降の不要なアクセスを抑止して流量制限を行うことが可能である。

一方、上記のような手順によりアクセスの流量制限を行った場合であっても、近年では、Ｗｅｂサーバ間はいわゆるシングルサインオン（以下では「ＳＳＯ」と記載する場合がある）により連携している場合もある。この場合、信頼できるＷｅｂサーバにおける既にログイン済みのユーザの認証情報を他のＷｅｂサーバに受け渡し、他のＷｅｂサーバでは当該認証情報に基づいて、ユーザによる新たなログイン認証を行わずにセッションを生成する。従って、従来技術によるアクセスの流量制限の手法では、上記他のＷｅｂサーバにおいてＳＳＯによるアクセスに対するログイン制限により流量制限を行うことは難しい。

そこで本発明の目的は、Ｗｅｂサーバシステムが高負荷となった際に、シングルサインオンによるアクセスに対しても適切にログイン制限することにより流量制限を行うＷｅｂサーバシステムへのログイン制御方法を提供することにある。本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

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

本発明の代表的な実施の形態によるＷｅｂサーバシステムへのログイン制御方法は、Ｗｅｂサーバシステムの負荷状況に応じて、前記Ｗｅｂサーバシステムへのユーザのログイン可能数を制限して、前記Ｗｅｂサーバシステムに対するアクセスの流量制限を行うものであって、以下のステップを実行することを特徴とするものである。

すなわち、アクセスの流量制限を行う第１Ｗｅｂサーバシステムが、定期的に前記第１Ｗｅｂサーバシステムの負荷状況を確認し、確認結果に応じて前記第１Ｗｅｂサーバシステムに新規にログイン可能なユーザ数を算出して、算出したユーザ数分のトークンを発行し、発行した前記トークンを、前記ユーザについての認証情報を前記第１Ｗｅｂサーバシステムに対して受け渡してシングルサインオンにより連携する１つ以上の第２Ｗｅｂサーバシステムに対して予め配布する第１ステップと、前記第２Ｗｅｂサーバシステムが、クライアント端末を利用した前記ユーザからの前記第２Ｗｅｂサーバシステムを経由した前記第１Ｗｅｂサーバシステムへのシングルサインオンによるアクセス要求を処理する際に、前記第１Ｗｅｂサーバシステムから配布された前記トークンのうち使用可能な前記トークンがあるか否かを確認する第２ステップと、前記第２ステップにおいて使用可能な前記トークンがある場合に、前記第２Ｗｅｂサーバシステムが、前記トークンのうちの１つを使用して前記アクセス要求を処理する第３ステップと、前記第２ステップにおいて使用可能な前記トークンがない場合に、前記第２Ｗｅｂサーバシステムが、前記アクセス要求の処理を行わずに拒否する第４ステップとを実行することを特徴とするものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

本発明の代表的な実施の形態によれば、Ｗｅｂサーバシステムにおいて予め設定されたログイン可能なユーザ数に対応して、当該Ｗｅｂサーバシステムに対するログイン要求を処理するためのトークンを、シングルサインオンによりアクセスしてくる他のＷｅｂサーバに対して発行する。このため、予め発行されたトークンの数に対応したユーザのログインを可能とするとともに、使用可能なトークンがない場合はログイン処理を抑止することで、発行済みのトークンの数に応じた確実な流量制限を行うことが可能となる。

本発明の一実施の形態であるＷｅｂサーバシステムへのログイン制御方法のＳＳＯ環境の場合の例について概要を示した図である。 本発明の一実施の形態であるＷｅｂサーバシステムへのログイン制御方法の例について概要を示した図である。 本発明の一実施の形態であるＷｅｂサーバシステムへのログイン制御方法を実装するＷｅｂシステムの構成例の概要を示した図である。 本発明の一実施の形態におけるトークン管理のデータ構造およびデータの例を示した図である。 本発明の一実施の形態におけるトークンのデータ構造およびデータの例を示した図である。 本発明の一実施の形態における配布ルールのデータ構造およびデータの例を示した図である。 本発明の一実施の形態におけるトークンの発行および配布の処理の例を示したシーケンス図である。 本発明の一実施の形態におけるトークン発行元のＷｅｂサーバでのログイン要求時の処理の例を示したシーケンス図である。 本発明の一実施の形態におけるトークン発行元のＷｅｂサーバに対するＳＳＯによるアクセス要求時の処理の例を示したシーケンス図である。 本発明の一実施の形態における使用可能なトークンがない場合の処理の例を示したシーケンス図である。

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

［概要］
図２は、本発明の一実施の形態であるＷｅｂサーバシステムへのログイン制御方法の例について概要を示した図である。図２のトークン発行元Ｗｅｂサーバ１００（１００ａ、１００ｂ）は、それぞれ、ポータルサイト等を提供し、定期的にシステムの負荷状況（各種ハードウェア資源の使用率やネットワーク負荷、ログインセッション数など）を確認し、確認結果に応じて新規にログイン可能なユーザ数を算出して、算出したユーザ数分のトークンを発行する。

クライアント端末３００上のＷｅｂブラウザ等を利用してユーザがＷｅｂサーバにログイン要求を行った場合、トークン発行元Ｗｅｂサーバ１００では使用可能なトークンがあるか否かを確認する。使用可能なトークンがある場合（トークン発行元Ｗｅｂサーバ１００ａの場合）は、トークンを１つ使用して、ユーザＩＤやパスワードの確認などの実際の認証処理を行う。認証が許可されてセッションが生成された場合は当該トークンを使用済みとする。

なお、ここでのトークンの使用とは、単にユーザからのログイン要求に対して実際の認証処理に進むための許可証としての使用（消費）であり、正当なトークンを使用しているか否かのみによって認証全体の許否を決定するために使用するというものではない。

使用可能なトークンがない場合（トークン発行元Ｗｅｂサーバ１００ｂの場合）は、ログイン要求は拒否される。これにより、予め発行されたトークンの数を超えるユーザは新たにログインできないように制限され、システムが高負荷になったことを検知してから流量制限を行うのと比較してより確実な流量制限を行うことができる。なお、このときは、例えば従来技術で示したような、ユーザによるアクセスの大量のリトライを防止するための対応を別途行うのが望ましい。

発行されたトークンは、ログイン要求を行うユーザの属性に対して自由に割り当てることができる。例えば、２０個のトークンが発行された場合、そのうちの３つは「管理者」用に割り当てて確保しておき、残りの１７個のトークンは「一般ユーザ」に割り当てるということが可能である。これにより、例えば、１７人以上の「一般ユーザ」がアクセスしてきて「一般ユーザ」については流量制限が行われている状況であっても、最低３人の「管理者」についてはログイン可能とするといった制御を行うことができる。

また、トークン自身に予め種別を設けておき、使用されたトークンの種別に応じてログイン制御の内容を変えるようにしてもよい。例えば、トークン発行元Ｗｅｂサーバ１００に対してログインして実行する（もしくはできる）処理の内容に応じてトークンの種別を分ける。処理内容が異なればトークン発行元Ｗｅｂサーバ１００での処理負荷も異なるため、その内容に応じてログイン制御を変えることができる。ログイン制御としては、例えば、使用されたトークンの種別に応じてログインの優先順位を変えたり、ログインセッション数が多くなった場合のログインの可否を変えたり、特定の種別のトークンを使用した場合にのみアクセス可能なサイトへの入口を提供したりなどが考えられる。

なお、トークンは、ログイン要求に対して認証処理を行うために使用された場合は、使用済みとなり消費されるが、これ以外にもトークンの発行時に各トークンに有効期限を設定しておき、有効期限が経過したトークンについては期限切れとして使用不可にすることもできる。使用済みや期限切れとなったトークンを適宜削除することにより、定期的なシステムの負荷状況の確認およびトークンの発行処理と合わせて、トークンの発行状況を最新のシステムの負荷状況に追従させることができる。

一方、上記のような手順によりアクセスの流量制限を行った場合であっても、近年では、Ｗｅｂサーバ間はＳＳＯにより連携している場合もある。ＳＳＯでは、信頼できるＷｅｂサーバにおける既にログイン済みのユーザの認証情報を他のＷｅｂサーバに受け渡し、他のＷｅｂサーバでは当該認証情報に基づいて、ユーザによる新たなログイン認証を行わずにセッションを生成する。このＷｅｂサーバ間での認証情報の受け渡しには、認証Ｃｏｏｋｉｅを利用する手法や、ＳＡＭＬ（Security Assertion Markup Language）を利用して属性情報やアクセス制御情報をＷｅｂサーバ間で伝達する手法などがある。

これらの場合、上述したように、ＳＳＯでのアクセス先となるＷｅｂサーバでは新たなログイン認証を行わずにセッションが生成される。従って、当該Ｗｅｂサーバでは、従来技術や上記のような手順によるアクセスの流量制限の手法では、通常のログインに加えてＳＳＯも考慮した上で新たなセッションの生成を一括して抑止するということは難しい。

そこで、本実施の形態のＷｅｂサーバシステムへのログイン制御方法では、Ｗｅｂサーバは、図２に示したトークン発行元Ｗｅｂサーバ１００自身に対するトークンの発行に加えて、ＳＳＯにより連携してくる外部のＷｅｂサーバに対しても同様にトークンを発行する。これにより、ＳＳＯによりアクセスしてくる他のＷｅｂサーバに対してもログイン制御を行うことができる。

図１は、本発明の一実施の形態であるＷｅｂサーバシステムへのログイン制御方法のＳＳＯ環境の場合の例について概要を示した図である。トークン発行元Ｗｅｂサーバ１００は、トークンの発行元であり、ＳＳＯにおいてターゲットとなるＷｅｂサーバである。トークン使用Ｗｅｂサーバ２００（２００ａ、２００ｂ）は、ポータルサイト等を提供し、トークンの配布先であり、トークン発行元Ｗｅｂサーバ１００が信頼するＷｅｂサーバであってＳＳＯにおいてソースとなるＷｅｂサーバである。

トークン発行元Ｗｅｂサーバ１００は、上記と同様に、定期的にシステムの負荷状況を確認してトークンを発行し、トークン使用Ｗｅｂサーバ２００に対して、発行したトークンを予め配布している。トークン使用Ｗｅｂサーバ２００は、それぞれクライアント端末３００を利用したユーザからのログイン要求に対して個別に認証処理を行い、セッションを確立している。この認証結果の情報に基づいて、トークン使用Ｗｅｂサーバ２００は、それぞれ、ＳＳＯにより連携してトークン発行元Ｗｅｂサーバ１００に当該ユーザのセッションを生成しようとする。このとき、トークン使用Ｗｅｂサーバ２００では、上記と同様にトークン発行元Ｗｅｂサーバ１００から発行された使用可能なトークンがあるか否かを確認する。

使用可能なトークンがある場合（トークン使用Ｗｅｂサーバ２００ａの場合）は、トークンを１つ使用（消費）して、ＳＳＯによりトークン発行元Ｗｅｂサーバ１００と連携する。使用可能なトークンがない場合（トークン使用Ｗｅｂサーバ２００ｂの場合）は、ＳＳＯによるトークン発行元Ｗｅｂサーバ１００へのアクセスは行われない。これにより、トークン発行元Ｗｅｂサーバ１００では、ＳＳＯによるアクセスも含めて、予め発行されたトークンの数を超えるユーザはログイン（セッション生成）できないように制限され、確実な流量制限を行うことができる。

また、トークン発行元Ｗｅｂサーバ１００では、外部の各トークン使用Ｗｅｂサーバ２００へのトークンの配布のパターンを適宜柔軟に変更することができる。例えば、複数のトークン使用Ｗｅｂサーバ２００に対して配布するトークンの数をＷｅｂサイトの重要度などに応じて按分したり、特定のトークン使用Ｗｅｂサーバ２００については優先的に必ず一定数のトークンを配布するようにしたりなど、種々のパターンが考えられる。

［システム構成］
図３は、本実施の形態のＷｅｂサーバシステムへのログイン制御方法を実装するＷｅｂシステムの構成例の概要を示した図である。図３において、Ｗｅｂシステムは例えば、インターネット等のネットワーク４００に、それぞれ１つ以上のトークン発行元Ｗｅｂサーバ１００、トークン使用Ｗｅｂサーバ２００、およびクライアント端末３００が接続される構成となっている。ここで、クライアント端末３００は、Ｗｅｂサーバにアクセス可能なＷｅｂブラウザ等のソフトウェアを有するＰＣ等の端末機器である。

図３の構成において、トークン使用Ｗｅｂサーバ２００は、トークン発行元Ｗｅｂサーバ１００にとって信頼できるＷｅｂサーバであり、トークン発行元Ｗｅｂサーバ１００では、ＳＳＯによりトークン使用Ｗｅｂサーバ２００でのユーザの認証情報を用いてログインによる認証を要さずにセッションを生成することができる。

トークン発行元Ｗｅｂサーバ１００は、クライアント端末３００に対してＷｅｂサーバとして動作するサーバ機器であり例えば、Ｗｅｂサーバプログラム１２０、認証部１３０、ＳＳＯ連携部１４０、アプリケーションプログラム１５０、トークン管理部１６０、および状態確認部１７０の各部を有する構成となっている。また、データベースやファイル等の形式で、ユーザ１１１、セッション１１２、トークン１１３、トークン管理１１４、および配布ルール１１５の各データを保持する。

また、トークン使用Ｗｅｂサーバ２００は、同様に、クライアント端末３００に対してＷｅｂサーバとして動作するサーバ機器であり、例えば、Ｗｅｂサーバプログラム２２０、認証部２３０、ＳＳＯ連携部２４０、アプリケーションプログラム２５０、およびトークン管理部２６０の各部を有する構成となっている。また、データベースやファイル等の形式で、ユーザ２１１、セッション２１２、およびトークン２１３の各データを保持する。

トークン発行元Ｗｅｂサーバ１００およびトークン使用Ｗｅｂサーバ２００におけるＷｅｂサーバプログラム１２０および２２０は、サーバ機器等をＷｅｂサーバとして機能させる一般に市販等されているソフトウェアである。

認証部１３０および２３０は、それぞれＷｅｂサーバプログラム１２０、２２０上で動作し、ユーザからクライアント端末３００上のＷｅｂブラウザ等を利用して送信されたログイン要求に対して、それぞれユーザ１１１、２１１に保持されたユーザＩＤやパスワード等の情報を用いて認証処理を行うソフトウェアプログラムである。このとき、認証部１３０、２３０では、それぞれ、後述するトークン管理部１６０、２６０によって自らが発行した使用可能なトークンがあるか否かを確認し、使用可能なトークンがある場合にのみ認証処理を行う。認証に成功した場合は、Ｗｅｂサーバプログラム１２０、２２０によりそれぞれセッション１１２、２１２に当該セッションの内容を保持する情報が生成される。

ＳＳＯ連携部１４０および２４０は、それぞれ外部のＷｅｂサーバと連携してＳＳＯを実現するソフトウェアプログラムやモジュールである。ここでは、例えば上述したＳＡＭＬプロトコルを処理することによりＳＳＯを実現する。図３の例では、トークン発行元Ｗｅｂサーバ１００のＳＳＯ連携部１４０とトークン使用Ｗｅｂサーバ２００のＳＳＯ連携部２４０とがＳＡＭＬ等を利用して連携することでＳＳＯによる認証を行う。

このとき、トークン使用Ｗｅｂサーバ２００のＳＳＯ連携部２４０では、後述するトークン管理部２６０によってトークン発行元Ｗｅｂサーバ１００から配布された使用可能なトークンがあるか否かを確認し、使用可能なトークンがある場合にのみトークン発行元Ｗｅｂサーバ１００との間でのＳＳＯによる認証を行う。トークン発行元Ｗｅｂサーバ１００においてＳＳＯによる認証が行われることにより、トークン使用Ｗｅｂサーバ２００でのユーザの認証情報を用いてトークン発行元Ｗｅｂサーバ１００上にセッション１１２を生成することができる。なお、トークン発行元Ｗｅｂサーバ１００は、他の信頼するＷｅｂサーバとの間で同様にＳＳＯによる認証を介してセッションを生成することができる。

アプリケーションプログラム１５０および２５０は、それぞれＷｅｂサーバプログラム１２０、２２０上で動作し、固有の業務処理を実行してサービスを提供するソフトウェアプログラムである。

トークン管理部１６０および２６０は、トークン発行元Ｗｅｂサーバ１００によって発行され配布されたトークンをそれぞれトークン１１３、２１３に保持し、使用状況について管理するソフトウェアプログラムである。また、トークン発行元Ｗｅｂサーバ１００のトークン管理部１６０は、後述する状態確認部１７０によって定期的にシステムの負荷状況を確認し、負荷状況およびセッション１１２に保持されている現在のセッション数などに基づいて、所定のルールにより自サーバ（トークン発行元Ｗｅｂサーバ１００）にログイン（ＳＳＯによるもの含む）可能な最大のユーザ数を算出して、算出したユーザ数分のトークンを発行する。

また、トークン管理部１６０は、発行したトークンをトークン管理１１４に保持して管理する。トークンの発行の際に、トークン管理１１４に発行済みで未使用のトークンが残っている場合はその分を考慮して発行する。さらに、発行したトークンを配布ルール１１５に設定されたルールに従って各Ｗｅｂサーバに配布する。トークンの配布に際しては、例えば、ＳＯＡＰ（Simple Object Access Protocol）などを利用することができる。

状態確認部１７０は、トークン発行元Ｗｅｂサーバ１００の負荷状況を定期的に確認するソフトウェアプログラムである。システムの負荷状況としては、例えば、ＣＰＵやメモリ等の各種ハードウェア資源の使用率やネットワーク負荷、各所での応答時間、ログインセッション数などがある。負荷状況の取得には、例えばＯＳが提供するコマンドや、パフォーマンス監視プログラム等の出力結果などを利用することができる。

［データ構造］
図４は、本実施の形態におけるトークン管理１１４のデータ構造およびデータの例を示した図である。トークン管理１１４は、例えば、発行トークンＩＤ１１４−１、有効期限１１４−２、配布先１１４−３、種別１１４−４、ステータス１１４−５の各項目を有し、トークン発行元Ｗｅｂサーバ１００のトークン管理部１６０が発行したトークンを保持する。発行された各トークンには識別のためのトークンＩＤが付与され、発行トークンＩＤ１１４−１に格納される。

また、各トークンには有効期限を設定してもよく、設定された値は有効期限１１４−２に格納される。有効期限を経過したトークンは期限切れのため使用不可として取り扱うことができ、期限切れのトークンは、トークン管理部１６０によって新たなトークンを発行する際などの所定のタイミングでトークン管理１１４から削除してもよい。配布先１１４−３には、対象のトークンを配布する（した）先のＷｅｂサーバ（トークン発行元Ｗｅｂサーバ１００もしくはトークン使用Ｗｅｂサーバ２００）を識別する情報（ホスト名やＩＰアドレス、ＵＲＬ等）が格納される。

また、各トークンには、使用されたトークンの種別に応じてログイン制御の内容を変えることができるように種別を設定しておいてもよい。図４の例では、各トークンに例えば「青」や「赤」、「黄」などの色を設定し、「青」のトークンを使用してアクセスしてきた場合は、ログインの優先順位を高くしたり、ログインセッション数が多くなった場合でもログインできるようにしたり、「青」のトークンを使用した場合しかアクセスできない入口を提供したりなどが考えられる。ここで、トークンに設定する色は、例えば、トークン発行元Ｗｅｂサーバ１００にアクセスした後に実行する処理内容によって分けることができる。

ステータス１１４−５には、対象のトークンの状態を示す値が格納される。例えば、発行直後の初期状態を「未使用」としておき、当該トークンが使用された場合に「使用済み」とすることで、使用可能なトークンを識別することができる。また、有効期限１１４−２の値を経過したトークンについてステータス１１４−５の値を「期限切れ」などの値に設定するようにしてもよい。なお、トークンが使用された際や、有効期限を経過したことを検知した際に、ステータス１１４−５の値を「使用済み」や「期限切れ」としてトークン管理１１４に残しておくのではなく、その時点でトークン管理１１４から当該トークンを削除するようにしてもよい。この場合ステータス１１４−５の項目は不要である。

なお、本実施の形態では、トークン毎にトークン管理１１４にエントリを有する構成としているが、トークンの発行数が多くなる場合はエントリ数も多くなってしまう。この場合、通常は、有効期限１１４−２や配布先１１４−３、種別１１４−４が同じであるトークンが多数発行されるものと考えられる。

従って、トークンの配布先の各Ｗｅｂサーバで、例えば、トークンＩＤの小さいものから順にシーケンシャルにトークンを使用するようなルールとすることで、有効期限１１４−２や配布先１１４−３、種別１１４−４が同じである複数のトークンについて、発行トークンＩＤ１１４−１を「ＸＸ００００１〜ＸＸ０１０００」というようにトークンＩＤの範囲で指定することができる。トークンＩＤの範囲における最新の使用済みのトークンＩＤを別途管理することで、上記と同様のトークンの管理を実現しつつ保持するデータ量を削減することが可能である。

図５は、本実施の形態におけるトークン１１３およびトークン２１３のデータ構造およびデータの例を示した図である。トークン１１３とトークン２１３は同様であり、例えば、トークンＩＤ１１３−１、有効期限１１３−２、配布元１１３−３、種別１１３−４、使用可能ユーザ１１３−５、ステータス１１３−６の各項目を有し、トークン発行元Ｗｅｂサーバ１００から発行・配布されたトークンを保持する。

トークンＩＤ１１３−１および有効期限１１３−２には、トークン発行元Ｗｅｂサーバ１００によって当該トークンに付与されたトークンＩＤおよび設定された有効期限の値が格納される。配布元１１３−３には、当該トークンを発行・配布したトークン発行元Ｗｅｂサーバ１００を識別する情報（ホスト名やＩＰアドレス、ＵＲＬ等）が格納される。

種別１１３−４には、配布元のサーバにおいて当該トークンに対して設定された種別（色）の値が格納される。使用可能ユーザ１１３−５には、当該トークンを配布されたＷｅｂサーバ（トークン発行元Ｗｅｂサーバ１００もしくはトークン使用Ｗｅｂサーバ２００）のトークン管理部１６０、２６０によって設定された、当該トークンを使用可能なユーザの属性の値が格納される。設定する属性の内容は、例えば、「一般ユーザ」や「プレミアユーザ」、「管理者」などである。

使用可能ユーザ１１３−５にどのような属性を設定して各トークンに割り当てるかの決定は、当該トークンを配布されたＷｅｂサーバが独自のルールに基づいて自由に行うことができる。使用可能ユーザ１１３−５に値を設定せず、当該トークンを使用可能なユーザの属性等を特に制限しないことも可能である。ステータス１１３−６は、図４のステータス１１４−５と同様であり、対象のトークンの状態を示す値が格納される。

図６は、本実施の形態における配布ルール１１５のデータ構造およびデータの例を示した図である。配布ルール１１５は、例えば、配布先１１５−１、配布比率：青１１５−２、配布比率：赤１１５−３の各構造を有し、トークン発行元Ｗｅｂサーバ１００のトークン管理部１６０が、発行したトークンを各Ｗｅｂサーバに配布する際の割り振りのルールに関する設定情報を保持する。

配布先１１５−１には、トークンの配布先となる各Ｗｅｂサーバを識別する情報（ホスト名やＩＰアドレス、ＵＲＬ等）が格納される。また、配布比率：青１１５−２および配布比率：赤１１５−３には、トークンを配布する際のルールの情報が格納される。図６では、発行したトークンの種別（「青」「赤」）に応じて各Ｗｅｂサーバにトークンを按分して配布する際の割合を格納する場合の例を示しているが、トークンを配布する際のルールの内容によってこれらの項目の内容は異なり得る。

例えば、各Ｗｅｂサーバにトークンを按分して配布するのではなく、各Ｗｅｂサーバ間での優先順位に基づいて、優先順位の高いＷｅｂサーバから順に可能な分だけトークンを配布する方式をとる場合には、各Ｗｅｂサーバ毎の最大配布数や優先順位の情報などを保持する項目を配布ルール１１５に有することになる。

なお、按分する比率や優先順位などの値は、管理者等が適宜変更することが可能であり、また、トークンの使用状況の実績等に基づいてトークン管理部１６０により統計的に決定してもよい。また、発行した全てのトークンを各Ｗｅｂサーバに配布せずに、後述するように各Ｗｅｂサーバでのトークンの使用状況等に応じて追加で配布できるように一部予備として残しておくようにしてもよい。

［処理シーケンス］
以降では、本実施の形態のＷｅｂサーバシステムへのログイン制御方法における各処理の具体的な内容とその流れについて説明する。図７は、本実施の形態のＷｅｂサーバシステムへのログイン制御方法におけるトークンの発行および配布の処理の例を示したシーケンス図である。この一連の処理は、トークン発行元Ｗｅｂサーバ１００のトークン管理部１６０において所定の時間間隔を計数し、これをトリガに定期的に実行される。

まず、トークン発行元Ｗｅｂサーバ１００では、トークン管理部１６０が、状態確認部１７０によりトークン発行元Ｗｅｂサーバ１００のシステムの状態（負荷状況）を確認する（Ｓ７０１）。次に、トークン管理部１６０が、ステップＳ７０１で取得したシステムの負荷状況に基づいて所定の算出ルールに基づいてトークン発行元Ｗｅｂサーバ１００にログイン可能なユーザ数（生成可能なセッション数）を算出し、さらに、セッション１１２に保持している情報から取得した現在のログインセッション数も考慮して、新たにログイン可能なユーザ数を算出する（Ｓ７０２）。

さらに、トークン管理１１４を参照して現在発行済みで使用可能なトークンがの残数を確認する（Ｓ７０３）。その後、ステップＳ７０２で算出した新たにログイン可能なユーザ数と、ステップＳ７０３で取得したトークンの残数との差分に基づいて新たに発行するトークンの数を算出し、その分のトークンを発行する（Ｓ７０４）。発行したトークンの情報はトークン管理１１４に格納する。なお、図７に示す一連の処理を定期的に実行する時間間隔と、トークンに設定する有効期限までの時間間隔とを合わせることにより、ステップＳ７０４でのトークンの発行の際に未使用で残っているトークンを実用上なくすことができる。この場合、ステップＳ７０３の処理を不要とすることも可能である。

次に、トークン管理部１６０は、発行したトークンを配布ルール１１５の設定内容に基づいて各Ｗｅｂサーバ（トークン発行元Ｗｅｂサーバ１００、トークン使用Ｗｅｂサーバ２００）に対してＳＯＡＰ等により配布する（Ｓ７０５）。トークンを配布された各Ｗｅｂサーバでは、トークン管理部１６０もしくは２６０が、各Ｗｅｂサーバでの個別のルールに基づいて、配布されたトークンをユーザの属性に対して割り当て（Ｓ７０６）、トークン１１３もしくは２１３に格納して登録する（Ｓ７０７）。なお、このとき、上述したように、トークン１１３もしくは２１３においてステータス１１３−６が「使用済み」もしくは「期限切れ」など使用不可のステータスで残っているトークンについて削除する処理を行ってもよい。

以上の処理を定期的に繰り返すことで、トークン発行元Ｗｅｂサーバ１００の現在のシステムの状態に応じて、予め、新たにログイン要求（ＳＳＯを含む）を受け付けるための許可証であるトークンを適当な数だけ発行しておくことができる。

図８は、本実施の形態のＷｅｂサーバシステムへのログイン制御方法におけるトークン発行元のＷｅｂサーバでの（ＳＳＯではない通常の）ログイン要求時の処理の例を示したシーケンス図である。まず、ユーザは、クライアント端末３００を利用して、トークン発行元Ｗｅｂサーバ１００に対してログイン要求を送信する（Ｓ８０１）。

トークン発行元Ｗｅｂサーバ１００では、Ｗｅｂサーバプログラム１２０を介してログイン要求を受けた認証部１３０が、トークン管理部１６０により、対象のユーザの属性に合致する使用可能なトークンがトークン１１３にあるか否かを確認し、使用可能なトークンがある場合は、その中から、トークンＩＤ１１３−１が最も小さいものを選択するなどのルールに基づいて、使用するトークンを１つ選択する（Ｓ８０２）。

使用可能なトークンがない場合は、ログインによるアクセスを拒否する応答をクライアント端末３００に送信し（Ｓ８０３）、処理を終了する。すなわち、トークン発行元Ｗｅｂサーバ１００にてログイン処理は行われない。このとき、以降のユーザによるログイン要求のリトライを防止するため、例えば「混雑のためあなたのＩＤはしばらくログインできません」等の画面を表示するなどの対策をとることが望ましい。

ステップＳ８０２で使用可能なトークンがある場合は、トークン管理部１６０は、選択されたトークンのトークンＩＤがトークン管理１１４の発行トークンＩＤ１１４−１に存在するか否かを確認することで、トークンの正当性を確認する（Ｓ８０４）。トークンが正当である場合、認証部１３０は、ユーザ１１１の情報に基づいて通常の認証処理を行う（Ｓ８０５）。認証が成功した場合は、Ｗｅｂサーバプログラム１２０はセッション１１２にセッションを生成してログイン許可の応答をクライアント端末３００に送信し（Ｓ８０６）、トークン管理部１６０は、選択されたトークンについてトークン１１３のステータス１１３−６を「使用済み」に更新する（Ｓ８０７）。

その後は、クライアント端末３００とトークン発行元Ｗｅｂサーバ１００との間で通常のアクセス（アクセス要求（Ｓ８０８）およびアクセス応答（Ｓ８０９））が行われ、アプリケーションプログラム１５０での処理によるサービスがユーザに提供される。

図９は、本実施の形態のＷｅｂサーバシステムへのログイン制御方法におけるトークン発行元のＷｅｂサーバに対するＳＳＯによるアクセス要求時の処理の例を示したシーケンス図である。図９では、トークン使用Ｗｅｂサーバ２００において認証を行いログインしているユーザが、ＳＳＯによりトークン発行元Ｗｅｂサーバ１００に対してログイン認証を行わずにアクセスする場合の例を示している。

なお、図９では、ＳＡＭＬによりＳＳＯを実現する場合の例を示しており、ＳＡＭＬを利用したＳＳＯにおけるいわゆるＰｕｌｌモデル（アクセス要求を受けたトークン発行元Ｗｅｂサーバ１００がトークン使用Ｗｅｂサーバ２００に対して認証情報を要求する）の場合の例を示しているが、Ｐｕｓｈモデル（トークン使用Ｗｅｂサーバ２００がアクセスが予定されるトークン発行元Ｗｅｂサーバ１００にアクセス認証の情報を事前に伝える）の場合や、その他のＷｅｂサーバ間でのいわゆるＩＤの連携（フェデレーション）によってＳＳＯを実現する手法であってもよい。

ユーザは事前に、トークン使用Ｗｅｂサーバ２００に対してクライアント端末３００を利用して通常のログイン処理を行っているものとする（Ｓ９０１〜Ｓ９０３）。その後、ユーザが、クライアント端末３００を利用して、トークン発行元Ｗｅｂサーバ１００にアクセスするため、トークン使用Ｗｅｂサーバ２００のＷｅｂページ上で提供されている、ＳＳＯを考慮したトークン発行元Ｗｅｂサーバ１００へのリンクを選択する等により、トークン使用Ｗｅｂサーバ２００に対してトークン発行元Ｗｅｂサーバ１００へのリンク要求を送信する（Ｓ９０４）。

トークン使用Ｗｅｂサーバ２００では、Ｗｅｂサーバプログラム２２０を介してリンク要求を受けたＳＳＯ連携部２４０が、トークン管理部２６０により、トークン発行元Ｗｅｂサーバ１００から配布された、対象のユーザ属性に合致する使用可能なトークンがトークン２１３にあるか否かを確認し、使用可能なトークンがある場合は、その中から、トークンＩＤ１１３−１が最も小さいものを選択するなどのルールに基づいて、使用するトークンを１つ選択する（Ｓ９０５）。

使用可能なトークンがない場合は、トークン発行元Ｗｅｂサーバ１００に対するアクセスを拒否する応答をクライアント端末３００に送信し（Ｓ９０６）、処理を終了する。すなわち、トークン使用Ｗｅｂサーバ２００からトークン発行元Ｗｅｂサーバ１００に対するＳＳＯ（ＩＤの連携）のためのアクセスは行われない。このとき、図８の例と同様に、以降のユーザによるリンク要求のリトライを防止するため、例えば「混雑のためあなたのＩＤはしばらくログインできません」等の画面を表示するなどの対策をとることが望ましい。

ステップＳ９０５で使用可能なトークンがある場合は、以下の処理によって、ＳＳＯによるトークン発行元Ｗｅｂサーバ１００での認証（セッションの生成）を行う。まず、トークン使用Ｗｅｂサーバ２００のＳＳＯ連携部２４０は、自サーバに対する認証情報の参照先の情報（アーティファクト）を生成して保存し（Ｓ９０７）、認証情報参照先を含む応答をクライアント端末３００に送信する（Ｓ９０８）。応答を受信したクライアント端末３００のＷｅｂブラウザは、応答をリダイレクトしてアクセス要求をトークン発行元Ｗｅｂサーバ１００に対して送信する（Ｓ９０９）。

アクセス要求を受けたトークン発行元Ｗｅｂサーバ１００のＳＳＯ連携部１４０は、ＳＡＭＬにより認証情報参照先（アーティファクト）をトークン使用Ｗｅｂサーバ２００に提示して認証情報を要求する（Ｓ９１０）。トークン使用Ｗｅｂサーバ２００のＳＳＯ連携部２４０は、認証情報参照先に基づいて認証情報を取得し（Ｓ９１１）、認証情報にステップＳ９０５で選択したトークンを付加してＳＡＭＬによりトークン発行元Ｗｅｂサーバ１００に応答する（Ｓ９１２）。また、トークン管理部２６０により、選択したトークンについてトークン２１３のステータス１１３−６を「使用済み」に更新する（Ｓ９１３）。

一方、トークン発行元Ｗｅｂサーバ１００のトークン管理部１６０は、トークン使用Ｗｅｂサーバ２００から送信されたトークンのトークンＩＤがトークン管理１１４の発行トークンＩＤ１１４−１に存在するか否かを確認することで、トークンの正当性を確認する（Ｓ９１４）。なお、このようなトークンの正当性の確認手法以外にも、例えば、トークンに対してトークン発行元Ｗｅｂサーバ１００やトークン使用Ｗｅｂサーバ２００において電子署名を行って送受信することによりトークンの正当性を確認するということも可能である。

ステップＳ９１４でトークンが正当である場合、ＳＳＯ連携部１４０は、トークン使用Ｗｅｂサーバ２００から送信された認証情報、およびユーザ１１１の情報等に基づいてセッション１１２に対象のユーザのセッションを生成し（Ｓ９１５）、アクセス許可の応答をクライアント端末３００に送信する（Ｓ９１６）。その後は、クライアント端末３００とトークン発行元Ｗｅｂサーバ１００との間で通常のアクセス（アクセス要求（Ｓ９１７）およびアクセス応答（Ｓ９１８））が行われ、アプリケーションプログラム１５０での処理によるサービスがユーザに提供される。

図８および図９の例に示すように、ステップＳ８０２およびＳ９０５で使用可能なトークンがない場合は、ステップＳ８０３およびＳ９０６でいずれもアクセス拒否の応答を送信することで、トークン発行元Ｗｅｂサーバ１００に対する無用なログイン処理およびＳＳＯのためのアクセスを抑止し、トークン発行元Ｗｅｂサーバ１００での無用な負荷の増大を回避しつつ確実な流量制限を行うことが可能となる。

ここで、上記のように例えば、あるトークン使用Ｗｅｂサーバ２００において多数のユーザからのアクセスがあり、ＳＳＯによるトークン発行元Ｗｅｂサーバ１００へのアクセスも多く行われた結果、トークン発行元Ｗｅｂサーバ１００から配布されたトークンがなくなり、図９の例に示すように流量制限が行われるような場合であっても、他のトークン使用Ｗｅｂサーバ２００ではユーザ数が少なく、トークン発行元Ｗｅｂサーバ１００から配布されたトークンに余剰があるという場合が生じ得る。

このように、トークン発行元Ｗｅｂサーバ１００のキャパシティに対して使用されないトークンが残るという状況を回避するため、例えば、トークン発行元Ｗｅｂサーバ１００がトークンを発行・配布する際に、算出したログイン可能なユーザ数よりも多めのトークンを発行・配布しておくということも可能である。ただしこの場合は、複数のトークン使用Ｗｅｂサーバ２００によって、トークン発行元Ｗｅｂサーバ１００に対してログイン可能なユーザ数よりも多いログイン要求もしくはアクセス要求が送信される場合が生じ得る。従って、トークン発行元Ｗｅｂサーバ１００が、ログイン要求やアクセス要求を受けた際に、ログイン可能なユーザ数および現在のセッション数等に基づいて、対象のログイン要求もしくはアクセス要求の処理が可能か否かを判断する処理が必要となる。

また、別の手法として、例えば、トークン発行元Ｗｅｂサーバ１００においてログイン可能なユーザ数の分だけ発行されたトークンの配布を受けるＷｅｂサーバ（トークン発行元Ｗｅｂサーバ１００およびトークン使用Ｗｅｂサーバ２００）間で、余剰のトークンを直接的・間接的に融通するような手法をとることも可能である。

このような例として、図１０は、本実施の形態のＷｅｂサーバシステムへのログイン制御方法における使用可能なトークンがない場合の処理の例を示したシーケンス図である。ここでは、トークン使用Ｗｅｂサーバ２００において、トークン発行元Ｗｅｂサーバ１００から配布されたトークンに残余がない場合に、トークン発行元Ｗｅｂサーバ１００を介して間接的に他のＷｅｂサーバから余剰のトークンを譲り受ける場合の例を示している。

図９の例におけるステップＳ９０４およびＳ９０５と同様に、ユーザが、クライアント端末３００を利用して、トークン使用Ｗｅｂサーバ２００のＷｅｂページ上で提供されている、ＳＳＯを考慮したトークン発行元Ｗｅｂサーバ１００へのリンクを選択する等により、トークン使用Ｗｅｂサーバ２００に対してトークン発行元Ｗｅｂサーバ１００へのリンク要求を送信する（Ｓ１００１）。トークン使用Ｗｅｂサーバ２００では、Ｗｅｂサーバプログラム２２０を介してリンク要求を受けたＳＳＯ連携部２４０が、トークン管理部２６０により、トークン発行元Ｗｅｂサーバ１００から配布された、対象のユーザ属性に合致する使用可能なトークンがトークン２１３にあるか否かを確認する（Ｓ１００２）。

ステップＳ１００２で使用可能なトークンがない場合は、トークン管理部２６０によりトークン発行元Ｗｅｂサーバ１００に対してＳＯＡＰ等を利用してトークンの追加要求を行う（Ｓ１００３）。追加要求を受信したトークン発行元Ｗｅｂサーバ１００のトークン管理部１６０は、トークン管理１１４を参照して、予備として未配布となっているトークンの残数を確認する（Ｓ１００４）。

ここで未配布のトークンの残数がない場合は、トークンの配布先である各Ｗｅｂサーバに対して余剰分の回収処理を行う（Ｓ１００５）。ここでは、実際に対象のＷｅｂサーバに対して回収指示を送信し、各Ｗｅｂサーバにて余剰分のトークンをトークン発行元Ｗｅｂサーバ１００に応答した後、対象のトークンをトークン２１３から削除するという処理を行ってもよい。

また、トークン発行元Ｗｅｂサーバ１００においてトークン管理１１４−１の配布先１１４−３の情報をトークンの追加要求を行った（トークンを必要とする）トークン使用Ｗｅｂサーバ２００の情報に強制的に更新して回収するという処理を行ってもよい。なお、この場合は、当初の配布先のＷｅｂサーバにおいて保持するトークンが削除されずに残るため、当該トークンを使用したアクセス要求が行われる場合も生じ得るが、トークンの正当性の確認（Ｓ８０４、Ｓ９１４）において正当なトークンを使用していないとしてアクセスを拒否することが可能である。

上述したようなトークンの回収処理は、トークン発行元Ｗｅｂサーバ１００において、例えば、システム障害に伴う片系運用など、通常運用時と比較してシステムのキャパシティが低下し、ログイン可能なユーザ数が大きく減少するような場合に、既に発行・配布済みのトークンを回収するという用途に用いることも可能である。

次に、回収したトークン、もしくは予備として未配布となっているトークンから必要な分を追加トークンとして対象のトークン使用Ｗｅｂサーバ２００に配布する（Ｓ１００６）。追加トークンとして配布できるトークンがない場合は拒否応答を送信する。なお、この追加トークンの配布処理をトークン使用Ｗｅｂサーバ２００からの追加要求をトリガとして行うのではなく、トークン発行元Ｗｅｂサーバ１００のトークン管理部１６０がトークン管理１１４を定期的に参照して各Ｗｅｂサーバのトークンの使用状況を確認し、使用率の高いＷｅｂサーバに対して能動的に追加トークンを配布するようにしてもよい。また、トークンの追加要求を、トークン発行元Ｗｅｂサーバ１００に対してではなく他のトークン使用Ｗｅｂサーバ２００に対して直接行うようにしてもよい。

追加トークンの配布を受けたトークン使用Ｗｅｂサーバ２００では、配布された追加トークンに対して図７の例におけるステップＳ７０６およびＳ７０７と同様に、ユーザの属性に対する割り当て（Ｓ１００７）と、トークン１１３、２１３への登録（Ｓ１００８）の処理を行う。以上の処理により、トークンが不足しているＷｅｂサーバが、トークンが余剰である他のＷｅｂサーバ等からトークンの融通を受けられるようにすることで、トークンの配布状況を最適化することが可能となる。

以上に説明したように、本実施の形態のＷｅｂサーバシステムへのログイン制御方法によれば、Ｗｅｂサーバシステムの負荷状況に応じて予め設定されたログイン可能なユーザ数に対応して、ログイン要求を処理するためのトークンを発行するため、予め発行されたトークンの数に対応したユーザのログインを可能とするとともに、使用可能なトークンがない場合はログイン要求を抑止することで、Ｗｅｂサーバシステムに無用な負荷をかけることなく確実な流量制限を行うことが可能となる。

また、発行されたトークンをユーザの属性等に応じて割り当てておくことで、他の属性のユーザ（例えば「一般ユーザ」）に割り当てられたトークンがなくなり流量制限が行われている場合であっても、特定のユーザ（例えば「管理者」や「プレミアムユーザ」など）のログインを確保することが可能となる。

さらに、本実施の形態のＷｅｂサーバシステムへのログイン制御方法によれば、Ｗｅｂサーバは、自サーバに対するトークンの発行に加えて、ＳＳＯにより連携してくる外部のＷｅｂサーバに対しても同様にトークンを発行・配布する。従って、通常のログイン処理に加えて、ＳＳＯによるアクセスも考慮した上で一括したログイン制御を行うことが可能であり、Ｗｅｂサーバシステムが高負荷の際に無用なログイン要求やＳＳＯのためのアクセス要求の発生を抑止し、Ｗｅｂサーバシステムに無用な負荷をかけることなく確実な流量制限を行うことが可能となる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

本発明は、システムの負荷の状況に応じてユーザのログイン可能数を制限してアクセスの流量制限を行うＷｅｂサーバシステムへのログイン制限方法に利用可能である。

１００、１００ａ、１００ｂ…トークン発行元Ｗｅｂサーバ、
１１１…ユーザ、１１２…セッション、１１３…トークン、１１３−１…トークンＩＤ、１１３−２…有効期限、１１３−３…配布元、１１３−４…種別、１１３−５…使用可能ユーザ、１１３−６…ステータス、１１４…トークン管理、１１４−１…発行トークンＩＤ、１１４−２…有効期限、１１４−３…配布先、１１４−４…種別、１１４−５…ステータス、１１５…配布ルール、１１５−１…配布先、１１５−２…配布比率：青、１１５−３…配布比率：赤、
１２０…Ｗｅｂサーバプログラム、１３０…認証部、１４０…ＳＳＯ連携部、１５０…アプリケーションプログラム、１６０…トークン管理部、１７０…状態確認部、
２００、２００ａ、２００ｂ…トークン使用Ｗｅｂサーバ、２１１…ユーザ、２１２…セッション、２１３…トークン、２２０…Ｗｅｂサーバプログラム、２３０…認証部、２４０…ＳＳＯ連携部、２５０…アプリケーションプログラム、２６０…トークン管理部、
３００…クライアント端末、
４００…ネットワーク。

Claims (6)

1. Ｗｅｂサーバシステムの負荷状況に応じて、前記Ｗｅｂサーバシステムへのユーザのログイン可能数を制限して、前記Ｗｅｂサーバシステムに対するアクセスの流量制限を行うＷｅｂサーバシステムへのログイン制限方法であって、
   アクセスの流量制限を行う第１Ｗｅｂサーバシステムが、定期的に前記第１Ｗｅｂサーバシステムの負荷状況を確認し、確認結果に応じて前記第１Ｗｅｂサーバシステムに新規にログイン可能なユーザ数を算出して、算出したユーザ数分のトークンを発行し、発行した前記トークンを、前記ユーザについての認証情報を前記第１Ｗｅｂサーバシステムに対して受け渡してシングルサインオンにより連携する１つ以上の第２Ｗｅｂサーバシステムに対して予め配布する第１ステップと、
   前記第２Ｗｅｂサーバシステムが、クライアント端末を利用した前記ユーザからの前記第２Ｗｅｂサーバシステムを経由した前記第１Ｗｅｂサーバシステムへのシングルサインオンによるアクセス要求を処理する際に、前記第１Ｗｅｂサーバシステムから配布された前記トークンのうち使用可能な前記トークンがあるか否かを確認する第２ステップと、
   前記第２ステップにおいて使用可能な前記トークンがある場合に、前記第２Ｗｅｂサーバシステムが、前記トークンのうちの１つを使用して前記アクセス要求を処理する第３ステップと、
   前記第２ステップにおいて使用可能な前記トークンがない場合に、前記第２Ｗｅｂサーバシステムが、前記アクセス要求の処理を行わずに拒否する第４ステップとを実行することを特徴とするＷｅｂサーバシステムへのログイン制限方法。
2. 請求項１に記載のＷｅｂサーバシステムへのログイン制限方法において、
   前記第１ステップでは、前記第１Ｗｅｂサーバシステムは、発行した前記トークンを前記第２Ｗｅｂサーバシステムに対して配布する際に、それぞれに対して配布する前記トークンの数もしくはその比率もしくは配布する際の前記第２Ｗｅｂサーバシステム間での優先順位を設定可能であることを特徴とするＷｅｂサーバシステムへのログイン制限方法。
3. 請求項１または２のいずれか１項に記載のＷｅｂサーバシステムへのログイン制限方法において、
   前記第１ステップでは、前記第１Ｗｅｂサーバシステムは、発行した前記トークンに対して種別を設定可能であり、
   前記第３ステップでは、前記第１Ｗｅｂサーバシステムが、前記第２Ｗｅｂサーバシステムからの前記アクセス要求に係るシングルサインオンによるログイン要求を受けた際に、使用された前記トークンに設定された前記種別に応じてログイン処理時の処理内容を変更可能であることを特徴とするＷｅｂサーバシステムへのログイン制限方法。
4. 請求項１〜３のいずれか１項に記載のＷｅｂサーバシステムへのログイン制限方法において、
   前記第１ステップでは、前記第１Ｗｅｂサーバシステムによって発行された前記トークンが配布された前記第２Ｗｅｂサーバシステムは、配布された前記トークンに対して、前記トークンを使用可能な前記ユーザの属性の情報を割り当て可能であることを特徴とするＷｅｂサーバシステムへのログイン制限方法。
5. 請求項１〜４のいずれか１項に記載のＷｅｂサーバシステムへのログイン制限方法において、
   前記第１ステップでは、前記第１Ｗｅｂサーバシステムは、発行した前記トークンに対して使用可能な期間を示す有効期限を設定可能であることを特徴とするＷｅｂサーバシステムへのログイン制限方法。
6. 請求項１〜５のいずれか１項に記載のＷｅｂサーバシステムへのログイン制限方法において、
   前記第２ステップにおいて、前記第２Ｗｅｂサーバシステムに配布された使用可能な前記トークンがない場合に、前記第１Ｗｅｂサーバシステムが、既に発行済みの前記トークンのうち、他のＷｅｂサーバシステムに対して配布されていないもの、および他のＷｅｂサーバシステムに対して配布されておりかつ使用されていないものの一部または全部を追加トークンとして前記第２Ｗｅｂサーバシステムに対して配布する第５ステップを実行することを特徴とするＷｅｂサーバシステムへのログイン制限方法。

Images