JP2010020647A - 認可サーバ装置、情報処理方法及びプログラム - Google Patents

Abstract

【課題】ユーザの負荷を軽減させると共に、導入負荷の低い統合認証基盤を提供することを目的とする。
【解決手段】ネットワークログオンによりシステムにシングルサインオンしたクライアント装置で動作するアプリケーション、又はシステムに含まれるサーバ装置で動作するＷｅｂアプリケーションからのユーザの権限に係る権限情報の問い合わせを受け付け、権限情報をアプリケーションに提供するＷｅｂサービス手段を有し、Ｗｅｂサービス手段は、問い合わせに含まれるユーザを識別するユーザ識別情報を取得し、ユーザ識別情報に基づいて、記憶装置に記憶されている、ユーザを識別するユーザ識別情報とユーザの権限情報とが関連付けられた権限データを検索し、対応する権限情報を取得し、権限情報を要求元のアプリケーションに提供することによって課題を解決する。
【選択図】図１

Description

本発明は、認可サーバ装置、情報処理方法及びプログラムに関する。

従来、多くの企業では複数のシステムを組み合わせて利用している。これらの企業の社員（ユーザ）は、それぞれのシステムに対してＩＤ及びパスワードを入力し、ログインの手続（ログイン手続）を経た上でそれぞれのシステムを使用している。つまり、各システムは、入力されたＩＤ及びパスワードと、設定されている認証に用いられる認証データと、を比較して、ユーザの認証を行っている。

企業において、より多くのシステムが導入されるようになった昨今では、各システムへログインする手続が増え、ユーザの手間が増加している。また、ＩＤ及びパスワードの数が増えてくると、ＩＤ及びパスワードの管理もユーザにとっては大きな手間となっている。

また、これら企業内のシステムでは、各システムに対するユーザの権限を管理する認可機能も必要である。これら、認証機能と、認可機能と、を統合して管理する仕組みは、統合認証基盤と呼ばれている。
統合認証基盤に関する技術として、リバースプロキシ型の仕組みと、エージェント型の仕組みと、がある。

リバースプロキシ型の仕組みは、クライアント装置にインストールされたブラウザ等を介してリバースプロキシ（リバースプロキシ装置）にアクセスしてきたユーザに対して、リバースプロキシが、前記ユーザがアクセス権限のあるサーバ装置（Ｗｅｂアプリケーション）にのみ、通信を許可する仕組みである。
一方、エージェント型の仕組みは、クライアント装置やサーバ装置にインストールされているエージェント（Ａｇｅｎｔ）と、各アプリケーション（例えばクライアント・サーバアプリケーション（ＣＳＳアプリケーション）やＷｅｂアプリケーション）と、が通信を行い、エージェントが、認可サーバに対して権限の問い合わせを行う仕組みである。エージェント型の統合認証基盤に関する技術としては、特許文献１がある。

特開２００２−１０８８２０号公報

上述したリバースプロキシ型の仕組みは、Ｗｅｂアプリケーション用の仕組みであるため、クライアントサーバシステムでは利用することができない問題があった。また、リバースプロキシ型の仕組みは、アクセスの認証の機能のみを提供する仕組みであり、認可の機能を提供するには別の仕組みを必要とする問題があった。
また、上述したエージェント型の仕組みは、アクセスの認証の機能及び認可の機能を提供する仕組みではあるが、クライアント装置及びサーバ装置共に、エージェントのインストールが必要となり、特にクライアント装置へのエージェントの配布の問題、アプリケーションのエージェントに対する組み込み対応の問題など、導入負荷が高い問題があった。

本発明はこのような問題点に鑑みなされたもので、ユーザの負荷を軽減させると共に、導入負荷の低い統合認証基盤を提供することを目的とする。

