JP2004302869A - アクセス管理サーバ、ネットワーク装置、ネットワークシステム、アクセス管理方法 - Google Patents
アクセス管理サーバ、ネットワーク装置、ネットワークシステム、アクセス管理方法 Download PDFInfo
- Publication number
- JP2004302869A JP2004302869A JP2003095179A JP2003095179A JP2004302869A JP 2004302869 A JP2004302869 A JP 2004302869A JP 2003095179 A JP2003095179 A JP 2003095179A JP 2003095179 A JP2003095179 A JP 2003095179A JP 2004302869 A JP2004302869 A JP 2004302869A
- Authority
- JP
- Japan
- Prior art keywords
- client
- access
- login
- sso
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Abstract
【課題】サービス毎に自由にログイン状態の制御が可能であり、そのログイン状態の変更を即時に他のサービスへも反映するとともに、パフォーマンスへの影響を最小限に抑え、さらに特別なポータルを必要としないネットワークシステムを提供する。
【解決手段】ＳＳＯアプリケーション２，３は、それぞれログイン状態情報データベース２３にログイン状態情報を保持しており、自由にログイン状態の管理を行うことができる。またＳＳＯアプリケーション２，３に対するクライアント５〜７のアクセスは、アクセス情報としてＳＳＯサーバ１のＳＳＯアクセス情報データベース１２に保持しておく。クライアント５〜７からのログインやログアウトなどのログイン状態の変更要求があると、ＳＳＯサーバ１はアクセス情報を利用してそれまでに要求元のクライアントがアクセスしたＳＳＯアプリケーションに対してログイン状態情報を通知する。
【選択図】 図１
【解決手段】ＳＳＯアプリケーション２，３は、それぞれログイン状態情報データベース２３にログイン状態情報を保持しており、自由にログイン状態の管理を行うことができる。またＳＳＯアプリケーション２，３に対するクライアント５〜７のアクセスは、アクセス情報としてＳＳＯサーバ１のＳＳＯアクセス情報データベース１２に保持しておく。クライアント５〜７からのログインやログアウトなどのログイン状態の変更要求があると、ＳＳＯサーバ１はアクセス情報を利用してそれまでに要求元のクライアントがアクセスしたＳＳＯアプリケーションに対してログイン状態情報を通知する。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、クライアントが複数のサービスを利用する際のアクセス管理技術に関するものであり、特に、一度認証するだけで認証が必要な複数のサービスを利用可能とするシングルサインオン（以下ＳＳＯ）機能に適用可能なアクセス管理技術に関するものである。
【０００２】
【従来の技術】
クライアントがネットワークを通じてサービスを利用する場合、そのサービスを利用する権限を有していることを確認するため、ユーザ名やパスワード等の入力によるサインを行う。ユーザの利用権限のチェックはそれぞれのサービスごとに必要となるため、旧来はそれぞれのサービスを利用する毎にユーザはサインを行っていた。しかし、利用するサービスが複数存在する場合、いちいちサインを行うのは手間がかかる。このようなユーザの手間を軽減するため、クライアントがただ一度のサイン（ユーザ名，パスワード等の入力）を行うことで複数のサービスの利用を可能にしたシングルサインオンの技術が開発されている。
【０００３】
シングルサインオンを実現する従来の方法の一つとして、例えばクライアント側で用いているブラウザにおいて、アプリケーション毎のサイン（ユーザ名，パスワード）を保持する方法がある。しかし、このような機能を有していないブラウザもあり、汎用的に利用できる技術ではない。
【０００４】
別の方法として、例えば特許文献１に記載されているように、クライアントからのアクセスを受け付けるＷｅｂサーバを設け、このＷｅｂサーバを通じて各種のサービスを提供する方法がある。この場合、Ｗｅｂサーバに対して１回のサイン（ユーザ名，パスワード入力）のみで、各種のサービスを利用することが可能である。また、クライアントのログイン状態はすべてＷｅｂサーバにおいて一元管理することができる。
【０００５】
しかし、ＷｅｂサーバやＳＳＯに参加している各サーバが利用するクライアント識別情報は同一であることを前提としているため、例えばＷｅｂアプリケーションに適用しようとした場合、必ずポータル的なサーバが必要となる。そのため、すでにネットワーク上にサーバが構成されている場合、導入への大きな障害となる。また、クライアントからの要求はすべてＷｅｂサーバを通過しなければならないため、パフォーマンスへの影響も大きい。
【０００６】
別の方法として、例えば特許文献２に記載されているように、複数の認証が必要なＷＷＷサーバのうち、一つのＷＷＷサーバにおいて認証を行えば、そのＷＷＷサーバから他のサーバへ認証済み情報が通知される技術がある。この技術では、認証が行われたときに、その旨を他のすべてのＷＷＷサーバへ通知する。そのため、それぞれのＷＷＷサーバが通知先となる全てのＷＷＷサーバの情報を保持している必要がある。また、クライアントがアクセスしたか否かによらず、全てのＷＷＷサーバへ認証済みである旨を通知するため、通知によるトラフィック量が増大し、パフォーマンスへの影響が大きいという問題がある。
【０００７】
さらに別の方法として、特願２００２−９５７５５号公報に記載されている技術においても、ＳＳＯサーバにおいてクライアント識別情報とそのクライアントの認証情報を一元管理し、ＳＳＯを実現している。この技術では、クライアントからのアクセスを受けたＷＷＷアプリケーションがＳＳＯサーバに問い合わせ、また、ＷＷＷアプリケーションがＳＳＯサーバから認証状況を受け取った後は、クライアントとＷＷＷアプリケーションの間で通信を行うので、特定のサーバにアクセスが集中することもなく、パフォーマンスの影響は小さい。
【０００８】
しかしこの技術では、ログイン状態を決定する情報をクライアントから受け取るのは、ログイン状態を管理しているサーバ（ＳＳＯサーバ）である。そのため、例えばＤｏｃｕＳｈａｒｅ（登録商標）のように各々のサーバがログイン状態を管理し、またそれぞれのサーバが認証機能を有してクライアントからの要求により認証方法を切り替えるといった制御を行っているシステムをＳＳＯに参加させることはできない。また、この技術では、ＳＳＯに参加しているサーバがＳＳＯサーバへクライアントのログイン状態を問い合わせるのは最初の接続時のみであり、その後のログイン状態の変化を反映することができない。そのため、クライアントのログイン状態が自由に変更可能なシステムにおいては、ログイン状態の統一を保つことができないという問題があった。
【０００９】
【特許文献１】
特開２０００−１０６５５２号公報
【特許文献２】
特開２００２−２８８１３８号公報
【００１０】
【発明が解決しようとする課題】
本発明は、上述した事情に鑑みてなされたもので、ＳＳＯに参加しているサービス毎に自由にログイン状態の制御が可能であるとともに、そのクライアントのログイン状態の変更を、パフォーマンスへの影響を最小限に抑えながらも、即時に他のサービスへも反映することができ、さらに特別なポータルを必要としないネットワークシステムを提供するとともに、そのようなネットワークシステムにおいて利用可能なアクセス管理サーバ及びネットワーク装置と、アクセス管理方法を提供することを目的とするものである。
【００１１】
【課題を解決するための手段】
本発明は、クライアントに対して提供されるサービスへの前記クライアントのアクセスを管理するアクセス管理サーバ及びアクセス管理方法において、通信制御手段は、クライアントが新たなサービスにアクセスするたびに、そのクライアントがアクセスしたサービスの情報をアクセス情報としてアクセス情報保持手段に保持し、クライアントのログイン状態の変更時には、アクセス情報保持手段に保持しておいたアクセス情報に従って、クライアントがアクセスしたサービスに対してログイン状態情報の変更を通知することを特徴とするものである。さらにクライアントのログイン状態に関するログイン状態情報をログイン状態情報保持手段に保持しておき、既にアクセス済のクライアントが他のサービスに新たにアクセスしたときには、ログイン状態情報に従って、他のサービスに対してログイン状態を通知し、ログイン状態の変更時にはログイン状態情報保持手段中のログイン状態情報の更新も行うように構成することができる。
【００１２】
例えばクライアントがいくつかのサービスに対してアクセスした場合には、それぞれのサービスに対してアクセスした旨をアクセス情報として保持しておく。そして、ログイン状態の変更としてサービスに対するログイン要求を受け付けた場合には、必要に応じてクライアントの認証を行い、あるサービスに対するログインの許可を他のアクセス済のサービスに対して通知する。また、例えばログイン状態の変更としてサービスに対するログアウト要求を受け付けた場合には、あるサービスに対するログアウトを他のアクセス済のサービスに対して通知すればよい。
【００１３】
このような構成によって、ログイン状態の変更に対応することができるとともに、ログイン状態の変更時にはそれまでクライアントがアクセスしたサービスに対してのみ、即時に通知するので、トラフィック量を低減してパフォーマンスへの影響を最小限に抑えながら、即時性を保証することができる。
【００１４】
なお、上述のようなクライアントからのアクセスあるいはサービスからのクライアントに関する問い合わせのアクセスに対して、それぞれのクライアント毎に有効期限を定めておくことができる。もちろん、有効期限を定めなくてもよい。
【００１５】
また本発明は、上述のようなアクセス管理サーバを利用し、ネットワークを通じて行われるクライアントからの要求に応じてサービスを提供するネットワーク装置において、クライアントのログイン状態に関するログイン状態情報をログイン状態情報保持手段に保持に保持しておき、クライアントからのアクセスを受けた際に、ログイン状態情報保持手段が保持するログイン状態情報を調べ、新たなクライアントからのアクセスである場合、あるいは、ログイン状態の変更を要求するアクセスの場合にはアクセス管理サーバに通知し、アクセス管理サーバからの通知に応じてログイン状態情報保持手段へのログイン状態情報の登録又はログイン状態情報の更新を行うことを特徴とするものである。
【００１６】
なお、ログイン状態の変更を要求したクライアントがサービスに対するローカルユーザである場合には、アクセス管理サーバへの問い合わせを行わずにログイン状態の変更を行うように構成することができる。このように、アクセス管理サーバによるログイン状態の管理に束縛されずに、それぞれのネットワーク装置が自由にログイン状態の制御が可能である。
【００１７】
また、サービスを提供するネットワーク装置の側でも、クライアント毎にアクセスの有効期限を定めることができる。もちろん、有効期限を定めなくてもよい。
【００１８】
さらに本発明は、ネットワークを通じて行われるクライアントからの要求に応じてサービスを提供するネットワーク装置と、ネットワークを通じて前記クライアントのアクセスを管理するアクセス管理サーバを含むネットワークシステムであって、ネットワーク装置は、クライアントから新たなアクセスを受けた際にアクセス管理サーバに通知し、アクセス管理サーバは、ネットワーク装置からの新たなアクセスを受けた際の通知に従いアクセス情報を保持する。そして、ネットワーク装置がクライアントからログイン状態の変更を要求された場合には、ログイン状態の変更の要求をアクセス管理サーバに送り、前記アクセス管理サーバはそれまでに保持されている当該クライアントに対応するアクセス情報に従って１ないし複数のネットワーク装置に対してログイン状態の変更を通知することを特徴とするものである。
【００１９】
例えばネットワーク装置がクライアントからログインの要求を受けたときには、アクセス管理サーバは必要に応じてクライアントの認証を行って、当該クライアントに対応するログイン状態情報をログインしている旨に変更するとともに、それまでに当該クライアントがアクセスした１ないし複数のネットワーク装置に対してログイン状態情報の変更を通知する。これによって、他のネットワーク装置においても当該クライアントをログイン済として扱うことができる。
【００２０】
また、ネットワーク装置がクライアントからログアウトの要求を受けたとき、アクセス管理サーバは当該クライアントに対応するログイン状態情報をログアウトの状態に変更するとともに、それまでに当該クライアントがアクセスした１ないし複数のネットワーク装置に対してログイン状態情報の変更を通知する。これによって、他のネットワーク装置においても当該クライアントがログアウトしたものとして扱うことができる。
【００２１】
このようなネットワークシステムおいては、ログイン状態の変更に容易に対応することができるとともに、ログイン状態の変更時にはそれまでクライアントがアクセスしたサービスに対してのみ、即時に通知するので、トラフィック量を低減してパフォーマンスへの影響を最小限に抑えながら、即時性を保証することができる。
【００２２】
【発明の実施の形態】
図１は、本発明の実施の一形態を示すシステム構成図である。図中、１はＳＳＯサーバ、２，３はＳＳＯアプリケーション、４はネットワーク、５〜７はクライアント、１１は通信制御部、１２はＳＳＯアクセス情報データベース、１３はログイン状態情報データベース、１４はユーザ認証情報データベース、２１は通信制御部、２２は処理部、２３はログイン状態情報データベースである。図１に示す例では、ＳＳＯサーバ１、ＳＳＯアプリケーション２，３、クライアント５〜７などがネットワーク４を利用して通信可能に構成されている。もちろん、多くのクライアント、多くのＳＳＯアプリケーション、その他多くのサーバ等と通信可能である。ネットワーク４は、ＬＡＮやインターネットなど、各種のネットワークで構成することができ、またそれらが複合的に組み合わされた構成であってよい。
【００２３】
ＳＳＯサーバ１は、クライアント５〜７からＳＳＯアプリケーション２，３に対するアクセス及びログイン状態を管理するアクセス管理サーバとして機能する。クライアントが新たなＳＳＯアプリケーションに対してアクセスする度にクライアントとアクセスしたＳＳＯアプリケーションの情報をＳＳＯアクセス情報としてＳＳＯアクセス情報データベース１２に保持しておく。また、管理しているログイン状態の情報をログイン状態情報データベース１３に格納しており、このログイン状態情報を用いてＳＳＯアプリケーション２，３からのログイン状態の問い合わせに応じることでＳＳＯ機能を提供する。さらに、ログイン状態の変更時には、必要に応じてクライアントの認証を行うとともに、ＳＳＯアクセス情報として登録されているそれまでにクライアントがアクセスしたＳＳＯアプリケーションに対してログイン状態の変更を通知する。ログイン状態の変更としては、ログイン前のゲストからユーザアカウントへのログイン、及び、ログインの状態からのログアウトなどがある。
【００２４】
この例ではＳＳＯサーバ１は、通信制御部１１、ＳＳＯアクセス情報データベース１２、ログイン状態情報データベース１３、ユーザ認証情報データベース１４などを含んで構成されている。通信制御部１１は、ネットワーク４を通じてＳＳＯアプリケーション２，３やクライアント５〜７等との通信を行うとともに、上述のようなＳＳＯサーバ１における機能を実現する。
【００２５】
ＳＳＯアクセス情報データベース１２は、クライアントがアクセスしたＳＳＯアプリケーションに関するアクセス情報を保持する。またログイン状態情報データベース１３は、それぞれのクライアントごとに、クライアントのログイン状態に関するログイン状態情報を保持する。さらにユーザ認証情報データベース１４は、クライアントの認証情報を保持する。
【００２６】
図２は、ＳＳＯサーバが保持する情報の一例の説明図である。図２（Ａ）に示すＳＳＯアクセス情報データベース１２に格納するアクセス情報は、ＳＳＯサーバにおけるクライアント識別情報（以下、ｓｉｄと呼ぶことがある）と、クライアントがアクセスしたＳＳＯアプリケーションの名称などの識別情報と、当該ＳＳＯアプリケーションにおけるクライアント識別情報（以下、ｃｉｄと呼ぶことがある）から構成されている。このようなアクセス情報を、クライアント毎、ＳＳＯアプリケーション毎に格納する。
【００２７】
また図２（Ｂ）に示すログイン状態情報データベース１３に格納するログイン状態情報は、ＳＳＯサーバにおけるクライアント識別情報（ｓｉｄ）と、ログイン状態から構成されている。ログイン状態には、例えば３行目に示しているように“ｇｕｅｓｔ”でＳＳＯアプリケーション２，３にアクセスしている状態か、１，２行目に示しているように“ｕｓｅｒ−Ａ”や“ｕｓｅｒ−Ｂ”といったユーザＩＤのアカウントによりログインした状態か、等を示す情報が格納されている。
【００２８】
さらに図２（Ｃ）に示すユーザ認証情報データベース１４に格納するユーザ認証情報は、ユーザＩＤと、対応する認証情報（例えばパスワードなど）によって構成されている。クライアントからログイン要求を受けたとき、ユーザＩＤと認証情報を用いて認証を行うことができる。
【００２９】
なお、それぞれのデータベースに格納する情報は図２に示した情報に限られるものではなく、それぞれの機能が果たせればどのような情報であってもよいし、他の種々の情報を含んでいてもよい。また、ＳＳＯアクセス情報データベース１２、ログイン状態情報データベース１３、ユーザ認証情報データベース１４は、この例ではＳＳＯサーバ１内に設けているが、これに限らず、その一部又は全部をＳＳＯサーバ１とは別のサーバにより構成することも可能である。
【００３０】
ＳＳＯアプリケーション２，３は、クライアントに対して各種のサービスを提供する。ＳＳＯアプリケーション２，３は、例えばコンピュータなどのネットワーク装置（サーバ）で構成することができる。なお、１台のネットワーク装置（サーバ）が複数のサービスを提供することもあるし、複数台のネットワーク装置が協働して１つのサービスを提供することもある。ここでは、ＳＳＯアプリケーション２，３は、クライアントに対して提供されるサービスに対応するものとして示している。なお、ＳＳＯアプリケーション２，３は、それぞれがローカルユーザのための認証機構を有しており、ユーザの認証を独自で行うことができる。認証を独自で行うか、あるいはＳＳＯサーバに任せるかは、それぞれのＳＳＯアプリケーション２，３が判断して行う。従って、ログイン状態の制御をＳＳＯアプリケーションにおいて行うことができる。
【００３１】
ＳＳＯアプリケーション２は、通信制御部２１、処理部２２、ログイン状態情報データベース２３を含んで構成されている。ＳＳＯアプリケーション３については図示していないが、同様の構成を含んで構成することができる。処理部２２は、実際にサービスを提供する部分である。
【００３２】
通信制御部２１は、ネットワーク１を通じてクライアント５〜７及びＳＳＯサーバ１などとの通信を行い、ＳＳＯアプリケーション２における処理部２２で行うサービスのための処理以外の様々な処理を行う。例えばクライアントからのアクセスを受け付け、ログイン状態情報データベース２３が保持するログイン状態情報を調べ、新たなクライアントからのアクセスである場合には、ＳＳＯサーバ１に対して問い合わせを行い、ログイン状態情報を受け取ってログイン状態情報を登録する。このとき、既に他のＳＳＯアプリケーションでログイン済であり、ＳＳＯ機能によりログインを許可する場合には、このＳＳＯアプリケーション２においてもログイン済として扱う。また、例えばゲストとしてアクセスしているクライアントからログイン要求を受けたり、ログイン中のクライアントからログアウト要求を受けるなど、ログイン状態を変更する要求を受けた場合には、ローカルなユーザであれば自装置内で処理し、そうでなければＳＳＯサーバ１に依頼する。さらに、ＳＳＯサーバ１からクライアントのログイン状態情報の変更が通知された場合には、当該通知に基づいてログイン状態情報の更新を行う。当然、ＳＳＯアプリケーション毎のクライアント管理の方針によりログイン状態情報の更新を行わなくても良い。（例えば、ローカルユーザのログイン状態を優先する方針であれば、ＳＳＯサーバ１からの通知では、ログイン状態を更新しない等。）
【００３３】
ログイン状態情報データベース２３は、それぞれのクライアントのログイン状態に関する情報であるログイン状態情報を保持している。図３は、ＳＳＯアプリケーションが保持するログイン状態情報の一例の説明図である。このログイン状態情報は、図２（Ｂ）に示したＳＳＯサーバ１が保持するログイン状態情報と同様であり、ＳＳＯアプリケーション２におけるクライアント識別情報（ｃｉｄ）とログイン状態を保持している。このログイン状態情報は、ＳＳＯアプリケーション２においてローカルなユーザについてのログイン状態情報についても保持しておくことができる。なお、ログイン状態情報は、図３に示した構成に限られるものではない。また、このログイン状態情報データベース２３はＳＳＯアプリケーションとは別に設けることも可能である。
【００３４】
なおクライアント５〜７は、コンピュータや携帯端末、携帯電話をはじめ、様々なネットワーク機器で構成することができる。
【００３５】
次に、本発明の実施の一形態における動作について説明する。なお、以下の動作の説明では、利用するプロトコルはＨＴＴＰとして説明する。図４は、クライアントからＳＳＯアプリケーションへの初回のアクセス時の動作の一例を示すシーケンス図である。ここではクライアント５がＳＳＯにより利用可能なＳＳＯアプリケーション群へのはじめてのアクセスとして、ＳＳＯアプリケーション２に対してアクセスを行ったものとする。クライアントは（１）において、ＳＳＯアプリケーション２のホームページなどのアドレス（ｕｒｌ）を指定してアクセスする。
【００３６】
ＳＳＯアプリケーション２は、クライアント５からのアクセスを受けると、クライアント５が既にＳＳＯアプリケーション２にアクセスを行っているか否かを調べる。これは、例えばクライアント５からＳＳＯアプリケーション２が発行した情報（例えばクッキー）の提示があるか否かを判定したり、あるいは、ログイン状態情報データベース２３に格納されているログイン状態情報を調べることによって行うことができる。
【００３７】
クライアント５からの新規のアクセスであることを確認したら、（２）において、クライアント５に対してクライアント識別情報（ｃｉｄ）を割り当てる。そして、ログイン状態情報として、クライアント識別情報（ｃｉｄ）と、まだログインしていない状態であることを示すログイン状態“ゲスト”を対応付けてログイン状態情報データベース２３に格納する。さらに、一時的な識別子（ｏｉｄ）をクライアント識別情報（ｃｉｄ）と対応付けて保持しておく。そしてＳＳＯアプリケーション２は、（３）において、クライアント５に対してリダイレクションによってＳＳＯサーバ１へのアクセスを指示する。このとき、ＳＳＯサーバ１のアドレスとともに、ＳＳＯアプリケーション２のアドレス（ＳＳＯＡｐｐ）と一時的な識別子（ｏｉｄ）を送る。
【００３８】
クライアント５では、リダイレクションの指示をＳＳＯアプリケーション２から受け取ると、自動的に、あるいはユーザの指示に従い、（４）において、送られてきたＳＳＯサーバのアドレスを用いてＳＳＯサーバ１へのアクセスが行われる。この時、同じく送られてきたＳＳＯアプリケーション２のアドレス（ＳＳＯＡｐｐ）と一時的な識別子（ｏｉｄ）についてもＳＳＯサーバ１へ送る。
【００３９】
ＳＳＯサーバ１では、クライアント５からのアクセスを受けると、クライアント５が既にＳＳＯサーバ１（すなわちＳＳＯアプリケーションのいずれか）にアクセスを行っているか否かを調べる。これは、例えばクライアント５からＳＳＯサーバ１が発行した情報（例えばクッキー）の提示があるか否かを判定したり、あるいは、ログイン状態情報データベース１３に格納されているログイン状態情報を調べることによって行うことができる。
【００４０】
クライアント５からの新規のアクセスであることを確認したら、（５）において、クライアント５に対してクライアント識別情報（ｓｉｄ）を割り当てる。そして、ログイン状態情報として、クライアント識別情報（ｓｉｄ）と、まだログインしていない状態であることを示すログイン状態“ゲスト”を対応付けてログイン状態情報データベース２３に格納する。さらに、（６）において、ＳＳＯサーバ１はＳＳＯアプリケーション２に対して、クライアント５から送られてきたＳＳＯアプリケーション２のアドレス（ＳＳＯＡｐｐ）及び一時的な識別子（ｏｉｄ）をもとに、ＳＳＯアプリケーション２におけるクライアント識別情報（ｃｉｄ）を要求する。
【００４１】
ＳＳＯサーバ１からの要求を受け取ったＳＳＯアプリケーション２では、（７）において、送られてきた一時的な識別子（ｏｉｄ）をもとに、関連づけられているクライアント識別情報（ｃｉｄ）を取得し、一時的な識別子（ｏｉｄ）とクライアント識別情報（ｃｉｄ）との関連づけを消す。そして（８）において、ＳＳＯアプリケーション２におけるクライアント識別情報（ｃｉｄ）をＳＳＯサーバ１へ送る。
【００４２】
ＳＳＯサーバ１では、ＳＳＯアプリケーション２から送られてきたクライアント識別情報（ｃｉｄ）を受け取ると、（９）において、ＳＳＯサーバ１におけるクライアント識別情報（ｓｉｄ）と、ＳＳＯアプリケーション２を識別する情報（例えばＳＳＯアプリケーション２のアドレス（ＳＳＯＡｐｐ）など）と、ＳＳＯアプリケーション２におけるクライアント識別情報（ｃｉｄ）とを対応付けてアクセス情報としてＳＳＯアクセス情報データベース１２に格納する。ＳＳＯサーバ１は、アクセス情報の登録が終了した後、クライアント５が初回のアクセスであった場合には、（１０）において、ＳＳＯアプリケーション２にアクセスを戻すため、ＳＳＯアプリケーション２のアドレス（ＳＳＯＡｐｐ）を指定したリダイレクションをクライアント５に指示する。この時、以後、ＳＳＯサーバ１にアクセスする際に用いる情報（例えばクッキーなど）をクライアント５へ送っておく。
【００４３】
クライアント５では、リダイレクションの指示をＳＳＯサーバ１から受け取ると、自動的に、あるいはユーザの指示に従い、（１１）において、送られてきたＳＳＯアプリケーションのアドレス（ＳＳＯＡｐｐ）を用いてＳＳＯアプリケーション２へのアクセスが行われる。
【００４４】
ＳＳＯアプリケーション２は、クライアント５からのアクセスを受け取ると、（１２）において、今度はクライアント５にクライアント識別情報（ｃｉｄ）が割り当てられているので、これをもとにログイン状態情報データベース２３に格納されているログイン状態情報を取得し、クライアント５のログインの状態を調べる。ここではクライアント５のログイン状態は“ゲスト”である。要求されているページが“ゲスト”のログイン状態で参照可能であることを確認後、（１３）において、要求されているページをクライアント５へ送る。
【００４５】
このようにして、（１）で要求したページがクライアント５において表示され、ユーザが参照することができる。以後、ＳＳＯアプリケーション２において“ゲスト”のログイン状態で参照可能なページについては、クライアント５からの要求に応じて、ＳＳＯアプリケーション２が当該ページを送ることによって、やりとりが行われる。
【００４６】
図５は、クライアントから別のＳＳＯアプリケーションへアクセスした時の動作の一例を示すシーケンス図である。ここではクライアント５が上述のようにしてＳＳＯアプリケーション２にアクセスした後に、ＳＳＯアプリケーション３に対してアクセスを行ったものとする。なお、図４で説明した初回のアクセス時と同様の部分には同じ符号を付して概略のみを説明する。
【００４７】
クライアント５が（１）においてＳＳＯアプリケーション３にアクセスすると、ＳＳＯアプリケーション３は、クライアント５が既にＳＳＯアプリケーション３にアクセスを行っているか否かを調べる。ここでは、クライアント５はＳＳＯアプリケーション２に対しては既にアクセスを行っているものの、ＳＳＯアプリケーション３に対しては初回のアクセスとなる。
【００４８】
ＳＳＯアプリケーション３は、クライアント５からの新規のアクセスであることを確認したら、（２）において、クライアント５に対するクライアント識別情報（ｃｉｄ）の割り当てと、ログイン状態情報の生成及びログイン状態情報データベースへの格納を行う。さらに、一時的な識別子（ｏｉｄ）をクライアント識別情報（ｃｉｄ）と対応付けて保持しておく。そして（３）において、クライアント５に対してリダイレクションによってＳＳＯサーバ１へのアクセスを指示する。クライアント５は、リダイレクションの指示を受け、（４）において、ＳＳＯサーバ１へのアクセスを行う。
【００４９】
ＳＳＯサーバ１では、クライアント５からのアクセスを受けると、（５’）において、クライアント５が既にＳＳＯサーバ１（すなわちＳＳＯアプリケーションのいずれか）にアクセスを行っているか否かを調べる。ここでは既にＳＳＯアプリケーション２にアクセスしたときにＳＳＯサーバ１へのアクセスを行っている。従って、ログイン状態情報データベース１３にクライアント５のログイン状態情報が格納されている。また、例えばＳＳＯサーバ１が例えばクッキー等の情報を発行している場合には、クライアント５からＳＳＯサーバ１が発行した例えばクッキー等の情報が提示される。なお、クライアント５が既に他のＳＳＯアプリケーションにアクセスしている場合には、新たなクライアント識別情報（ｓｉｄ）の割り当てや新たなログイン状態情報の生成及び登録などは行わない。
【００５０】
ＳＳＯサーバ１は、（６）において、ＳＳＯアプリケーション３に対して一時的な識別子（ｏｉｄ）をもとに、ＳＳＯアプリケーション３におけるクライアント識別情報（ｃｉｄ）を要求する。この要求に対して、ＳＳＯアプリケーション３では、（７）において、送られてきた一時的な識別子（ｏｉｄ）をもとに、関連づけられているクライアント識別情報（ｃｉｄ）を取得し、一時的な識別子（ｏｉｄ）とクライアント識別情報（ｃｉｄ）との関連づけを消す。そして（８）において、ＳＳＯアプリケーション３におけるクライアント識別情報（ｃｉｄ）をＳＳＯサーバ１へ送る。
【００５１】
ＳＳＯサーバ１では、ＳＳＯアプリケーション３から送られてきたクライアント識別情報（ｃｉｄ）を受け取ると、（９）において、ＳＳＯサーバ１におけるクライアント識別情報（ｓｉｄ）と、ＳＳＯアプリケーション３を識別する情報（例えばＳＳＯアプリケーション３のアドレス（ＳＳＯＡｐｐ）など）と、ＳＳＯアプリケーション３におけるクライアント識別情報（ｃｉｄ）とを対応付けてアクセス情報としてＳＳＯアクセス情報データベース１２に格納する。このようにして、同じクライアント５であっても、異なるＳＳＯアプリケーションにアクセスした場合には新たなアクセス情報が生成され、登録される。従ってクライアント５がいずれのＳＳＯアプリケーションにアクセスしたかがアクセス情報として蓄積されることになる。
【００５２】
ＳＳＯサーバ１は、アクセス情報の登録が終了した後、（１０’）において、ＳＳＯアプリケーション３に対して、ログイン状態情報データベース１３に格納されているクライアント５に対応するログイン状態情報（ｓｔａｔｕｓ）を、ＳＳＯアプリケーション３におけるクライアント５のクライアント識別情報（ｃｉｄ）とともに送る。この通知を受けたＳＳＯアプリケーション３では、（１２’）において、ログイン状態情報データベース２３に格納されているクライアント５に対応するログイン状態情報を、受け取ったログイン状態情報に書き換える。そして（１３）において、要求されているページをクライアント５へ送る。
【００５３】
この例では、先にＳＳＯアプリケーション２に対して“ゲスト”としてアクセスしているので、ＳＳＯサーバ１からＳＳＯアプリケーション３に対してログイン状態が“ゲスト”である旨が通知され、ＳＳＯアプリケーション３におけるクライアント５に対するログイン状態情報は“ゲスト”のままである。例えば後述するログイン状態の変更要求がなされ、ユーザＩＤなどによってログインされた状態の場合には、その旨がＳＳＯサーバ１からＳＳＯアプリケーション３に通知され、ＳＳＯアプリケーション３においても通知されたユーザＩＤによってログインされた状態となる。これによって、クライアント５から改めてＳＳＯアプリケーション３に対してログインを行わなくても、ＳＳＯアプリケーション３にログインしているものとしてＳＳＯアプリケーション３のサービスを受けることができ、ＳＳＯを実現することができる。
【００５４】
次に、ログイン状態の変更を要求された場合の動作について説明する。ログイン状態の変更としては、ユーザＩＤによるログインやログアウトなどがある。まずログイン時の動作について説明する。
【００５５】
図６は、クライアントからＳＳＯアプリケーションへログイン要求を行ったときの動作の一例を示すシーケンス図である。ここではクライアント５がＳＳＯアプリケーション２にログイン要求を行うものとし、これまでにクライアント５はＳＳＯアプリケーション２，３に対してアクセスを行っているものとする。すなわち、ＳＳＯサーバ１にはアクセス情報として、ＳＳＯアプリケーション２へのアクセス時のアクセス情報とＳＳＯアプリケーション３へのアクセス時のアクセス情報がＳＳＯアクセス情報データベース１２に格納されているものとする。
【００５６】
クライアント５は、ログインを要求するために、ここではＳＳＯアプリケーション２に対して（２１）においてログインフォームを要求し、ＳＳＯアプリケーション２は、この要求に応じて（２２）においてログインフォームをクライアント５に送る。クライアント５では、送られてきたログインフォームにユーザＩＤやパスワードなどの所定事項を入力し、その内容をログイン情報として、（２３）においてＳＳＯアプリケーション２に送る。
【００５７】
ＳＳＯアプリケーション２は、クライアント５からログイン情報を受け取ると、その内容をチェックした後、（２４）においてクライアント５のクライアント識別情報（ｃｉｄ）とともにログイン情報をＳＳＯサーバ１へ送る。
【００５８】
ＳＳＯサーバ１では、ＳＳＯアプリケーション２からクライアント識別情報（ｃｉｄ）及びログイン情報を受け取ると、（２５）において、ユーザ認証情報データベース１４に格納されているユーザ認証情報を用いて認証を行う。認証に成功したら、ＳＳＯアプリケーション２におけるクライアント識別情報（ｃｉｄ）をもとにＳＳＯサーバ１におけるクライアント識別情報（ｓｉｄ）を特定し、ログイン状態情報データベース１３に格納されているクライアント５のログイン状態情報を更新する。さらに（２６）において、ＳＳＯサーバ１におけるクライアント識別情報（ｓｉｄ）をもとにＳＳＯアクセス情報データベース１２を検索し、それまでクライアント５がアクセスしたＳＳＯアプリケーションを特定する。
【００５９】
そして（２７）において、（２６）で特定したＳＳＯアプリケーションに対して、それぞれ、ログイン状態情報（ｓｔａｔｕｓ）をそれぞれのＳＳＯアプリケーションにおけるクライアント識別情報（ｃｉｄ）とともに送る。クライアント５がＳＳＯアプリケーション２，３にアクセスしていた場合、図中（２７）として示すＳＳＯアプリケーション２へのログイン状態情報の送信とともに、ＳＳＯアプリケーション３に対してもログイン状態情報が送信される。これを（２７’）として示している。
【００６０】
このように、ログインが行われてログイン状態が更新される場合には、ＳＳＯアクセス情報データベース１２に蓄積されている、クライアントがそれまでにアクセスしたすべてのＳＳＯアプリケーションに対して更新後のログイン状態情報が送信される。これによって即時性を保証する。しかし、ＳＳＯアプリケーションが多数存在する場合でも、クライアントがアクセスしたＳＳＯアプリケーションのみにしかログイン状態情報を送信しないため、ネットワーク４などに対する負荷を最小限にとどめることができる。さらに、ログイン状態の変更はＳＳＯサーバ１から通知されるため、ＳＳＯアプリケーションから定期的に、あるいはクライアントからのアクセス時毎にＳＳＯサーバ１へ尋ねる必要もなく、この点でも即時性及び負荷の軽減に寄与することができる。
【００６１】
ＳＳＯサーバ１からログイン状態情報を受け取ったＳＳＯアプリケーション２では、（２８）において、受け取ったログイン状態情報に従ってログイン状態情報データベース２３を更新し、クライアント５はＳＳＯアプリケーション２にログインした状態に変更される。そしてＳＳＯアプリケーション２は、ログイン後のページを（２９）においてクライアント５に送る。以後、クライアント５はログインしたユーザとして扱われ、ログインユーザのみに許されるページなどの参照が可能となる。
【００６２】
また、ＳＳＯアプリケーション３においても、ＳＳＯサーバ１からクライアント５のログイン状態情報を受け取る。そしてＳＳＯアプリケーション３のログイン状態情報データベースについても更新される。これによって、クライアント５がＳＳＯアプリケーション２に対してログインを行うだけで、ＳＳＯアプリケーション３についてもログインを行ったのと同等のサービスを受けることができるようになり、ＳＳＯの機能を実現することができる。
【００６３】
なお、（２３）においてＳＳＯアプリケーション２がクライアント５からログイン情報を受け取ったとき、このログイン情報を（２４）でＳＳＯサーバ１に転送するか否かはＳＳＯアプリケーション２が制御可能である。例えばＳＳＯアプリケーション２が個別の認証機構を有しており、ＳＳＯアプリケーション２のローカルユーザとしてクライアントの認証を行う場合には、クライアントの認証を自装置において行えばよく、ＳＳＯサーバ１にログイン情報を転送する必要はない。また、ＳＳＯアプリケーションにおいて、クライアントはローカルユーザとしてログインしており、かつそのＳＳＯアプリケーションがローカルユーザを優先する方針であれば、ＳＳＯサーバからログイン状態情報変更の通知を受け取ったとしても、クライアントのログイン状態を更新する必要はない。既存のＳＳＯアプリケーションでは、このように従来から用いているアカウント及び認証機構をそのまま維持している場合が多く、このようなＳＳＯアプリケーションについてもＳＳＯシステムに容易に加えることが可能である。またこのような機構によって、ＳＳＯアプリケーションがログイン状態を任意に制御できるようにしている。
【００６４】
また、ＳＳＯサーバ１が（２５）において認証を行った結果、認証が不成功に終わった場合には、その旨をＳＳＯアプリケーション２に送り、さらにＳＳＯアプリケーション２がクライアント５に対してログインが成功しなかった旨を伝えればよい。
【００６５】
図７は、クライアントからＳＳＯアプリケーションへログアウト要求を行ったときの動作の一例を示すシーケンス図である。ここではクライアント５がログイン中にＳＳＯアプリケーション２に対してログアウトの要求を行うものとする。この例においても、これまでにクライアント５はＳＳＯアプリケーション２，３に対してアクセスを行っているものとする。
【００６６】
クライアント５は、ここではＳＳＯアプリケーション２に対して（３１）においてログアウトを要求する。ＳＳＯアプリケーション２は、クライアント５からログアウトの要求を受け取ると、（３２）においてクライアント５のクライアント識別情報（ｃｉｄ）とともにログアウトの要求をＳＳＯサーバ１へ送る。
【００６７】
ＳＳＯサーバ１では、ＳＳＯアプリケーション２からクライアント識別情報（ｃｉｄ）及びログアウトの要求を受け取ると、（３３）において、ＳＳＯアプリケーション２におけるクライアント識別情報（ｃｉｄ）をもとにＳＳＯサーバ１におけるクライアント識別情報（ｓｉｄ）を特定し、ログイン状態情報データベース１３に格納されているクライアント５のログイン状態情報を更新する。例えば“ゲスト”の状態に戻せばよい。
【００６８】
さらに、ＳＳＯサーバ１におけるクライアント識別情報（ｓｉｄ）をもとにＳＳＯアクセス情報データベース１２を検索し、それまでクライアント５がアクセスしたＳＳＯアプリケーションを特定する。
【００６９】
そして（３４）において、（３３）で特定した各ＳＳＯアプリケーションに対して、ログアウトをそれぞれのＳＳＯアプリケーションにおけるクライアント識別情報（ｃｉｄ）とともに送る。ログアウトは、例えば“ゲスト”のログイン状態情報（ｓｔａｔｕｓ）を送信してもよい。クライアント５がＳＳＯアプリケーション２，３にアクセスしていた場合、図中（３４）として示すＳＳＯアプリケーション２へのログアウトの送信とともに、ＳＳＯアプリケーション３に対してもログアウトが送信される。これを（３４’）として示している。
【００７０】
このように、ログアウトが行われてログイン状態が更新される場合も、ログイン時と同様、ＳＳＯアクセス情報データベース１２に蓄積されている、クライアントがそれまでにアクセスしたすべてのＳＳＯアプリケーションに対してログアウトが送信される。これによって即時性を保証するとともに、クライアントがアクセスしたＳＳＯアプリケーションのみにしかログアウトを送信しないことによって、ネットワーク４などに対する負荷を最小限にとどめることができる。さらに、ログアウトについてもＳＳＯサーバ１からＳＳＯアプリケーションに通知されるため、ＳＳＯアプリケーションから定期的に、あるいはクライアントからのアクセス時毎にＳＳＯサーバ１へ尋ねる必要もなく、この点でも即時性及び負荷の軽減に寄与することができる。
【００７１】
ＳＳＯサーバ１からログアウトを受け取ったＳＳＯアプリケーション２では、（３５）において、クライアント５のログイン状態情報をログアウトの状態（例えば“ゲスト”）に更新する。そしてＳＳＯアプリケーション２は、ログアウト後のページを（３６）においてクライアント５に送る。以後、クライアント５はログインしていない“ゲスト”として扱われる。
【００７２】
また、ＳＳＯアプリケーション３においても、ＳＳＯサーバ１からクライアント５のログアウトを受け取る。そしてＳＳＯアプリケーション３のログイン状態情報データベースについても更新される。これによって、クライアント５がＳＳＯアプリケーション２に対してログアウトを行うだけで、ＳＳＯアプリケーション３についてもログアウトを行ったのと同等のサービスを受けることができるようになり、ＳＳＯの機能を実現することができる。
【００７３】
なお、（３１）においてＳＳＯアプリケーション２がクライアント５からログアウトの要求を受け取ったとき、クライアント５がローカルユーザとしてログインしている場合にはＳＳＯアプリケーション２においてログアウトの処理を行い、ＳＳＯサーバ１へのログアウトの要求の転送を行わないように制御すればよい。また、通知を受けるＳＳＯアプリケーションにおいて、クライアントはローカルユーザとしてログインしており、かつそのＳＳＯアプリケーションがローカルユーザを優先する方針であれば、ＳＳＯサーバからログイン状態情報変更の通知を受け取ったとしても、クライアントのログイン状態をログアウト状態へ更新する必要はない。
【００７４】
上述の動作の説明では、ＳＳＯアプリケーション２，３及びＳＳＯサーバ１においてクライアントに対して割り当てたクライアント識別情報（ｃｉｄ，ｓｉｄ）に対する有効期限については説明していないが、例えばログインしたら永続的にそのログインの状態を続けるのであれば、有効期限を設定しなければよい。あるいは、無期限の設定を行えばよい。
【００７５】
もちろん有効期限を設定することもでき、その場合には、例えばそれぞれのＳＳＯアプリケーション及びＳＳＯサーバにおいて期限管理を行えばよい。あるいは、ＳＳＯアプリケーション及びＳＳＯサーバがクライアントに対して発行した情報（例えばクッキー）に有効期限を設定しておき、クライアントからのアクセスを有効期限内に制限することもできる。有効期限としては、例えば時間を設定したり、例えばセッションの終了までなどといった特定の事象の発生までの期限を設定することもできる。
【００７６】
このような有効期限は、ユーザの利用を制限するほか、クライアント識別情報（ｃｉｄ，ｓｉｄ）の漏洩による不正アクセスの防止にも利用することができる。例えばＳＳＯサーバにおけるクライアント識別情報（ｓｉｄ）に有効期限を設けず、ＳＳＯアプリケーションにおけるクライアント識別情報（ｃｉｄ）に有効期限を設けておく。そして、ＳＳＯアプリケーションにおけるクライアント識別情報（ｃｉｄ）の有効期限切れの後にクライアントからＳＳＯアプリケーションにアクセスされ、ＳＳＯサーバに問い合わせが行われた際に、ＳＳＯサーバにおけるクライアント識別情報（ｓｉｄ）を更新する。これによって、ＳＳＯサーバにおけるログイン状態は保ったまま、クライアント識別情報（ｓｉｄ）を変更してゆくことができる。従ってクライアント識別情報（ｓｉｄ）が漏洩しても永続的に利用できないため、不正アクセスを低減することができる。
【００７７】
【発明の効果】
以上の説明から明らかなように、本発明によれば、ＳＳＯを実現するとともにログイン状態の変更にも対応し、またそのログイン状態をサービス側で自由に制御することができ、さらに特別なポータルサイトを必要としないネットワークシステムを提供することができる。また、クライアントがアクセスしたサービスに関する情報をアクセス管理サーバに保持しておき、ログイン状態の変更時にはクライアントがアクセスしたことのあるサービスに対してログイン状態の変更を通知するようにしたので、ログイン状態の変更が即時に行われるとともに、ネットワークに対する負荷を軽減し、パフォーマンスへの影響を最小限に抑えることができるという効果がある。
【図面の簡単な説明】
【図１】本発明の実施の一形態を示すシステム構成図である。
【図２】ＳＳＯサーバが保持する情報の一例の説明図である。
【図３】ＳＳＯアプリケーションが保持するログイン状態情報の一例の説明図である。
【図４】クライアントからＳＳＯアプリケーションへの初回のアクセス時の動作の一例を示すシーケンス図である。
【図５】クライアントから別のＳＳＯアプリケーションへアクセスした時の動作の一例を示すシーケンス図である。
【図６】クライアントからＳＳＯアプリケーションへログイン要求を行ったときの動作の一例を示すシーケンス図である。
【図７】クライアントからＳＳＯアプリケーションへログアウト要求を行ったときの動作の一例を示すシーケンス図である。
【符号の説明】
１…ＳＳＯサーバ、２，３…ＳＳＯアプリケーション、４…ネットワーク、５〜７…クライアント、１１…通信制御部、１２…ＳＳＯアクセス情報データベース、１３…ログイン状態情報データベース、１４…ユーザ認証情報データベース、２１…通信制御部、２２…処理部、２３…ログイン状態情報データベース。
【発明の属する技術分野】
本発明は、クライアントが複数のサービスを利用する際のアクセス管理技術に関するものであり、特に、一度認証するだけで認証が必要な複数のサービスを利用可能とするシングルサインオン（以下ＳＳＯ）機能に適用可能なアクセス管理技術に関するものである。
【０００２】
【従来の技術】
クライアントがネットワークを通じてサービスを利用する場合、そのサービスを利用する権限を有していることを確認するため、ユーザ名やパスワード等の入力によるサインを行う。ユーザの利用権限のチェックはそれぞれのサービスごとに必要となるため、旧来はそれぞれのサービスを利用する毎にユーザはサインを行っていた。しかし、利用するサービスが複数存在する場合、いちいちサインを行うのは手間がかかる。このようなユーザの手間を軽減するため、クライアントがただ一度のサイン（ユーザ名，パスワード等の入力）を行うことで複数のサービスの利用を可能にしたシングルサインオンの技術が開発されている。
【０００３】
シングルサインオンを実現する従来の方法の一つとして、例えばクライアント側で用いているブラウザにおいて、アプリケーション毎のサイン（ユーザ名，パスワード）を保持する方法がある。しかし、このような機能を有していないブラウザもあり、汎用的に利用できる技術ではない。
【０００４】
別の方法として、例えば特許文献１に記載されているように、クライアントからのアクセスを受け付けるＷｅｂサーバを設け、このＷｅｂサーバを通じて各種のサービスを提供する方法がある。この場合、Ｗｅｂサーバに対して１回のサイン（ユーザ名，パスワード入力）のみで、各種のサービスを利用することが可能である。また、クライアントのログイン状態はすべてＷｅｂサーバにおいて一元管理することができる。
【０００５】
しかし、ＷｅｂサーバやＳＳＯに参加している各サーバが利用するクライアント識別情報は同一であることを前提としているため、例えばＷｅｂアプリケーションに適用しようとした場合、必ずポータル的なサーバが必要となる。そのため、すでにネットワーク上にサーバが構成されている場合、導入への大きな障害となる。また、クライアントからの要求はすべてＷｅｂサーバを通過しなければならないため、パフォーマンスへの影響も大きい。
【０００６】
別の方法として、例えば特許文献２に記載されているように、複数の認証が必要なＷＷＷサーバのうち、一つのＷＷＷサーバにおいて認証を行えば、そのＷＷＷサーバから他のサーバへ認証済み情報が通知される技術がある。この技術では、認証が行われたときに、その旨を他のすべてのＷＷＷサーバへ通知する。そのため、それぞれのＷＷＷサーバが通知先となる全てのＷＷＷサーバの情報を保持している必要がある。また、クライアントがアクセスしたか否かによらず、全てのＷＷＷサーバへ認証済みである旨を通知するため、通知によるトラフィック量が増大し、パフォーマンスへの影響が大きいという問題がある。
【０００７】
さらに別の方法として、特願２００２−９５７５５号公報に記載されている技術においても、ＳＳＯサーバにおいてクライアント識別情報とそのクライアントの認証情報を一元管理し、ＳＳＯを実現している。この技術では、クライアントからのアクセスを受けたＷＷＷアプリケーションがＳＳＯサーバに問い合わせ、また、ＷＷＷアプリケーションがＳＳＯサーバから認証状況を受け取った後は、クライアントとＷＷＷアプリケーションの間で通信を行うので、特定のサーバにアクセスが集中することもなく、パフォーマンスの影響は小さい。
【０００８】
しかしこの技術では、ログイン状態を決定する情報をクライアントから受け取るのは、ログイン状態を管理しているサーバ（ＳＳＯサーバ）である。そのため、例えばＤｏｃｕＳｈａｒｅ（登録商標）のように各々のサーバがログイン状態を管理し、またそれぞれのサーバが認証機能を有してクライアントからの要求により認証方法を切り替えるといった制御を行っているシステムをＳＳＯに参加させることはできない。また、この技術では、ＳＳＯに参加しているサーバがＳＳＯサーバへクライアントのログイン状態を問い合わせるのは最初の接続時のみであり、その後のログイン状態の変化を反映することができない。そのため、クライアントのログイン状態が自由に変更可能なシステムにおいては、ログイン状態の統一を保つことができないという問題があった。
【０００９】
【特許文献１】
特開２０００−１０６５５２号公報
【特許文献２】
特開２００２−２８８１３８号公報
【００１０】
【発明が解決しようとする課題】
本発明は、上述した事情に鑑みてなされたもので、ＳＳＯに参加しているサービス毎に自由にログイン状態の制御が可能であるとともに、そのクライアントのログイン状態の変更を、パフォーマンスへの影響を最小限に抑えながらも、即時に他のサービスへも反映することができ、さらに特別なポータルを必要としないネットワークシステムを提供するとともに、そのようなネットワークシステムにおいて利用可能なアクセス管理サーバ及びネットワーク装置と、アクセス管理方法を提供することを目的とするものである。
【００１１】
【課題を解決するための手段】
本発明は、クライアントに対して提供されるサービスへの前記クライアントのアクセスを管理するアクセス管理サーバ及びアクセス管理方法において、通信制御手段は、クライアントが新たなサービスにアクセスするたびに、そのクライアントがアクセスしたサービスの情報をアクセス情報としてアクセス情報保持手段に保持し、クライアントのログイン状態の変更時には、アクセス情報保持手段に保持しておいたアクセス情報に従って、クライアントがアクセスしたサービスに対してログイン状態情報の変更を通知することを特徴とするものである。さらにクライアントのログイン状態に関するログイン状態情報をログイン状態情報保持手段に保持しておき、既にアクセス済のクライアントが他のサービスに新たにアクセスしたときには、ログイン状態情報に従って、他のサービスに対してログイン状態を通知し、ログイン状態の変更時にはログイン状態情報保持手段中のログイン状態情報の更新も行うように構成することができる。
【００１２】
例えばクライアントがいくつかのサービスに対してアクセスした場合には、それぞれのサービスに対してアクセスした旨をアクセス情報として保持しておく。そして、ログイン状態の変更としてサービスに対するログイン要求を受け付けた場合には、必要に応じてクライアントの認証を行い、あるサービスに対するログインの許可を他のアクセス済のサービスに対して通知する。また、例えばログイン状態の変更としてサービスに対するログアウト要求を受け付けた場合には、あるサービスに対するログアウトを他のアクセス済のサービスに対して通知すればよい。
【００１３】
このような構成によって、ログイン状態の変更に対応することができるとともに、ログイン状態の変更時にはそれまでクライアントがアクセスしたサービスに対してのみ、即時に通知するので、トラフィック量を低減してパフォーマンスへの影響を最小限に抑えながら、即時性を保証することができる。
【００１４】
なお、上述のようなクライアントからのアクセスあるいはサービスからのクライアントに関する問い合わせのアクセスに対して、それぞれのクライアント毎に有効期限を定めておくことができる。もちろん、有効期限を定めなくてもよい。
【００１５】
また本発明は、上述のようなアクセス管理サーバを利用し、ネットワークを通じて行われるクライアントからの要求に応じてサービスを提供するネットワーク装置において、クライアントのログイン状態に関するログイン状態情報をログイン状態情報保持手段に保持に保持しておき、クライアントからのアクセスを受けた際に、ログイン状態情報保持手段が保持するログイン状態情報を調べ、新たなクライアントからのアクセスである場合、あるいは、ログイン状態の変更を要求するアクセスの場合にはアクセス管理サーバに通知し、アクセス管理サーバからの通知に応じてログイン状態情報保持手段へのログイン状態情報の登録又はログイン状態情報の更新を行うことを特徴とするものである。
【００１６】
なお、ログイン状態の変更を要求したクライアントがサービスに対するローカルユーザである場合には、アクセス管理サーバへの問い合わせを行わずにログイン状態の変更を行うように構成することができる。このように、アクセス管理サーバによるログイン状態の管理に束縛されずに、それぞれのネットワーク装置が自由にログイン状態の制御が可能である。
【００１７】
また、サービスを提供するネットワーク装置の側でも、クライアント毎にアクセスの有効期限を定めることができる。もちろん、有効期限を定めなくてもよい。
【００１８】
さらに本発明は、ネットワークを通じて行われるクライアントからの要求に応じてサービスを提供するネットワーク装置と、ネットワークを通じて前記クライアントのアクセスを管理するアクセス管理サーバを含むネットワークシステムであって、ネットワーク装置は、クライアントから新たなアクセスを受けた際にアクセス管理サーバに通知し、アクセス管理サーバは、ネットワーク装置からの新たなアクセスを受けた際の通知に従いアクセス情報を保持する。そして、ネットワーク装置がクライアントからログイン状態の変更を要求された場合には、ログイン状態の変更の要求をアクセス管理サーバに送り、前記アクセス管理サーバはそれまでに保持されている当該クライアントに対応するアクセス情報に従って１ないし複数のネットワーク装置に対してログイン状態の変更を通知することを特徴とするものである。
【００１９】
例えばネットワーク装置がクライアントからログインの要求を受けたときには、アクセス管理サーバは必要に応じてクライアントの認証を行って、当該クライアントに対応するログイン状態情報をログインしている旨に変更するとともに、それまでに当該クライアントがアクセスした１ないし複数のネットワーク装置に対してログイン状態情報の変更を通知する。これによって、他のネットワーク装置においても当該クライアントをログイン済として扱うことができる。
【００２０】
また、ネットワーク装置がクライアントからログアウトの要求を受けたとき、アクセス管理サーバは当該クライアントに対応するログイン状態情報をログアウトの状態に変更するとともに、それまでに当該クライアントがアクセスした１ないし複数のネットワーク装置に対してログイン状態情報の変更を通知する。これによって、他のネットワーク装置においても当該クライアントがログアウトしたものとして扱うことができる。
【００２１】
このようなネットワークシステムおいては、ログイン状態の変更に容易に対応することができるとともに、ログイン状態の変更時にはそれまでクライアントがアクセスしたサービスに対してのみ、即時に通知するので、トラフィック量を低減してパフォーマンスへの影響を最小限に抑えながら、即時性を保証することができる。
【００２２】
【発明の実施の形態】
図１は、本発明の実施の一形態を示すシステム構成図である。図中、１はＳＳＯサーバ、２，３はＳＳＯアプリケーション、４はネットワーク、５〜７はクライアント、１１は通信制御部、１２はＳＳＯアクセス情報データベース、１３はログイン状態情報データベース、１４はユーザ認証情報データベース、２１は通信制御部、２２は処理部、２３はログイン状態情報データベースである。図１に示す例では、ＳＳＯサーバ１、ＳＳＯアプリケーション２，３、クライアント５〜７などがネットワーク４を利用して通信可能に構成されている。もちろん、多くのクライアント、多くのＳＳＯアプリケーション、その他多くのサーバ等と通信可能である。ネットワーク４は、ＬＡＮやインターネットなど、各種のネットワークで構成することができ、またそれらが複合的に組み合わされた構成であってよい。
【００２３】
ＳＳＯサーバ１は、クライアント５〜７からＳＳＯアプリケーション２，３に対するアクセス及びログイン状態を管理するアクセス管理サーバとして機能する。クライアントが新たなＳＳＯアプリケーションに対してアクセスする度にクライアントとアクセスしたＳＳＯアプリケーションの情報をＳＳＯアクセス情報としてＳＳＯアクセス情報データベース１２に保持しておく。また、管理しているログイン状態の情報をログイン状態情報データベース１３に格納しており、このログイン状態情報を用いてＳＳＯアプリケーション２，３からのログイン状態の問い合わせに応じることでＳＳＯ機能を提供する。さらに、ログイン状態の変更時には、必要に応じてクライアントの認証を行うとともに、ＳＳＯアクセス情報として登録されているそれまでにクライアントがアクセスしたＳＳＯアプリケーションに対してログイン状態の変更を通知する。ログイン状態の変更としては、ログイン前のゲストからユーザアカウントへのログイン、及び、ログインの状態からのログアウトなどがある。
【００２４】
この例ではＳＳＯサーバ１は、通信制御部１１、ＳＳＯアクセス情報データベース１２、ログイン状態情報データベース１３、ユーザ認証情報データベース１４などを含んで構成されている。通信制御部１１は、ネットワーク４を通じてＳＳＯアプリケーション２，３やクライアント５〜７等との通信を行うとともに、上述のようなＳＳＯサーバ１における機能を実現する。
【００２５】
ＳＳＯアクセス情報データベース１２は、クライアントがアクセスしたＳＳＯアプリケーションに関するアクセス情報を保持する。またログイン状態情報データベース１３は、それぞれのクライアントごとに、クライアントのログイン状態に関するログイン状態情報を保持する。さらにユーザ認証情報データベース１４は、クライアントの認証情報を保持する。
【００２６】
図２は、ＳＳＯサーバが保持する情報の一例の説明図である。図２（Ａ）に示すＳＳＯアクセス情報データベース１２に格納するアクセス情報は、ＳＳＯサーバにおけるクライアント識別情報（以下、ｓｉｄと呼ぶことがある）と、クライアントがアクセスしたＳＳＯアプリケーションの名称などの識別情報と、当該ＳＳＯアプリケーションにおけるクライアント識別情報（以下、ｃｉｄと呼ぶことがある）から構成されている。このようなアクセス情報を、クライアント毎、ＳＳＯアプリケーション毎に格納する。
【００２７】
また図２（Ｂ）に示すログイン状態情報データベース１３に格納するログイン状態情報は、ＳＳＯサーバにおけるクライアント識別情報（ｓｉｄ）と、ログイン状態から構成されている。ログイン状態には、例えば３行目に示しているように“ｇｕｅｓｔ”でＳＳＯアプリケーション２，３にアクセスしている状態か、１，２行目に示しているように“ｕｓｅｒ−Ａ”や“ｕｓｅｒ−Ｂ”といったユーザＩＤのアカウントによりログインした状態か、等を示す情報が格納されている。
【００２８】
さらに図２（Ｃ）に示すユーザ認証情報データベース１４に格納するユーザ認証情報は、ユーザＩＤと、対応する認証情報（例えばパスワードなど）によって構成されている。クライアントからログイン要求を受けたとき、ユーザＩＤと認証情報を用いて認証を行うことができる。
【００２９】
なお、それぞれのデータベースに格納する情報は図２に示した情報に限られるものではなく、それぞれの機能が果たせればどのような情報であってもよいし、他の種々の情報を含んでいてもよい。また、ＳＳＯアクセス情報データベース１２、ログイン状態情報データベース１３、ユーザ認証情報データベース１４は、この例ではＳＳＯサーバ１内に設けているが、これに限らず、その一部又は全部をＳＳＯサーバ１とは別のサーバにより構成することも可能である。
【００３０】
ＳＳＯアプリケーション２，３は、クライアントに対して各種のサービスを提供する。ＳＳＯアプリケーション２，３は、例えばコンピュータなどのネットワーク装置（サーバ）で構成することができる。なお、１台のネットワーク装置（サーバ）が複数のサービスを提供することもあるし、複数台のネットワーク装置が協働して１つのサービスを提供することもある。ここでは、ＳＳＯアプリケーション２，３は、クライアントに対して提供されるサービスに対応するものとして示している。なお、ＳＳＯアプリケーション２，３は、それぞれがローカルユーザのための認証機構を有しており、ユーザの認証を独自で行うことができる。認証を独自で行うか、あるいはＳＳＯサーバに任せるかは、それぞれのＳＳＯアプリケーション２，３が判断して行う。従って、ログイン状態の制御をＳＳＯアプリケーションにおいて行うことができる。
【００３１】
ＳＳＯアプリケーション２は、通信制御部２１、処理部２２、ログイン状態情報データベース２３を含んで構成されている。ＳＳＯアプリケーション３については図示していないが、同様の構成を含んで構成することができる。処理部２２は、実際にサービスを提供する部分である。
【００３２】
通信制御部２１は、ネットワーク１を通じてクライアント５〜７及びＳＳＯサーバ１などとの通信を行い、ＳＳＯアプリケーション２における処理部２２で行うサービスのための処理以外の様々な処理を行う。例えばクライアントからのアクセスを受け付け、ログイン状態情報データベース２３が保持するログイン状態情報を調べ、新たなクライアントからのアクセスである場合には、ＳＳＯサーバ１に対して問い合わせを行い、ログイン状態情報を受け取ってログイン状態情報を登録する。このとき、既に他のＳＳＯアプリケーションでログイン済であり、ＳＳＯ機能によりログインを許可する場合には、このＳＳＯアプリケーション２においてもログイン済として扱う。また、例えばゲストとしてアクセスしているクライアントからログイン要求を受けたり、ログイン中のクライアントからログアウト要求を受けるなど、ログイン状態を変更する要求を受けた場合には、ローカルなユーザであれば自装置内で処理し、そうでなければＳＳＯサーバ１に依頼する。さらに、ＳＳＯサーバ１からクライアントのログイン状態情報の変更が通知された場合には、当該通知に基づいてログイン状態情報の更新を行う。当然、ＳＳＯアプリケーション毎のクライアント管理の方針によりログイン状態情報の更新を行わなくても良い。（例えば、ローカルユーザのログイン状態を優先する方針であれば、ＳＳＯサーバ１からの通知では、ログイン状態を更新しない等。）
【００３３】
ログイン状態情報データベース２３は、それぞれのクライアントのログイン状態に関する情報であるログイン状態情報を保持している。図３は、ＳＳＯアプリケーションが保持するログイン状態情報の一例の説明図である。このログイン状態情報は、図２（Ｂ）に示したＳＳＯサーバ１が保持するログイン状態情報と同様であり、ＳＳＯアプリケーション２におけるクライアント識別情報（ｃｉｄ）とログイン状態を保持している。このログイン状態情報は、ＳＳＯアプリケーション２においてローカルなユーザについてのログイン状態情報についても保持しておくことができる。なお、ログイン状態情報は、図３に示した構成に限られるものではない。また、このログイン状態情報データベース２３はＳＳＯアプリケーションとは別に設けることも可能である。
【００３４】
なおクライアント５〜７は、コンピュータや携帯端末、携帯電話をはじめ、様々なネットワーク機器で構成することができる。
【００３５】
次に、本発明の実施の一形態における動作について説明する。なお、以下の動作の説明では、利用するプロトコルはＨＴＴＰとして説明する。図４は、クライアントからＳＳＯアプリケーションへの初回のアクセス時の動作の一例を示すシーケンス図である。ここではクライアント５がＳＳＯにより利用可能なＳＳＯアプリケーション群へのはじめてのアクセスとして、ＳＳＯアプリケーション２に対してアクセスを行ったものとする。クライアントは（１）において、ＳＳＯアプリケーション２のホームページなどのアドレス（ｕｒｌ）を指定してアクセスする。
【００３６】
ＳＳＯアプリケーション２は、クライアント５からのアクセスを受けると、クライアント５が既にＳＳＯアプリケーション２にアクセスを行っているか否かを調べる。これは、例えばクライアント５からＳＳＯアプリケーション２が発行した情報（例えばクッキー）の提示があるか否かを判定したり、あるいは、ログイン状態情報データベース２３に格納されているログイン状態情報を調べることによって行うことができる。
【００３７】
クライアント５からの新規のアクセスであることを確認したら、（２）において、クライアント５に対してクライアント識別情報（ｃｉｄ）を割り当てる。そして、ログイン状態情報として、クライアント識別情報（ｃｉｄ）と、まだログインしていない状態であることを示すログイン状態“ゲスト”を対応付けてログイン状態情報データベース２３に格納する。さらに、一時的な識別子（ｏｉｄ）をクライアント識別情報（ｃｉｄ）と対応付けて保持しておく。そしてＳＳＯアプリケーション２は、（３）において、クライアント５に対してリダイレクションによってＳＳＯサーバ１へのアクセスを指示する。このとき、ＳＳＯサーバ１のアドレスとともに、ＳＳＯアプリケーション２のアドレス（ＳＳＯＡｐｐ）と一時的な識別子（ｏｉｄ）を送る。
【００３８】
クライアント５では、リダイレクションの指示をＳＳＯアプリケーション２から受け取ると、自動的に、あるいはユーザの指示に従い、（４）において、送られてきたＳＳＯサーバのアドレスを用いてＳＳＯサーバ１へのアクセスが行われる。この時、同じく送られてきたＳＳＯアプリケーション２のアドレス（ＳＳＯＡｐｐ）と一時的な識別子（ｏｉｄ）についてもＳＳＯサーバ１へ送る。
【００３９】
ＳＳＯサーバ１では、クライアント５からのアクセスを受けると、クライアント５が既にＳＳＯサーバ１（すなわちＳＳＯアプリケーションのいずれか）にアクセスを行っているか否かを調べる。これは、例えばクライアント５からＳＳＯサーバ１が発行した情報（例えばクッキー）の提示があるか否かを判定したり、あるいは、ログイン状態情報データベース１３に格納されているログイン状態情報を調べることによって行うことができる。
【００４０】
クライアント５からの新規のアクセスであることを確認したら、（５）において、クライアント５に対してクライアント識別情報（ｓｉｄ）を割り当てる。そして、ログイン状態情報として、クライアント識別情報（ｓｉｄ）と、まだログインしていない状態であることを示すログイン状態“ゲスト”を対応付けてログイン状態情報データベース２３に格納する。さらに、（６）において、ＳＳＯサーバ１はＳＳＯアプリケーション２に対して、クライアント５から送られてきたＳＳＯアプリケーション２のアドレス（ＳＳＯＡｐｐ）及び一時的な識別子（ｏｉｄ）をもとに、ＳＳＯアプリケーション２におけるクライアント識別情報（ｃｉｄ）を要求する。
【００４１】
ＳＳＯサーバ１からの要求を受け取ったＳＳＯアプリケーション２では、（７）において、送られてきた一時的な識別子（ｏｉｄ）をもとに、関連づけられているクライアント識別情報（ｃｉｄ）を取得し、一時的な識別子（ｏｉｄ）とクライアント識別情報（ｃｉｄ）との関連づけを消す。そして（８）において、ＳＳＯアプリケーション２におけるクライアント識別情報（ｃｉｄ）をＳＳＯサーバ１へ送る。
【００４２】
ＳＳＯサーバ１では、ＳＳＯアプリケーション２から送られてきたクライアント識別情報（ｃｉｄ）を受け取ると、（９）において、ＳＳＯサーバ１におけるクライアント識別情報（ｓｉｄ）と、ＳＳＯアプリケーション２を識別する情報（例えばＳＳＯアプリケーション２のアドレス（ＳＳＯＡｐｐ）など）と、ＳＳＯアプリケーション２におけるクライアント識別情報（ｃｉｄ）とを対応付けてアクセス情報としてＳＳＯアクセス情報データベース１２に格納する。ＳＳＯサーバ１は、アクセス情報の登録が終了した後、クライアント５が初回のアクセスであった場合には、（１０）において、ＳＳＯアプリケーション２にアクセスを戻すため、ＳＳＯアプリケーション２のアドレス（ＳＳＯＡｐｐ）を指定したリダイレクションをクライアント５に指示する。この時、以後、ＳＳＯサーバ１にアクセスする際に用いる情報（例えばクッキーなど）をクライアント５へ送っておく。
【００４３】
クライアント５では、リダイレクションの指示をＳＳＯサーバ１から受け取ると、自動的に、あるいはユーザの指示に従い、（１１）において、送られてきたＳＳＯアプリケーションのアドレス（ＳＳＯＡｐｐ）を用いてＳＳＯアプリケーション２へのアクセスが行われる。
【００４４】
ＳＳＯアプリケーション２は、クライアント５からのアクセスを受け取ると、（１２）において、今度はクライアント５にクライアント識別情報（ｃｉｄ）が割り当てられているので、これをもとにログイン状態情報データベース２３に格納されているログイン状態情報を取得し、クライアント５のログインの状態を調べる。ここではクライアント５のログイン状態は“ゲスト”である。要求されているページが“ゲスト”のログイン状態で参照可能であることを確認後、（１３）において、要求されているページをクライアント５へ送る。
【００４５】
このようにして、（１）で要求したページがクライアント５において表示され、ユーザが参照することができる。以後、ＳＳＯアプリケーション２において“ゲスト”のログイン状態で参照可能なページについては、クライアント５からの要求に応じて、ＳＳＯアプリケーション２が当該ページを送ることによって、やりとりが行われる。
【００４６】
図５は、クライアントから別のＳＳＯアプリケーションへアクセスした時の動作の一例を示すシーケンス図である。ここではクライアント５が上述のようにしてＳＳＯアプリケーション２にアクセスした後に、ＳＳＯアプリケーション３に対してアクセスを行ったものとする。なお、図４で説明した初回のアクセス時と同様の部分には同じ符号を付して概略のみを説明する。
【００４７】
クライアント５が（１）においてＳＳＯアプリケーション３にアクセスすると、ＳＳＯアプリケーション３は、クライアント５が既にＳＳＯアプリケーション３にアクセスを行っているか否かを調べる。ここでは、クライアント５はＳＳＯアプリケーション２に対しては既にアクセスを行っているものの、ＳＳＯアプリケーション３に対しては初回のアクセスとなる。
【００４８】
ＳＳＯアプリケーション３は、クライアント５からの新規のアクセスであることを確認したら、（２）において、クライアント５に対するクライアント識別情報（ｃｉｄ）の割り当てと、ログイン状態情報の生成及びログイン状態情報データベースへの格納を行う。さらに、一時的な識別子（ｏｉｄ）をクライアント識別情報（ｃｉｄ）と対応付けて保持しておく。そして（３）において、クライアント５に対してリダイレクションによってＳＳＯサーバ１へのアクセスを指示する。クライアント５は、リダイレクションの指示を受け、（４）において、ＳＳＯサーバ１へのアクセスを行う。
【００４９】
ＳＳＯサーバ１では、クライアント５からのアクセスを受けると、（５’）において、クライアント５が既にＳＳＯサーバ１（すなわちＳＳＯアプリケーションのいずれか）にアクセスを行っているか否かを調べる。ここでは既にＳＳＯアプリケーション２にアクセスしたときにＳＳＯサーバ１へのアクセスを行っている。従って、ログイン状態情報データベース１３にクライアント５のログイン状態情報が格納されている。また、例えばＳＳＯサーバ１が例えばクッキー等の情報を発行している場合には、クライアント５からＳＳＯサーバ１が発行した例えばクッキー等の情報が提示される。なお、クライアント５が既に他のＳＳＯアプリケーションにアクセスしている場合には、新たなクライアント識別情報（ｓｉｄ）の割り当てや新たなログイン状態情報の生成及び登録などは行わない。
【００５０】
ＳＳＯサーバ１は、（６）において、ＳＳＯアプリケーション３に対して一時的な識別子（ｏｉｄ）をもとに、ＳＳＯアプリケーション３におけるクライアント識別情報（ｃｉｄ）を要求する。この要求に対して、ＳＳＯアプリケーション３では、（７）において、送られてきた一時的な識別子（ｏｉｄ）をもとに、関連づけられているクライアント識別情報（ｃｉｄ）を取得し、一時的な識別子（ｏｉｄ）とクライアント識別情報（ｃｉｄ）との関連づけを消す。そして（８）において、ＳＳＯアプリケーション３におけるクライアント識別情報（ｃｉｄ）をＳＳＯサーバ１へ送る。
【００５１】
ＳＳＯサーバ１では、ＳＳＯアプリケーション３から送られてきたクライアント識別情報（ｃｉｄ）を受け取ると、（９）において、ＳＳＯサーバ１におけるクライアント識別情報（ｓｉｄ）と、ＳＳＯアプリケーション３を識別する情報（例えばＳＳＯアプリケーション３のアドレス（ＳＳＯＡｐｐ）など）と、ＳＳＯアプリケーション３におけるクライアント識別情報（ｃｉｄ）とを対応付けてアクセス情報としてＳＳＯアクセス情報データベース１２に格納する。このようにして、同じクライアント５であっても、異なるＳＳＯアプリケーションにアクセスした場合には新たなアクセス情報が生成され、登録される。従ってクライアント５がいずれのＳＳＯアプリケーションにアクセスしたかがアクセス情報として蓄積されることになる。
【００５２】
ＳＳＯサーバ１は、アクセス情報の登録が終了した後、（１０’）において、ＳＳＯアプリケーション３に対して、ログイン状態情報データベース１３に格納されているクライアント５に対応するログイン状態情報（ｓｔａｔｕｓ）を、ＳＳＯアプリケーション３におけるクライアント５のクライアント識別情報（ｃｉｄ）とともに送る。この通知を受けたＳＳＯアプリケーション３では、（１２’）において、ログイン状態情報データベース２３に格納されているクライアント５に対応するログイン状態情報を、受け取ったログイン状態情報に書き換える。そして（１３）において、要求されているページをクライアント５へ送る。
【００５３】
この例では、先にＳＳＯアプリケーション２に対して“ゲスト”としてアクセスしているので、ＳＳＯサーバ１からＳＳＯアプリケーション３に対してログイン状態が“ゲスト”である旨が通知され、ＳＳＯアプリケーション３におけるクライアント５に対するログイン状態情報は“ゲスト”のままである。例えば後述するログイン状態の変更要求がなされ、ユーザＩＤなどによってログインされた状態の場合には、その旨がＳＳＯサーバ１からＳＳＯアプリケーション３に通知され、ＳＳＯアプリケーション３においても通知されたユーザＩＤによってログインされた状態となる。これによって、クライアント５から改めてＳＳＯアプリケーション３に対してログインを行わなくても、ＳＳＯアプリケーション３にログインしているものとしてＳＳＯアプリケーション３のサービスを受けることができ、ＳＳＯを実現することができる。
【００５４】
次に、ログイン状態の変更を要求された場合の動作について説明する。ログイン状態の変更としては、ユーザＩＤによるログインやログアウトなどがある。まずログイン時の動作について説明する。
【００５５】
図６は、クライアントからＳＳＯアプリケーションへログイン要求を行ったときの動作の一例を示すシーケンス図である。ここではクライアント５がＳＳＯアプリケーション２にログイン要求を行うものとし、これまでにクライアント５はＳＳＯアプリケーション２，３に対してアクセスを行っているものとする。すなわち、ＳＳＯサーバ１にはアクセス情報として、ＳＳＯアプリケーション２へのアクセス時のアクセス情報とＳＳＯアプリケーション３へのアクセス時のアクセス情報がＳＳＯアクセス情報データベース１２に格納されているものとする。
【００５６】
クライアント５は、ログインを要求するために、ここではＳＳＯアプリケーション２に対して（２１）においてログインフォームを要求し、ＳＳＯアプリケーション２は、この要求に応じて（２２）においてログインフォームをクライアント５に送る。クライアント５では、送られてきたログインフォームにユーザＩＤやパスワードなどの所定事項を入力し、その内容をログイン情報として、（２３）においてＳＳＯアプリケーション２に送る。
【００５７】
ＳＳＯアプリケーション２は、クライアント５からログイン情報を受け取ると、その内容をチェックした後、（２４）においてクライアント５のクライアント識別情報（ｃｉｄ）とともにログイン情報をＳＳＯサーバ１へ送る。
【００５８】
ＳＳＯサーバ１では、ＳＳＯアプリケーション２からクライアント識別情報（ｃｉｄ）及びログイン情報を受け取ると、（２５）において、ユーザ認証情報データベース１４に格納されているユーザ認証情報を用いて認証を行う。認証に成功したら、ＳＳＯアプリケーション２におけるクライアント識別情報（ｃｉｄ）をもとにＳＳＯサーバ１におけるクライアント識別情報（ｓｉｄ）を特定し、ログイン状態情報データベース１３に格納されているクライアント５のログイン状態情報を更新する。さらに（２６）において、ＳＳＯサーバ１におけるクライアント識別情報（ｓｉｄ）をもとにＳＳＯアクセス情報データベース１２を検索し、それまでクライアント５がアクセスしたＳＳＯアプリケーションを特定する。
【００５９】
そして（２７）において、（２６）で特定したＳＳＯアプリケーションに対して、それぞれ、ログイン状態情報（ｓｔａｔｕｓ）をそれぞれのＳＳＯアプリケーションにおけるクライアント識別情報（ｃｉｄ）とともに送る。クライアント５がＳＳＯアプリケーション２，３にアクセスしていた場合、図中（２７）として示すＳＳＯアプリケーション２へのログイン状態情報の送信とともに、ＳＳＯアプリケーション３に対してもログイン状態情報が送信される。これを（２７’）として示している。
【００６０】
このように、ログインが行われてログイン状態が更新される場合には、ＳＳＯアクセス情報データベース１２に蓄積されている、クライアントがそれまでにアクセスしたすべてのＳＳＯアプリケーションに対して更新後のログイン状態情報が送信される。これによって即時性を保証する。しかし、ＳＳＯアプリケーションが多数存在する場合でも、クライアントがアクセスしたＳＳＯアプリケーションのみにしかログイン状態情報を送信しないため、ネットワーク４などに対する負荷を最小限にとどめることができる。さらに、ログイン状態の変更はＳＳＯサーバ１から通知されるため、ＳＳＯアプリケーションから定期的に、あるいはクライアントからのアクセス時毎にＳＳＯサーバ１へ尋ねる必要もなく、この点でも即時性及び負荷の軽減に寄与することができる。
【００６１】
ＳＳＯサーバ１からログイン状態情報を受け取ったＳＳＯアプリケーション２では、（２８）において、受け取ったログイン状態情報に従ってログイン状態情報データベース２３を更新し、クライアント５はＳＳＯアプリケーション２にログインした状態に変更される。そしてＳＳＯアプリケーション２は、ログイン後のページを（２９）においてクライアント５に送る。以後、クライアント５はログインしたユーザとして扱われ、ログインユーザのみに許されるページなどの参照が可能となる。
【００６２】
また、ＳＳＯアプリケーション３においても、ＳＳＯサーバ１からクライアント５のログイン状態情報を受け取る。そしてＳＳＯアプリケーション３のログイン状態情報データベースについても更新される。これによって、クライアント５がＳＳＯアプリケーション２に対してログインを行うだけで、ＳＳＯアプリケーション３についてもログインを行ったのと同等のサービスを受けることができるようになり、ＳＳＯの機能を実現することができる。
【００６３】
なお、（２３）においてＳＳＯアプリケーション２がクライアント５からログイン情報を受け取ったとき、このログイン情報を（２４）でＳＳＯサーバ１に転送するか否かはＳＳＯアプリケーション２が制御可能である。例えばＳＳＯアプリケーション２が個別の認証機構を有しており、ＳＳＯアプリケーション２のローカルユーザとしてクライアントの認証を行う場合には、クライアントの認証を自装置において行えばよく、ＳＳＯサーバ１にログイン情報を転送する必要はない。また、ＳＳＯアプリケーションにおいて、クライアントはローカルユーザとしてログインしており、かつそのＳＳＯアプリケーションがローカルユーザを優先する方針であれば、ＳＳＯサーバからログイン状態情報変更の通知を受け取ったとしても、クライアントのログイン状態を更新する必要はない。既存のＳＳＯアプリケーションでは、このように従来から用いているアカウント及び認証機構をそのまま維持している場合が多く、このようなＳＳＯアプリケーションについてもＳＳＯシステムに容易に加えることが可能である。またこのような機構によって、ＳＳＯアプリケーションがログイン状態を任意に制御できるようにしている。
【００６４】
また、ＳＳＯサーバ１が（２５）において認証を行った結果、認証が不成功に終わった場合には、その旨をＳＳＯアプリケーション２に送り、さらにＳＳＯアプリケーション２がクライアント５に対してログインが成功しなかった旨を伝えればよい。
【００６５】
図７は、クライアントからＳＳＯアプリケーションへログアウト要求を行ったときの動作の一例を示すシーケンス図である。ここではクライアント５がログイン中にＳＳＯアプリケーション２に対してログアウトの要求を行うものとする。この例においても、これまでにクライアント５はＳＳＯアプリケーション２，３に対してアクセスを行っているものとする。
【００６６】
クライアント５は、ここではＳＳＯアプリケーション２に対して（３１）においてログアウトを要求する。ＳＳＯアプリケーション２は、クライアント５からログアウトの要求を受け取ると、（３２）においてクライアント５のクライアント識別情報（ｃｉｄ）とともにログアウトの要求をＳＳＯサーバ１へ送る。
【００６７】
ＳＳＯサーバ１では、ＳＳＯアプリケーション２からクライアント識別情報（ｃｉｄ）及びログアウトの要求を受け取ると、（３３）において、ＳＳＯアプリケーション２におけるクライアント識別情報（ｃｉｄ）をもとにＳＳＯサーバ１におけるクライアント識別情報（ｓｉｄ）を特定し、ログイン状態情報データベース１３に格納されているクライアント５のログイン状態情報を更新する。例えば“ゲスト”の状態に戻せばよい。
【００６８】
さらに、ＳＳＯサーバ１におけるクライアント識別情報（ｓｉｄ）をもとにＳＳＯアクセス情報データベース１２を検索し、それまでクライアント５がアクセスしたＳＳＯアプリケーションを特定する。
【００６９】
そして（３４）において、（３３）で特定した各ＳＳＯアプリケーションに対して、ログアウトをそれぞれのＳＳＯアプリケーションにおけるクライアント識別情報（ｃｉｄ）とともに送る。ログアウトは、例えば“ゲスト”のログイン状態情報（ｓｔａｔｕｓ）を送信してもよい。クライアント５がＳＳＯアプリケーション２，３にアクセスしていた場合、図中（３４）として示すＳＳＯアプリケーション２へのログアウトの送信とともに、ＳＳＯアプリケーション３に対してもログアウトが送信される。これを（３４’）として示している。
【００７０】
このように、ログアウトが行われてログイン状態が更新される場合も、ログイン時と同様、ＳＳＯアクセス情報データベース１２に蓄積されている、クライアントがそれまでにアクセスしたすべてのＳＳＯアプリケーションに対してログアウトが送信される。これによって即時性を保証するとともに、クライアントがアクセスしたＳＳＯアプリケーションのみにしかログアウトを送信しないことによって、ネットワーク４などに対する負荷を最小限にとどめることができる。さらに、ログアウトについてもＳＳＯサーバ１からＳＳＯアプリケーションに通知されるため、ＳＳＯアプリケーションから定期的に、あるいはクライアントからのアクセス時毎にＳＳＯサーバ１へ尋ねる必要もなく、この点でも即時性及び負荷の軽減に寄与することができる。
【００７１】
ＳＳＯサーバ１からログアウトを受け取ったＳＳＯアプリケーション２では、（３５）において、クライアント５のログイン状態情報をログアウトの状態（例えば“ゲスト”）に更新する。そしてＳＳＯアプリケーション２は、ログアウト後のページを（３６）においてクライアント５に送る。以後、クライアント５はログインしていない“ゲスト”として扱われる。
【００７２】
また、ＳＳＯアプリケーション３においても、ＳＳＯサーバ１からクライアント５のログアウトを受け取る。そしてＳＳＯアプリケーション３のログイン状態情報データベースについても更新される。これによって、クライアント５がＳＳＯアプリケーション２に対してログアウトを行うだけで、ＳＳＯアプリケーション３についてもログアウトを行ったのと同等のサービスを受けることができるようになり、ＳＳＯの機能を実現することができる。
【００７３】
なお、（３１）においてＳＳＯアプリケーション２がクライアント５からログアウトの要求を受け取ったとき、クライアント５がローカルユーザとしてログインしている場合にはＳＳＯアプリケーション２においてログアウトの処理を行い、ＳＳＯサーバ１へのログアウトの要求の転送を行わないように制御すればよい。また、通知を受けるＳＳＯアプリケーションにおいて、クライアントはローカルユーザとしてログインしており、かつそのＳＳＯアプリケーションがローカルユーザを優先する方針であれば、ＳＳＯサーバからログイン状態情報変更の通知を受け取ったとしても、クライアントのログイン状態をログアウト状態へ更新する必要はない。
【００７４】
上述の動作の説明では、ＳＳＯアプリケーション２，３及びＳＳＯサーバ１においてクライアントに対して割り当てたクライアント識別情報（ｃｉｄ，ｓｉｄ）に対する有効期限については説明していないが、例えばログインしたら永続的にそのログインの状態を続けるのであれば、有効期限を設定しなければよい。あるいは、無期限の設定を行えばよい。
【００７５】
もちろん有効期限を設定することもでき、その場合には、例えばそれぞれのＳＳＯアプリケーション及びＳＳＯサーバにおいて期限管理を行えばよい。あるいは、ＳＳＯアプリケーション及びＳＳＯサーバがクライアントに対して発行した情報（例えばクッキー）に有効期限を設定しておき、クライアントからのアクセスを有効期限内に制限することもできる。有効期限としては、例えば時間を設定したり、例えばセッションの終了までなどといった特定の事象の発生までの期限を設定することもできる。
【００７６】
このような有効期限は、ユーザの利用を制限するほか、クライアント識別情報（ｃｉｄ，ｓｉｄ）の漏洩による不正アクセスの防止にも利用することができる。例えばＳＳＯサーバにおけるクライアント識別情報（ｓｉｄ）に有効期限を設けず、ＳＳＯアプリケーションにおけるクライアント識別情報（ｃｉｄ）に有効期限を設けておく。そして、ＳＳＯアプリケーションにおけるクライアント識別情報（ｃｉｄ）の有効期限切れの後にクライアントからＳＳＯアプリケーションにアクセスされ、ＳＳＯサーバに問い合わせが行われた際に、ＳＳＯサーバにおけるクライアント識別情報（ｓｉｄ）を更新する。これによって、ＳＳＯサーバにおけるログイン状態は保ったまま、クライアント識別情報（ｓｉｄ）を変更してゆくことができる。従ってクライアント識別情報（ｓｉｄ）が漏洩しても永続的に利用できないため、不正アクセスを低減することができる。
【００７７】
【発明の効果】
以上の説明から明らかなように、本発明によれば、ＳＳＯを実現するとともにログイン状態の変更にも対応し、またそのログイン状態をサービス側で自由に制御することができ、さらに特別なポータルサイトを必要としないネットワークシステムを提供することができる。また、クライアントがアクセスしたサービスに関する情報をアクセス管理サーバに保持しておき、ログイン状態の変更時にはクライアントがアクセスしたことのあるサービスに対してログイン状態の変更を通知するようにしたので、ログイン状態の変更が即時に行われるとともに、ネットワークに対する負荷を軽減し、パフォーマンスへの影響を最小限に抑えることができるという効果がある。
【図面の簡単な説明】
【図１】本発明の実施の一形態を示すシステム構成図である。
【図２】ＳＳＯサーバが保持する情報の一例の説明図である。
【図３】ＳＳＯアプリケーションが保持するログイン状態情報の一例の説明図である。
【図４】クライアントからＳＳＯアプリケーションへの初回のアクセス時の動作の一例を示すシーケンス図である。
【図５】クライアントから別のＳＳＯアプリケーションへアクセスした時の動作の一例を示すシーケンス図である。
【図６】クライアントからＳＳＯアプリケーションへログイン要求を行ったときの動作の一例を示すシーケンス図である。
【図７】クライアントからＳＳＯアプリケーションへログアウト要求を行ったときの動作の一例を示すシーケンス図である。
【符号の説明】
１…ＳＳＯサーバ、２，３…ＳＳＯアプリケーション、４…ネットワーク、５〜７…クライアント、１１…通信制御部、１２…ＳＳＯアクセス情報データベース、１３…ログイン状態情報データベース、１４…ユーザ認証情報データベース、２１…通信制御部、２２…処理部、２３…ログイン状態情報データベース。
Claims (14)
- クライアントに対して提供されるサービスへの前記クライアントのアクセスを管理するアクセス管理サーバにおいて、クライアントがアクセスしたサービスに関するアクセス情報を保持するアクセス情報保持手段と、前記クライアントが新たなサービスにアクセスするたびに前記クライアントがアクセスしたサービスの情報を前記アクセス情報として前記アクセス情報保持手段に保持させ前記クライアントのログイン状態の変更時には前記アクセス情報に従って前記クライアントがアクセスしたサービスに対してログイン状態の変更を通知する通信制御手段を有することを特徴とするアクセス管理サーバ。
- 前記クライアントのログイン状態に関するログイン状態情報を保持するログイン状態情報保持手段を有し、前記通信制御手段は、既にアクセス済のクライアントが他のサービスに新たにアクセスしたときには、前記ログイン状態情報に従って前記他のサービスに対してログイン状態を通知し、ログイン状態の変更時には前記ログイン状態情報の更新も行うことを特徴とする請求項１に記載のアクセス管理サーバ。
- 前記通信制御手段は、前記ログイン状態の変更としてサービスに対するログイン要求を受け付け、あるサービスに対するログインの許可を他のアクセス済のサービスに対して通知することを特徴とする請求項１または請求項２に記載のアクセス管理サーバ。
- クライアントの認証情報を保持する認証情報保持手段を有しており、前記通信制御手段は、前記サービスに対するログイン要求を受け付けた際に前記認証情報保持手段に保持されている認証情報を用いてクライアントの認証を行うことを特徴とする請求項３に記載のアクセス管理サーバ。
- 前記通信制御手段は、前記ログイン状態の変更としてサービスに対するログアウト要求を受け付け、あるサービスに対するログアウトを他のアクセス済のサービスに対して通知することを特徴とする請求項１または請求項２に記載のアクセス管理サーバ。
- 前記通信制御手段は、前記クライアント毎にアクセスの有効期限を定めることを特徴とする請求項１ないし請求項５のいずれか１項に記載のアクセス管理サーバ。
- ネットワークを通じて行われるクライアントからの要求に応じてサービスを提供するネットワーク装置において、要求されたサービスを提供する処理手段と、前記クライアントのログイン状態に関するログイン状態情報を保持するログイン状態情報保持手段と、クライアントからのアクセスを受け付けて必要に応じて前記処理手段にサービスを行わせる通信制御手段を有し、前記通信制御手段は、クライアントからのアクセスを受けた際に、前記ログイン状態情報保持手段が保持する前記ログイン状態情報を調べ、新たなクライアントからのアクセスである場合、あるいは、ログイン状態の変更を要求するアクセスの場合にはアクセス管理サーバに通知し、前記アクセス管理サーバからの通知に応じて前記ログイン状態情報保持手段への前記ログイン状態情報の登録又は前記ログイン状態情報の更新を行うことを特徴とするネットワーク装置。
- 前記通信制御手段は、ログイン状態の変更を要求したクライアントがサービスに対するローカルユーザである場合には、前記アクセス管理サーバへの問い合わせを行わずにログイン状態の変更を行うことを特徴とする請求項７に記載のネットワーク装置。
- 前記通信制御手段は、前記クライアント毎にアクセスの有効期限を定めることを特徴とする請求項７または請求項８に記載のネットワーク装置。
- ネットワークを通じて行われるクライアントからの要求に応じてサービスを提供するネットワーク装置と、ネットワークを通じて前記クライアントのアクセスを管理するアクセス管理サーバを含み、前記ネットワーク装置は、クライアントから新たなアクセスを受けた際に前記アクセス管理サーバに通知し、前記アクセス管理サーバは、前記ネットワーク装置からの新たなアクセスを受けた際の通知に従いアクセス情報を保持し、前記ネットワーク装置がクライアントからログイン状態の変更を要求された場合には前記ログイン状態の変更の要求を前記アクセス管理サーバに送り、前記アクセス管理サーバはそれまでに保持されている当該クライアントに対応するアクセス情報に従って１ないし複数のネットワーク装置に対してログイン状態の変更を通知することを特徴とするネットワークシステム。
- 前記ネットワーク装置がクライアントからログインの要求を受けたとき、前記アクセス管理サーバは前記クライアントの認証を行って当該クライアントに対応するログイン状態情報をログインの状態に変更するとともに、それまでに前記クライアントがアクセスしたネットワーク装置に対してログイン状態情報の変更を通知し、他のネットワーク装置においても前記クライアントがログイン済として扱うことを特徴とする請求項１０に記載のネットワークシステム。
- 前記ネットワーク装置がクライアントからログアウトの要求を受けたとき、前記アクセス管理サーバは当該クライアントに対応するログイン状態情報をログアウトの状態に変更するとともに、それまでに前記クライアントがアクセスしたネットワーク装置に対してログイン状態情報の変更を通知し、他のネットワーク装置においても前記クライアントがログアウトしたものとして扱うことを特徴とする請求項１０に記載のネットワークシステム。
- クライアントに対して提供されるサービスへの前記クライアントのアクセスを管理するアクセス管理方法において、前記クライアントが新たなサービスにアクセスするたびに前記クライアントがアクセスしたサービスの情報をアクセス情報として保持し、前記クライアントのログイン状態の変更時には、前記アクセス情報に従って前記クライアントがアクセスしたサービスに対してログイン状態情報の変更を通知することを特徴とするアクセス管理方法。
- さらに、前記クライアントのログイン状態に関するログイン状態情報を保持しており、既にアクセス済のクライアントが他のサービスに新たにアクセスしたときには、前記ログイン状態情報に従って前記他のサービスに対してログイン状態を通知し、ログイン状態の変更時には前記ログイン状態情報の更新も行うことを特徴とする請求項１３に記載のアクセス管理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003095179A JP4352210B2 (ja) | 2003-03-31 | 2003-03-31 | アクセス管理サーバ、ネットワーク装置、ネットワークシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003095179A JP4352210B2 (ja) | 2003-03-31 | 2003-03-31 | アクセス管理サーバ、ネットワーク装置、ネットワークシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004302869A true JP2004302869A (ja) | 2004-10-28 |
| JP4352210B2 JP4352210B2 (ja) | 2009-10-28 |
Family
ID=33407565
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003095179A Expired - Lifetime JP4352210B2 (ja) | 2003-03-31 | 2003-03-31 | アクセス管理サーバ、ネットワーク装置、ネットワークシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4352210B2 (ja) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008225943A (ja) * | 2007-03-14 | 2008-09-25 | Nomura Research Institute Ltd | セッション管理装置、プログラム、及び記憶媒体 |
| US7823187B2 (en) | 2006-06-07 | 2010-10-26 | Fujitsu Limited | Communication processing method and system relating to authentication information |
| CN102065067A (zh) * | 2009-11-11 | 2011-05-18 | 杭州华三通信技术有限公司 | 一种在门户服务器和客户端之间防重放攻击的方法及设备 |
| JP2012137968A (ja) * | 2010-12-27 | 2012-07-19 | Kyocera Document Solutions Inc | 画像形成装置 |
| JP2012137969A (ja) * | 2010-12-27 | 2012-07-19 | Kyocera Document Solutions Inc | 画像形成装置 |
| CN111800511A (zh) * | 2020-07-07 | 2020-10-20 | 上海携程商务有限公司 | 同步登录态的处理方法、系统、设备及可读存储介质 |
-
2003
- 2003-03-31 JP JP2003095179A patent/JP4352210B2/ja not_active Expired - Lifetime
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7823187B2 (en) | 2006-06-07 | 2010-10-26 | Fujitsu Limited | Communication processing method and system relating to authentication information |
| JP2008225943A (ja) * | 2007-03-14 | 2008-09-25 | Nomura Research Institute Ltd | セッション管理装置、プログラム、及び記憶媒体 |
| CN102065067A (zh) * | 2009-11-11 | 2011-05-18 | 杭州华三通信技术有限公司 | 一种在门户服务器和客户端之间防重放攻击的方法及设备 |
| CN102065067B (zh) * | 2009-11-11 | 2014-06-25 | 杭州华三通信技术有限公司 | 一种在门户服务器和客户端之间防重放攻击的方法及设备 |
| JP2012137968A (ja) * | 2010-12-27 | 2012-07-19 | Kyocera Document Solutions Inc | 画像形成装置 |
| JP2012137969A (ja) * | 2010-12-27 | 2012-07-19 | Kyocera Document Solutions Inc | 画像形成装置 |
| CN111800511A (zh) * | 2020-07-07 | 2020-10-20 | 上海携程商务有限公司 | 同步登录态的处理方法、系统、设备及可读存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4352210B2 (ja) | 2009-10-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5357246B2 (ja) | 統合認証のためのシステム、方法およびプログラム製品 | |
| JP3569122B2 (ja) | セッション管理システム、サービス提供サーバ、セッション管理サーバ、セッション管理方法及び記録媒体 | |
| TWI400922B (zh) | 在聯盟中主用者之認證 | |
| US7082532B1 (en) | Method and system for providing distributed web server authentication | |
| AU2015324004B2 (en) | Using credentials stored in different directories to access a common endpoint | |
| JP4579546B2 (ja) | 単一サインオンサービスにおけるユーザ識別子の取り扱い方法及び装置 | |
| CN102171984B (zh) | 服务提供者访问 | |
| CN111147453A (zh) | 系统登录方法以及集成登录系统 | |
| CN103404103A (zh) | 将访问控制系统与业务管理系统相结合的系统和方法 | |
| CN110730174B (zh) | 一种网络访问控制方法、装置、设备及介质 | |
| JP2009519529A (ja) | 認証方法を拡張するための方法及びシステム | |
| JP2005516533A (ja) | パブリックキー暗号法を用いたインターネット上でのシングルサインオン | |
| JPH10177552A (ja) | 認証応答方法およびその方法を用いた認証応答装置 | |
| CN102638454A (zh) | 一种面向http身份鉴别协议的插件式单点登录集成方法 | |
| JP2007310512A (ja) | 通信システム、サービス提供サーバおよびユーザ認証サーバ | |
| CN112367666B (zh) | 一种5G核心网中pNF通过NRF认证cNF的方法、装置及系统 | |
| JP2016115260A (ja) | 権限移譲システム、権限移譲システムに用いられる認可サーバー、リソースサーバー、クライアント、媒介装置、権限移譲方法およびプログラム | |
| AU2017344389B2 (en) | Portal aggregation service mapping subscriber device identifiers to portal addresses to which connection and authentication requests are redirected and facilitating mass subscriber apparatus configuration | |
| JP2000106552A (ja) | 認証方法 | |
| JP4352210B2 (ja) | アクセス管理サーバ、ネットワーク装置、ネットワークシステム | |
| US20170195426A1 (en) | Maintaining session across plural providing devices | |
| JP2005301424A (ja) | 分散認証システム、負荷分散装置及び認証サーバ、並びに負荷分散プログラム及び認証プログラム | |
| JP2001056795A (ja) | アクセス認証処理装置及びこれを備えるネットワーク及びその記憶媒体及びアクセス認証処理方法 | |
| JP2000172645A (ja) | サーバコンピュータ及びサーバコンピュータにおける認証情報管理方法 | |
| JP2005293088A (ja) | 認証システム及び認証方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060221 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090210 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090410 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090701 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090714 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4352210 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120807 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120807 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130807 Year of fee payment: 4 |
|
| S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| EXPY | Cancellation because of completion of term |