そこで、本発明は、ネットワークログオンによりシステムにシングルサインオンしたクライアント装置で動作するアプリケーション、又は前記システムに含まれるサーバ装置で動作するＷｅｂアプリケーションからのユーザの権限に係る権限情報の問い合わせを受け付け、前記権限情報を前記アプリケーションに提供するＷｅｂサービス手段を有し、前記Ｗｅｂサービス手段は、前記問い合わせに含まれる前記ユーザを識別するユーザ識別情報を取得し、前記ユーザ識別情報に基づいて、記憶装置に記憶されている、ユーザを識別するユーザ識別情報と前記ユーザの権限情報とが関連付けられた権限データを検索し、対応する権限情報を取得し、前記権限情報を要求元のアプリケーションに提供することを特徴とする。

本発明によれば、ネットワークログオンによりシステムにシングルサインオンしたクライアント装置で動作するアプリケーション、又は前記システムに含まれるサーバ装置で動作するＷｅｂアプリケーションからのユーザの権限に係る権限情報の問い合わせを受け付け、前記権限情報を前記アプリケーションに提供するＷｅｂサービス手段を有し、前記Ｗｅｂサービス手段は、前記問い合わせに含まれる前記ユーザを識別するユーザ識別情報を取得し、前記ユーザ識別情報に基づいて、記憶装置に記憶されている、ユーザを識別するユーザ識別情報と前記ユーザの権限情報とが関連付けられた権限データを検索し、対応する権限情報を取得し、前記権限情報を要求元のアプリケーションに提供することにより、例えばクライアント装置にエージェント等をインストールする必要なく、また、認証をネットワークドメインサーバ装置等によるシングルサインオンに委ねているので、ユーザの負荷を軽減させると共に、導入負荷の低い統合認証基盤を提供することができる。
なお、特許請求の範囲に記載のユーザの権限に係る権限情報とは、例えば、後述する図８等に示されるユーザの権限等に対応する。また、特許請求の範囲に記載のアクセス権に係るアクセス権限情報とは、例えば、後述する図７等に示されるアクセス権等に対応する。

また、本発明は、情報処理装置及びプログラムとしてもよい。

本発明によれば、ユーザの負荷を軽減させると共に、導入負荷の低い統合認証基盤を提供することができる。

以下、本発明の実施形態について図面に基づいて説明する。

図１は、統合認証基盤システムのシステム構成の一例を示す図（その１）である。図１に示されるように、本実施形態に係る統合認証基盤システムは、少なくとも１台以上のクライアント装置１と、ネットワークドメインサーバ装置２と、認可サーバ装置３と、Ｗｅｂサーバ装置４と、がネットワーク５を介して接続されている。
後述するように、本実施形態に係る統合認証基盤システムでは、まず、クライアント装置１は、ネットワークドメインサーバ装置２にユーザを識別するための情報（例えばユーザＩＤとパスワードとの組み合わせ）を送信する。ネットワークドメインサーバ装置２は、クライアント装置１より送信されたユーザを識別するための情報と、認証情報（例えば有効なユーザＩＤとパスワードとの組み合わせ群）と、に基づいて、認証を行う。認証に成功すると、ネットワークドメインサーバ装置２は、クライアント装置１（又はクライアント装置１のユーザ）に対して、例えばネットワークドメインサーバ装置２、認可サーバ装置３、Ｗｅｂサーバ装置４等が存在するネットワークドメインに対する参加を許可する。

次に、例えばクライアント装置１にインストールされているＣＳＳ（クライアントサーバシステム）アプリケーション等は、ユーザによる利用開始の操作等に応じて、ユーザの権限の問い合わせ（問い合わせ要求）のＸＭＬメッセージをＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）を介して認可サーバ装置３に送信する。
なお、このＸＭＬメッセージには、ＣＳＳアプリケーションによって、ＣＳＳアプリケーションを識別するアプリケーションＩＤが入力されている。また、このＸＭＬメッセージのメッセージヘッダーには、ネットワークドメインに参加しているＯＳの機能によってユーザを識別するユーザＩＤが入力されている。

前記ＸＭＬメッセージを受け取った認可サーバ装置３は、前記ユーザＩＤを含むユーザに関する情報であるユーザ情報（本実施形態の例ではユーザが所属するグループのグループＩＤ）の取得要求をネットワークドメインサーバ装置２に対して送信する。そして、認可サーバ装置３は、前記ユーザＩＤで識別されるユーザのユーザ情報をネットワークドメインサーバ装置２より受信する。

認可サーバ装置３は、ネットワークドメインサーバ装置２より取得したユーザ情報に基づいて、クライアント装置１のユーザが、自装置（つまり認可サーバ装置３）にアクセス可能か否かを判断する。認可サーバ装置３は、クライアント装置１のユーザが、自装置にアクセス可能であると判断した場合、ＸＭＬメッセージに含まれていたユーザＩＤ及びアプリケーションＩＤに基づいて、認可テーブル等より対応するユーザの権限を検索する。そして、認可サーバ装置３は、検索した結果、取得した権限をＸＭＬメッセージに含め、ＳＯＡＰを介して要求元のＣＳＳアプリケーションに送信する。ＣＳＳアプリケーションは、受信した権限を例えば画面等に含めて表示する。

このように本実施形態の統合認証基盤システムでは、認証行為をネットワークドメインサーバ装置２に委ね、Ｗｅｂサービス等を通じてユーザの権限（認可情報）を例えばクライアント装置とサーバ装置との間でやり取りを行うことにより、ユーザの負荷を軽減させると共に、導入負荷の低い統合認証基盤を提供することができる。

図２は、クライアント装置１のハードウェア構成の一例を示す図である。図２に示されるようにクライアント装置１は、ハードウェア構成として、ＣＰＵ１１を含む。ＣＰＵ１１が、記憶装置１３に記憶されている、プログラムに基づき処理を行うことによって、後述する機能、又はシーケンスに係る処理を実現する。
ＣＰＵ１１には、バス１０を介して、入力装置１２、記憶装置１３及び表示装置１４が接続されている。記憶装置１３は、例えば、ＲＯＭ、ＲＡＭ、ハードディスク装置等からなり、上述した各プログラム以外に、プログラムに基づく処理で用いられるデータを記憶する。表示装置１４は、情報を表示する例えばディスプレイ等である。入力装置１２は、情報を入力する例えば操作キー等である。
なお、クライアント装置１には、ＣＳＳアプリケーションやＷｅｂブラウザ等がインストールされているものとする。

図３は、ネットワークドメインサーバ装置２のハードウェア構成の一例を示す図である。図３に示されるようにネットワークドメインサーバ装置２は、ハードウェア構成として、ＣＰＵ２１を含む。ＣＰＵ２１が、記憶装置２２に記憶されている、プログラムに基づき処理を行うことによって、後述する機能、又はシーケンスに係る処理を実現する。
ＣＰＵ２１には、バス２３を介して、記憶装置２２が接続されている。記憶装置２２は、例えば、ＲＯＭ、ＲＡＭ、ハードディスク装置等からなら、上述した各プログラム以外に、プログラムに基づく処理で用いられるデータを記憶する。
なお、ネットワークドメインサーバ装置２は、上述したクライアント装置１の様に、入力装置及び表示装置をハードウェア構成として含んでいてもよい。

また、認可サーバ装置３及びＷｅｂサーバ装置４のハードウェア構成は、図３のネットワークドメインサーバ装置２のハードウェア構成と同様である。
認可サーバ装置３のＣＰＵが記憶装置に記憶されているプログラムに基づき処理を行うことによって、後述する機能、又はシーケンスに係る処理を実現する。また、Ｗｅｂサーバ装置４のＣＰＵが記憶装置に記憶されているプログラムに基づき処理を行うことによって、後述する機能、又はシーケンスに係る処理を実現する。

図４は、ネットワークドメインサーバ装置２の機能構成の一例を示す図である。図４に示されるように、ネットワークドメインサーバ装置２は、機能構成として、認証部３１と、ユーザ情報提供部３２と、を含む。
認証部３１は、クライアント装置１より送信されてきたユーザを識別するための情報と、認証情報と、に基づいて、認証を行う。認証部３１は、認証に成功すると、クライアント装置１（又はクライアント装置１のユーザ）に対して、例えばネットワークドメインサーバ装置２、認可サーバ装置３、Ｗｅｂサーバ装置４等が存在するネットワークドメインに対する参加を許可する。

ユーザ情報提供部３２は、認可サーバ装置３又はＷｅｂサーバ装置４（又はＷｅｂサーバ装置４にインストールされているＷｅｂアプリケーション）等から送信されてきたユーザ情報の取得要求に含まれるユーザＩＤに基づいて、ユーザＩＤに対応するユーザ情報を要求元の認可サーバ装置３又はＷｅｂサーバ装置４に提供（送信）する。
なお、本実施形態の例では、ユーザ情報として、ユーザが所属するグループ情報を例に説明を行う。

図５は、ネットワークドメインサーバ装置２の記憶装置２２に記憶されているユーザ情報に係るテーブルの一例を示す図である。図５に示されるように、ユーザ情報テーブル３３は、ユーザＩＤと、グループＩＤと、を項目に含む。ユーザ情報テーブル３３は、例えば、ユーザ情報提供部３２等が管理している。
ユーザ情報提供部３２は、例えば認可サーバ装置３よりユーザＩＤ「００３」を含むユーザ情報の取得要求を受け取ると、前記取得要求に含まれるユーザＩＤ「００３」を検索キーに、図５に示されるユーザ情報テーブルを検索し、対応するグループＩＤ「Ｂ」をユーザ情報として（又はユーザＩＤと、グループＩＤ「Ｂ」と、をユーザ情報として）要求元の認可サーバ装置３に送信する。

図６は、認可サーバ装置３の機能構成の一例を示す図（その１）である。図６に示されるように、認可サーバ装置３は、機能構成として、Ｗｅｂサービス部４１と、管理部４２と、を含む。
Ｗｅｂサービス部４１は、Ｗｅｂサービスとして機能を提供する部である。Ｗｅｂサービス部４１は、クライアント装置１のＣＳＳアプリケーションやＷｅｂサーバ装置４のＷｅｂアプリケーションより、ＳＯＡＰを介したＸＭＬメッセージを受け取る。

Ｗｅｂサービス部４１は、受け取ったＸＭＬメッセージに含まれるユーザＩＤ及びＣＳＳアプリケーション又はＷｅｂアプリケーションを識別するアプリケーションＩＤを取得する。そして、Ｗｅｂサービス部４１は、取得したユーザＩＤを管理部４２に渡す。
管理部４２は、Ｗｅｂサービス部４１より受け取ったユーザＩＤを含む、ユーザ情報の取得要求をネットワークドメインサーバ装置２に送信し、前記取得要求に対応するユーザ情報（本実施形態の例ではグループＩＤ）を取得する。

管理部４２は、取得したグループＩＤに基づいて、グループＩＤ毎に自装置にアクセス可能か否かが設定されている図７に示されるようなアクセス可否設定テーブル４３を検索し、対応する情報（つまりアクセス可能か否かの情報）を取得し、前記グループＩＤに属するユーザが自装置にアクセス可能か否かを判断し、判断結果をＷｅｂサービス部４１に返す。
ここで、図７は、アクセス可否設定テーブル４３の一例を示す図である。図７に示されるアクセス可否設定テーブル４３は、例えば認可サーバ装置３の記憶装置等に記憶されている。

Ｗｅｂサービス部４１は、管理部４２より、ユーザが自装置にアクセス可能であるとの判断結果を受け取ると、ＸＭＬメッセージに含まれていたユーザＩＤ及びアプリケーションＩＤに基づいて、ユーザＩＤ及びアプリケーションＩＤ毎にユーザの権限が設定されている図８に示されるような認可テーブル４４を検索し、対応するユーザの権限を取得する。
そして、認可サーバ装置３は、取得した権限をＸＭＬメッセージに含め、ＳＯＡＰを介して要求元のＣＳＳアプリケーション又はＷｅｂアプリケーションに送信する。
ここで、図８は、認可テーブル４４の一例を示す図である。図８に示される認可テーブル４４は、例えば認可サーバ装置３の記憶装置等に記憶されている。

図９は、ネットワークログオンに係るシーケンスの一例を示す図である。
シーケンスＳＱ１において、クライアント装置１は、ネットワークドメインサーバ装置２にユーザを識別するための情報（例えばユーザＩＤとパスワードとの組み合わせ）を送信する。ネットワークドメインサーバ装置２は、クライアント装置１より送信されたユーザを識別するための情報と、認証情報（例えば有効なユーザＩＤとパスワードとの組み合わせ群）と、に基づいて、認証を行う。認証に成功すると、ネットワークドメインサーバ装置２は、クライアント装置１（又はクライアント装置１のユーザ）に対して、例えばネットワークドメインサーバ装置２、認可サーバ装置３、Ｗｅｂサーバ装置４等が存在するネットワークドメインに対する参加を許可する。

図１０は、クライアント装置１のＣＳＳアプリケーションにより権限問い合わせに係るシーケンスの一例を示す図である。
シーケンスＳＱ１０において、ＣＳＳアプリケーションは、ユーザによる利用開始の操作等に応じて、ユーザの権限の問い合わせ（問い合わせ要求）のＸＭＬメッセージを、ＳＯＡＰを介して認可サーバ装置３に送信する。上述したように、このＸＭＬメッセージには、ＣＳＳアプリケーションによって、ＣＳＳアプリケーションを識別するアプリケーションＩＤが入力されている。また、このＸＭＬメッセージのメッセージヘッダーには、ネットワークドメインに参加しているＯＳの機能によってユーザを識別するユーザＩＤが入力されている。

シーケンスＳＱ１１において、認可サーバ装置３は、受け取ったＸＭＬメッセージに含まれるユーザＩＤを含む、ユーザ情報の取得要求をネットワークドメインサーバ装置２に送信する。ネットワークドメインサーバ装置２は、ユーザ情報の取得要求に含まれるユーザＩＤに基づいて、図５に示されるユーザ情報テーブルを検索し、対応するグループＩＤを取得する。そして、シーケンスＳＱ１２において、ネットワークドメインサーバ装置２は、取得したグループＩＤをユーザ情報として要求元の認可サーバ装置３に送信する。認可サーバ装置３は、ネットワークドメインサーバ装置２が送信したグループＩＤを受信する。

シーケンスＳＱ１３において、認可サーバ装置３は、受信したグループＩＤに基づいて、図７に示されるようなアクセス可否設定テーブル４３を検索し、対応する情報（つまりアクセス可能か否かの情報）を取得し、前記グループＩＤに属するユーザが自装置にアクセス可能か否かを判断する。
ユーザが自装置にアクセス可能であると判断した場合、シーケンスＳＱ１４において、認可サーバ装置３は、ＸＭＬメッセージに含まれていたユーザＩＤ及びアプリケーションＩＤに基づいて、図８に示されるような認可テーブル４４を検索し、対応するユーザの権限を取得する。

シーケンスＳＱ１５において、認可サーバ装置３は、取得した権限をＸＭＬメッセージに含め、ＳＯＡＰを介して要求元のＣＳＳアプリケーションに送信する。ＣＳＳアプリケーションは、認可サーバ装置３より権限を受信する。
シーケンスＳＱ１６において、ＣＳＳアプリケーションは、受信したユーザの権限を例えばアプリケーションに係る画面上等に表示する。

図１１は、Ｗｅｂサーバ装置４のＷｅｂアプリケーションによる権限問い合わせに係るシーケンスの一例を示す図である。
シーケンスＳＱ２０において、クライアント装置１のＷｅｂブラウザは、ユーザによる利用開始の操作等に応じて、Ｗｅｂアプリケーションの利用要求をＷｅｂサーバ装置４のＷｅｂアプリケーションに送信する。なお、この利用要求には、ネットワークドメインに参加しているＯＳの機能によってユーザを識別するユーザＩＤが入力されている。

シーケンスＳＱ２１において、Ｗｅｂサーバ装置４は、受け取った利用要求に含まれるユーザＩＤと、Ｗｅｂアプリケーションを識別するアプリケーションＩＤと、を含むユーザの権限の問い合わせ（問い合わせ要求）のＸＭＬメッセージを、ＳＯＡＰを介して認可サーバ装置３に送信する。

シーケンスＳＱ２２において、認可サーバ装置３は、受け取ったＸＭＬメッセージに含まれるユーザＩＤを含む、ユーザ情報の取得要求をネットワークドメインサーバ装置２に送信する。ネットワークドメインサーバ装置２は、ユーザ情報の取得要求に含まれるユーザＩＤに基づいて、図５に示されるユーザ情報テーブルを検索し、対応するグループＩＤを取得する。そして、シーケンスＳＱ２３において、ネットワークドメインサーバ装置２は、取得したグループＩＤをユーザ情報として要求元の認可サーバ装置３に送信する。認可サーバ装置３は、ネットワークドメインサーバ装置２が送信したグループＩＤを受信する。

シーケンスＳＱ２４において、認可サーバ装置３は、受信したグループＩＤに基づいて、図７に示されるようなアクセス可否設定テーブル４３を検索し、対応する情報（つまりアクセス可能か否かの情報）を取得し、前記グループＩＤに属するユーザが自装置にアクセス可能か否かを判断する。
ユーザが自装置にアクセス可能であると判断した場合、シーケンスＳＱ２５において、認可サーバ装置３は、ＸＭＬメッセージに含まれていたユーザＩＤ及びアプリケーションＩＤに基づいて、図８に示されるような認可テーブル４４を検索し、対応するユーザの権限を取得する。

シーケンスＳＱ２６において、認可サーバ装置３は、取得した権限をＸＭＬメッセージに含め、ＳＯＡＰを介して要求元のＷｅｂアプリケーションに送信する。Ｗｅｂアプリケーションは、認可サーバ装置３より権限を受信する。
シーケンスＳＱ２７において、Ｗｅｂサーバ装置４のＷｅｂアプリケーションは、受信した権限に応じて、Ｗｅｂアプリケーションの利用を許可するか否かを判断し、この判断結果（利用可能か否かの利用可否）をクライアント装置１のＷｅｂブラウザに送信する。

以上、上述したように本実施形態によれば、ＣＳＳアプリケーションでもＷｅｂアプリケーションでも利用可能な統合認証基盤を実現することができる。また、本実施形態によれば、Ｗｅｂサービスの仕組みを使っているため、クライアント装置やサーバ装置に余計なアプリケーションをインストールする必要がない。また、Ｗｉｎｄｏｗｓ（登録商標）やＬｉｎｕｘ（登録商標）など、様々な環境、様々な言語へ容易に導入することができる。
つまり、本実施形態によれば、ユーザの負荷を軽減させると共に、導入負荷の低い統合認証基盤を提供することができる。

＜実施形態２＞
実施形態１では、図１に示したように認可サーバ装置３はシステム内に１台だけの例で説明を行った。しかしながら、図１２に示されるように、認可サーバ装置３をシステム内に複数設けてもよい。図１２は、統合認証基盤システムのシステム構成の一例を示す図（その２）である。なお、本実施形態では、上述した実施形態と異なる点について主に説明を行う。
図１２に示されるように、システム内に複数の認可サーバ装置３を設けることによって、ある一台の認可サーバ装置３が障害等で動作できなくなっても、ユーザは他の認可サーバ装置３で認可を行うことができる。よって、本実施形態によれば、システムの可用性が向上する。

＜実施形態３＞
図１３は、認可サーバ装置３の機能構成の一例を示す図（その２）である。図１３に示されるように、認可サーバ装置３は、機能構成として、Ｗｅｂサービス部４１と、管理部４２と、権限棚卸部４５と、ロック部４６と、を含む。なお、本実施形態では、上述した実施形態と異なる点について主に説明を行う。
権限棚卸部４５は、ユーザＩＤに関連付けてユーザの部室、役職情報を管理し、例えば、予め定められた時間間隔ごとに、初回登録時又は更新登録時の部室、役職情報から変更されているか否か確認する。権限棚卸部４５は、ユーザの部室又は役職情報が、初回登録時又は更新登録時の部室、役職情報から変更されていた場合、認可テーブル４４の対応する権限も変更する必要があるか否か、例えば管理者等にメール等で問い合わせを行う。また、権限棚卸部４５は、ユーザの部室又は役職情報が、初回登録時又は更新登録時の部室、役職情報から変更されていた場合、変更された部室又は役職情報及び予め設定されている権限の変更に係る設定情報等に基づき、前記ユーザの権限を変更するようにしてもよい。
また、権限棚卸部４５は、Ｗｅｂサービス部４１等を介して権限の問い合わせを管理し、予め定められた期間、ユーザからの権限の問い合わせがない場合、認可テーブル４４の前記ユーザに関する権限をこのまま維持するか否か、例えば管理者等にメール等で通知する。また、権限棚卸部４５は、Ｗｅｂサービス部４１等を介して権限の問い合わせを管理し、予め定められた期間、ユーザからの権限の問い合わせがない場合、予め設定されている権限の削除又は縮小に係る設定情報等に基づき、前記ユーザの権限を削除又は縮小するようにしてもよい。
つまり、権限棚卸部４５の機能により、部室、役職の変更や、長時間利用していないユーザの棚卸が容易に可能となる。

ロック部４６は、管理者権限を有するユーザからの要求等に基づいて、管理者権限以外の権限を有するユーザの権限を「＊＊ＬＯＣＫＥＤ＊＊」等の特殊な権限とすると共に、管理者権限を有するユーザからの要求等に基づいて、管理者権限以外の権限を有するユーザの権限を元の権限に戻す。
つまり、ロック部４６の機能により、メンテナンス時等にアプリケーションを停止させることなく、管理者権限以外の権限を有するユーザの利用権限を一時的に剥奪すると共に、メンテナンス等が終了した場合は、元の権限に戻すことによって、容易に前記ユーザの利用権限を復権させることができる。

以上、上述した各実施形態によれば、ユーザの負荷を軽減させると共に、導入負荷の低い統合認証基盤を提供することができる。

以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
例えば、上述した実施形態では、ＣＳＳアプリケーションを例に説明を行ったが、上述した各実施形態は、ＣＳＳアプリケーションに限定されるものではなく、権限に応じて処理が変わるようなアプリケーションであればどのようなアプリケーションであってもよい。

統合認証基盤システムのシステム構成の一例を示す図（その１）である。 クライアント装置１のハードウェア構成の一例を示す図である。 ネットワークドメインサーバ装置２のハードウェア構成の一例を示す図である。 ネットワークドメインサーバ装置２の機能構成の一例を示す図である。 ネットワークドメインサーバ装置２の記憶装置２２に記憶されているユーザ情報に係るテーブルの一例を示す図である。 認可サーバ装置３の機能構成の一例を示す図（その１）である。 アクセス可否設定テーブル４３の一例を示す図である。 認可テーブル４４の一例を示す図である。 ネットワークログオンに係るシーケンスの一例を示す図である。 クライアント装置１のＣＳＳアプリケーションにより権限問い合わせに係るシーケンスの一例を示す図である。 Ｗｅｂサーバ装置４のＷｅｂアプリケーションによる権限問い合わせに係るシーケンスの一例を示す図である。 統合認証基盤システムのシステム構成の一例を示す図（その２）である。 認可サーバ装置３の機能構成の一例を示す図（その２）である。

符号の説明

１ クライアント装置
２ ネットワークドメインサーバ装置
３ 認可サーバ装置
４ Ｗｅｂサーバ装置

Claims (6)

1. ネットワークログオンによりシステムにシングルサインオンしたクライアント装置で動作するアプリケーション、又は前記システムに含まれるサーバ装置で動作するＷｅｂアプリケーションからのユーザの権限に係る権限情報の問い合わせを受け付け、前記権限情報を前記アプリケーションに提供するＷｅｂサービス手段を有し、
   前記Ｗｅｂサービス手段は、
   前記問い合わせに含まれる前記ユーザを識別するユーザ識別情報を取得し、前記ユーザ識別情報に基づいて、記憶装置に記憶されている、ユーザを識別するユーザ識別情報と前記ユーザの権限情報とが関連付けられた権限データを検索し、対応する権限情報を取得し、前記権限情報を要求元のアプリケーションに提供することを特徴とする認可サーバ装置。
2. 認可サーバ装置へのアクセス権に係るアクセス権限情報を管理する管理手段を更に有し、
   前記管理手段は、
   前記問い合わせに含まれる前記ユーザを識別するユーザ識別情報を取得し、前記ユーザ識別情報を含む前記ユーザに関するユーザ情報の取得要求をネットワークドメインサーバ装置に送信し、前記ネットワークドメインサーバ装置より取得した前記ユーザ情報に基づいて、記憶装置に記憶されている、ユーザに関するユーザ情報と前記アクセス権限情報とが関連付けられたアクセス権限データを検索し、対応するアクセス権限情報を取得し、前記アクセス権限情報に基づいて、認可サーバ装置へのアクセス権が存在するか否かを判定することを特徴とする請求項１に記載の認可サーバ装置。
3. 前記Ｗｅｂサービス手段は、前記管理手段で認可サーバ装置へのアクセス権が存在すると判定された場合、前記問い合わせに対する処理を実行することを特徴とする請求項２に記載の認可サーバ装置。
4. 前記Ｗｅｂサービス手段は、クライアント装置にインストールされたアプリケーション及びサーバ装置にインストールされたＷｅｂアプリケーションから前記問い合わせを受け付けることを特徴とする請求項１乃至３の何れか１項に記載の認可サーバ装置。
5. 認可サーバ装置における情報処理方法であって、
   ネットワークログオンによりシステムにシングルサインオンしたクライアント装置で動作するアプリケーション、又は前記システムに含まれるサーバ装置で動作するＷｅｂアプリケーションからのユーザの権限に係る権限情報の問い合わせを受け付け、前記権限情報を前記アプリケーションに提供するＷｅｂサービスステップを有し、
   前記Ｗｅｂサービスステップでは、
   前記問い合わせに含まれる前記ユーザを識別するユーザ識別情報を取得し、前記ユーザ識別情報に基づいて、記憶装置に記憶されている、ユーザを識別するユーザ識別情報と前記ユーザの権限情報とが関連付けられた権限データを検索し、対応する権限情報を取得し、前記権限情報を要求元のアプリケーションに提供することを特徴とする情報処理方法。
6. コンピュータを、
   ネットワークログオンによりシステムにシングルサインオンしたクライアント装置で動作するアプリケーション、又は前記システムに含まれるサーバ装置で動作するＷｅｂアプリケーションからのユーザの権限に係る権限情報の問い合わせを受け付け、前記権限情報を前記アプリケーションに提供するＷｅｂサービス手段として機能させるプログラムであって、
   前記Ｗｅｂサービス手段は、
   前記問い合わせに含まれる前記ユーザを識別するユーザ識別情報を取得し、前記ユーザ識別情報に基づいて、記憶装置に記憶されている、ユーザを識別するユーザ識別情報と前記ユーザの権限情報とが関連付けられた権限データを検索し、対応する権限情報を取得し、前記権限情報を要求元のアプリケーションに提供することを特徴とするプログラム。

Images