本発明は、併合情報提供装置、情報提供装置、管理装置、併合情報提供方法、情報提供方法、管理方法、併合情報提供プログラム、情報提供プログラム、管理プログラム及び記録媒体に関する。
認証プロバイダを利用してユーザの認証を行い、アプリケーションが提供するサービスを利用する従来例を、図1を用いて説明する。図1は、認証プロバイダを利用してユーザの認証を行い、アプリケーションが提供するサービスを利用する一例を説明するための図である。
図1のシステムは、Webブラウザ1と、Webポータル2と、アプリケーション3と、認証ディレクトリプロバイダ4とから構成される。
Webブラウザ1は、Webページを閲覧するソフトウェアである。
Webポータル2は、インターネットの入口となるWebサイトで、Webブラウザ1から利用できる様々なWebサービスを提供するWebサイトである。
アプリケーション3は、Webポータル2がWebブラウザ1に提供するサービスの1つである。
認証ディレクトリプロバイダ4は、登録されているユーザの認証及び該ユーザの所属するグループの情報などを提供するプロバイダである。
ステップS1では、Webブラウザ1が、ユーザによって入力されたログイン名とパスワードとをWebポータル2に送信する。
ステップS1に続いてステップS2に進み、Webポータル2は、ステップS1において受信したログイン名とパスワードとを含む後述する認証チケットの作成リクエストを認証ディレクトリプロバイダ4に送信する。
認証ディレクトリプロバイダ4では、受信した認証チケットの作成リクエストに含まれるログイン名とパスワードとに基づいて、登録されているユーザの正しいログイン名とパスワードとの組み合わせかどうかを判定し、登録されているユーザの正しい組み合わせであると判定した場合は、このことを認証する認証チケットを作成する。
ステップS2に続いてステップS3に進み、認証ディレクトリプロバイダ4は、前記作成した認証チケットのIDを含む認証チケットの作成レスポンスをWebポータル2に送信する。
ステップS3に続いてステップS4に進み、Webポータル2は、認証が成功した旨の情報をWebブラウザ1に送信する。
ステップS4に続いてステップS5に進み、Webブラウザ1は、アプリケーション3が提供するサービスの利用を開始する旨をWebポータル2に通知する。
ステップS5に続いてステップS6に進み、Webポータル2は、ステップS3において取得した認証チケットのIDを含むサービスの利用を許可するセッションチケットの作成リクエストをアプリケーション3に送信する。
ステップS6に続いてステップS7に進み、アプリケーション3は、当該アプリケーションの利用を許可しても良い、有効なユーザからのセッションチケットの作成リクエストかどうかを確認するために、前記認証チケットのIDを含むID確認リクエストをディレクトリプロバイダ4に送信する。
ステップS7に続いてステップS8に進み、認証ディレクトリプロバイダ4は、渡された認証チケットのIDが有効な認証チケットのIDかどうかを判定し、有効な認証チケットのIDであると判定した場合、該認証チケットのIDを作成したユーザの情報を含むID確認レスポンスを、アプリケーション3に送信する。
ステップS8に続いてステップS9に進み、アプリケーション3は、ステップS8において取得したユーザの情報から、ステップS6において取得したセッションチケットの作成リクエストは、当該アプリケーションの利用を許可しても良い、有効なユーザからのリクエストであると判定すると、セッションチケットを作成し、該セッションチケットのIDを含む、セッションチケットの作成レスポンスをWebポータル2に送信する。
ステップS9に続いてステップS10に進み、Webポータル2は、Webブラウザ1に対してサービスの利用が許可された旨を通知する。
ステップS10に続いてステップS11に進み、Webブラウザ1は、アプリケーション3が提供するサービスを利用する旨をWebポータル2に通知する。
ステップS11に続いてステップS12に進み、Webポータル2は、ステップS9において取得したセッションチケットのIDを含むサービスの利用リクエストをアプリケーション3に送信する。
ステップS12に続いてステップS13に進み、アプリケーション3は、サービスの利用リクエストに含まれるセッションチケットのIDの有効性を判定し、有効なセッションチケットのIDであると判定すると、指定されたサービスをWebポータル2に送信する。
ステップS13に続いてステップS14に進み、Webポータル2は、ステップS13において受信したサービスをWebブラウザ1に提供する。
図1を用いて説明したように、認証ディレクトリプロバイダ4は、Webポータル2より受信した認証チケットの作成リクエストに含まれるユーザ名とパスワードとを基に、登録されているユーザを認証する認証チケットを作成し、該認証チケットのIDを含む認証チケットの作成レスポンスをWebポータル2に送信する。また、認証ディレクトリプロバイダ4は、アプリケーション3より受信した認証チケットのIDの確認リクエストに含まれる前記認証チケットのIDを基に、ユーザの情報を含む認証チケットのIDの確認レスポンスをアプリケーション3に送信する。
しかしながら、一般的にWebポータル2は複数のWebサービスを提供するため、複数のアプリケーション及び該アプリケーションのユーザを認証する複数の認証プロバイダをサポートする。
図2は、1つのWebポータルが、複数のアプリケーションと複数の認証ディレクトリプロバイダとをサポートする一例を説明するための図である。
図2のシステムは、Webブラウザ1と、Webポータル2と、Windows(登録商標)アプリケーション5と、Notes(登録商標)アプリケーション6と、Windows(登録商標)認証ディレクトリプロバイダ7と、Notes(登録商標)認証ディレクトリプロバイダ8とから構成される。
図2は、図1に比べてWebポータル2が提供するアプリケーション及び該アプリケーションのユーザの認証を行う認証プロバイダがそれぞれ複数存在する。
図2に示すような構成を取ることによって、ユーザが、Windows(登録商標)認証ディレクトリプロバイダ7に登録されているユーザ名とパスワードとをWebブラウザ1に入力すれば、Windows(登録商標)認証ディレクトリプロバイダ7においてWindows(登録商標)のユーザとして認証され、Windows(登録商標)アプリケーション5を利用することができる。
また、ユーザが、Notes(登録商標)認証ディレクトリプロバイダ8に登録されているユーザのユーザ名とパスワードとをWebブラウザ1に入力すれば、Notes(登録商標)認証ディレクトリプロバイダ8においてNotes(登録商標)のユーザとして認証され、Notes(登録商標)アプリケーション6を利用することができる。
しかしながら、図2に示す構成の場合、Webポータル2に、Windows(登録商標)認証ディレクトリプロバイダ7にアクセスするアクセスモジュール101と、Notes(登録商標)認証ディレクトリプロバイダ8にアクセスするアクセスモジュール102とをそれぞれ別々に開発する必要があり、効率的ではない問題があった。
この問題を解決するためには、図3に示すような構成が考えられる。図3は、Webポータルにおけるアクセスモジュールを1つに統合した一例を説明するための図である。
図3のシステムは、Webブラウザ1と、Webポータル2と、Windows(登録商標)アプリケーション5と、Notes(登録商標)アプリケーション6と、Windows(登録商標)認証ディレクトリプロバイダ7と、Notes(登録商標)認証ディレクトリプロバイダ8と、プロバイダ9とから構成される。
図3は、図2に比べてWebポータル2におけるアクセスモジュール10を1つに統合するために、プロバイダ9が新たに設けられている。
プロバイダ9は、Webブラウザ1及びWebポータル2を介して取得したユーザ名とパスワードとをWindows(登録商標)認証ディレクトリプロバイダ7及びNotes(登録商標)認証ディレクトリプロバイダ8それぞれに送信して、それぞれに認証チケット作成のリクエストを行う。
プロバイダ9は、どちらか一方のプロバイダから認証チケットのIDを含む認証チケットの作成レスポンスを受信した場合は、前記認証チケットのIDをWebポータル2に送信する。
図3に示すような構成を取ることによって、Webポータル2のアクセスモジュール10を1つにすることができる。
しかしながら、図3に示すような構成において、新たなアプリケーションをWebポータル2に追加した場合、新たに追加したアプリケーションにおいて、例えばWindows(登録商標)認証ディレクトリプロバイダ7に登録されているWindows(登録商標)ユーザとNotes(登録商標)認証ディレクトリプロバイダ8に登録されているNotes(登録商標)ユーザとを区別しなくてはならない問題がある。
図3の構成に新たなアプリケーションを追加した一例を、図4を用いて説明する。
図4は、図3の構成に新たなアプリケーションを追加した一例を説明するための図である。
図4のシステムは、Webブラウザ1と、Webポータル2と、Windows(登録商標)認証ディレクトリプロバイダ7と、Notes(登録商標)認証ディレクトリプロバイダ8と、プロバイダ9と、アプリケーション11とから構成される。
図4は、図3と比べてWindows(登録商標)アプリケーション5及びNotes(登録商標)アプリケーション6に変わってアプリケーション11がWebポータル2に新たに追加された構成となっている。
このような構成において、例えばアプリケーション11が、Windows(登録商標)認証ディレクトリプロバイダ7で認証されたWindows(登録商標)ユーザも、Notes(登録商標)認証ディレクトリプロバイダ8で認証されたNotes(登録商標)ユーザも両方利用可能であるとした場合、アプリケーション11では、それぞれのユーザを識別するユーザIDを登録して、2つのユーザを管理しなくてはならなく、管理が煩雑になる問題があった。
例えば、Windows(登録商標)のユーザと、Notes(登録商標)のユーザとが同一人物で、該ユーザがWindows(登録商標)でもNotes(登録商標)でも同一のユーザIDを使用していたとしても、アプリケーション11では、Windows(登録商標)のユーザとしてのユーザID、Notes(登録商標)のユーザとしてのユーザIDと、別々に管理しなくてはならない問題があった。
一方、Windows(登録商標)認証ディレクトリプロバイダ7と、Notes(登録商標)認証ディレクトリプロバイダ8以外に、Local認証ディレクトリプロバイダ12を新たに導入する構成も考えられる。
図5は、Local認証ディレクトリプロバイダを導入した一例を説明するための図である。
図5のシステムは、Webブラウザ1と、Webポータル2と、Windows(登録商標)認証ディレクトリプロバイダ7と、Notes(登録商標)認証ディレクトリプロバイダ8と、プロバイダ9と、アプリケーション11と、Local認証ディレクトリプロバイダ12とから構成される。
図5は、図4と比べてLocal認証ディレクトリプロバイダ12が新たに導入されている。
図5に示すように、Windows(登録商標)認証ディレクトリプロバイダ7には、ユーザkana、kurose、maeda、aitoh、ikegami、rdhguestが登録されており、Notes(登録商標)認証ディレクトリプロバイダ8には、ユーザkana、kurose、maeda、aitoh、ikegamiが登録されている。
また、新たに導入されたLocal認証ディレクトリプロバイダ12には、ユーザkana、kurose、maeda及びgroup1、group2、が登録されている。
以下、図5に示したLocal認証ディレクトリプロバイダ12に登録されているグループのメンバーの一例を、図6を用いて説明する。図6は、図5に示したLocal認証ディレクトリプロバイダ12に登録されているグループのメンバーの一例を説明するための図である。
図6に示されるように、図5のLocal認証ディレクトリプロバイダ12は、当該自身のプロバイダ内のユーザやグループをグループのメンバーとして保持する。
しかしながら、このように当該自身のプロバイダ内のユーザやグループをグループのメンバーとして保持するLocalプロバイダ12を導入したとしても、図5のアプリケーション11は、Localプロバイダ12のユーザやグループ又は他のプロバイダのユーザやグループ等を別々に管理しなくてはならない問題があった。
また、従来例で示したシステムにおいては、例えばユーザがWebブラウザ1を介してログイン名とパスワードとを入力して認証を求めた場合、認証を行ったプロバイダ以外のプロバイダに登録されているユーザのユーザ情報及び/又はユーザの所属するグループ情報が取得できない問題があった。
図7は、従来のプロバイダの問題点を説明するための図である。例えば、Windows(登録商標)認証ディレクトリプロバイダ7で認証が行われた場合、Windows(登録商標)認証ディレクトリプロバイダ7に登録されているユーザkanaの情報や、ユーザkanaが所属するグループの情報は取得できても、Notes(登録商標)認証ディレクトリプロバイダ8に登録されているユーザkanaの情報や、ユーザkanaが所属するグループの情報は取得できない問題があった。
また、従来例では、プロバイダ9に接続されたWindows(登録商標)やNotes(登録商標)やLocalのプロバイダが認証とユーザ情報及び/又はユーザの所属するグループ情報の提供との両方を行う認証ディレクトリプロバイダについて説明したが、これらのプロバイダがユーザ情報及び/又はユーザの所属するグループ情報を提供するディレクトリプロバイダであっても、上記と同様ユーザによって入力されたログイン名とパスワードとに基づいて、利用が許可されたディレクトリプロバイダ以外のディレクトリプロバイダに登録されているユーザのユーザ情報及び/又はユーザの所属するグループ情報が取得できない問題があった。
本発明は、上記の点に鑑みなされたもので、認証及び/又は利用が許可されたプロバイダと共に、それ以外のプロバイダに登録されているユーザのユーザ情報及び/又はユーザの所属するグループ情報を取得することを目的とする。
そこで、上記問題を解決するため、本発明は、ユーザに係る情報を提供する複数のユーザ情報提供手段を下位のユーザ情報提供手段とする併合ユーザ情報提供手段を有する併合情報提供装置であって、前記ユーザに係る情報を前記ユーザ情報提供手段より取得し、該取得したユーザに係る情報を併合して提供することを特徴とする。
本発明によれば、ユーザに係る情報を提供する複数のユーザ情報提供手段を下位のユーザ情報提供手段とする併合ユーザ情報提供手段を有する併合情報提供装置であって、前記ユーザに係る情報を前記ユーザ情報提供手段より取得し、該取得したユーザに係る情報を併合して提供することによって、利用が許可されたプロバイダと共に、それ以外のプロバイダに登録されているユーザのユーザ情報及び/又はユーザの所属するグループ情報を取得することができる。
また、本発明は、ユーザに係る情報を提供すると共にユーザに係る認証サービスを提供する複数のユーザ情報提供手段を下位のユーザ情報提供手段とする併合ユーザ情報提供手段を有する併合情報提供装置であって、前記ユーザに係る情報を前記ユーザ情報提供手段より取得し、該取得したユーザに係る情報を併合して提供することを特徴とする。
本発明によれば、ユーザに係る情報を提供すると共にユーザに係る認証サービスを提供する複数のユーザ情報提供手段を下位のユーザ情報提供手段とする併合ユーザ情報提供手段を有する併合情報提供装置であって、前記ユーザに係る情報を前記ユーザ情報提供手段より取得し、該取得したユーザに係る情報を併合して提供することによって、認証されたプロバイダと共に、それ以外のプロバイダに登録されているユーザのユーザ情報及び/又はユーザの所属するグループ情報を取得することができる。
また、本発明は、ユーザに係る情報を提供するユーザ情報提供手段を有する情報提供装置であって、前記ユーザ情報提供手段は、当該ユーザ情報提供手段及び他のユーザ情報提供手段を下位のユーザ情報提供手段とする併合ユーザ情報提供手段からの要求に応じて、指定されたユーザのユーザに係る情報を前記併合ユーザ情報提供手段に提供するユーザ情報提供手段を有することを特徴とする。
本発明によれば、ユーザに係る情報を提供するユーザ情報提供手段を有する情報提供装置であって、前記ユーザ情報提供手段は、当該ユーザ情報提供手段及び他のユーザ情報提供手段を下位のユーザ情報提供手段とする併合ユーザ情報提供手段からの要求に応じて、指定されたユーザのユーザに係る情報を前記併合ユーザ情報提供手段に提供するユーザ情報提供手段を有することによって、指定されたユーザのユーザ情報及び/又はユーザの所属するグループ情報を提供することができる。
また、本発明は、ユーザに係る情報を提供すると共にユーザに係る認証サービスを提供するユーザ情報提供手段を有する情報提供装置であって、前記ユーザ情報提供手段は、当該ユーザ情報提供手段及び他のユーザ情報提供手段を下位のユーザ情報提供手段とする併合ユーザ情報提供手段からの要求に応じて、指定されたユーザのユーザに係る情報を前記併合ユーザ情報提供手段に提供するユーザ情報提供手段を有することを特徴とする。
本発明によれば、ユーザに係る情報を提供すると共にユーザに係る認証サービスを提供するユーザ情報提供手段を有する情報提供装置であって、前記ユーザ情報提供手段は、当該ユーザ情報提供手段及び他のユーザ情報提供手段を下位のユーザ情報提供手段とする併合ユーザ情報提供手段からの要求に応じて、指定されたユーザのユーザに係る情報を前記併合ユーザ情報提供手段に提供するユーザ情報提供手段を有することによって、指定されたユーザのユーザ情報及び/又はユーザの所属するグループ情報を提供することができる。
また、本発明は、前記併合情報提供装置に、前記下位のユーザ情報提供手段の設定に係る要求を送信する設定要求送信手段を有することを特徴とすることを特徴とする。
本発明によれば、前記併合情報提供装置に、前記下位のユーザ情報提供手段の設定に係る要求を送信する設定要求送信手段を有することを特徴とすることによって、下位のユーザ情報提供手段の設定を変更したり、新たに追加したりすることができる。
また、他の手段として、併合情報提供方法、情報提供方法、管理方法、併合情報提供プログラム、情報提供プログラム、管理プログラム及び記録媒体としてもよい。
なお、特許請求の範囲に記載の第一利用許可情報は、例えば、後述するサブプロバイダ14におけるセッションチケット300又は該セッションチケット300のセッションチケットID310に相当する。
また、特許請求の範囲に記載の第二利用許可情報は、例えば、後述するUnionマージプロバイダ13におけるセッションチケット200又は該セッションチケット200のセッションチケットID210に相当する。
また、特許請求の範囲に記載の第一認証情報は、例えば、後述するサブプロバイダ14における認証チケット600又は該認証チケット600の認証チケットID610に相当する。
また、特許請求の範囲に記載の第二認証情報は、例えば、後述するUnionマージプロバイダ13における認証チケット500又は該認証チケット500の認証チケットID510に相当する。
また、特許請求の範囲に記載のユーザ識別情報は、例えば、後述するUIDに相当する。
本発明によれば、認証及び/又は利用が許可されたプロバイダと共に、それ以外のプロバイダに登録されているユーザのユーザ情報及び/又はユーザの所属するグループ情報を取得することができる。
以下、本発明の実施の形態について図面に基づいて説明する。図8は、本発明によるUnionマージプロバイダを導入した一例を説明するための図である。
図8のシステムは、Webブラウザ1と、Webポータル2と、Windows(登録商標)認証ディレクトリプロバイダ7と、Notes(登録商標)認証ディレクトリプロバイダ8と、アプリケーション11と、Local認証ディレクトリプロバイダ12と、Unionマージプロバイダ13とから構成される。
図8は、従来の技術において説明した図5のプロバイダ9に変わって、Unionマージプロバイダ13が新たに導入されている。
本発明におけるUnionマージプロバイダ13は、後述するように、管理対象となるプロバイダ(以下、サブプロバイダともいう)が、登録されているユーザ情報及び/又はユーザの所属するグループ情報を提供するプロバイダであった場合は、ユーザによって入力されたログイン名とパスワードとによって、利用許可されたサブプロバイダ以外のサブプロバイダからもこれらのサブプロバイダに登録されているユーザ情報及び/又はユーザの所属するグループ情報を取得することができる。
また、Unionマージプロバイダ13は、接続されたサブプロバイダが、登録されているユーザ情報及び/又はユーザの所属するグループ情報を提供すると共にユーザに係る認証サービスを提供するプロバイダであった場合も、ユーザによって入力されたログイン名とパスワードとによって、認証されたサブプロバイダ以外のサブプロバイダに登録されているユーザ情報及び/又はユーザの所属するグループ情報を取得することができる。
なお、サブプロバイダは図8を例に取ると、Windows(登録商標)認証ディレクトリプロバイダ7、Local認証ディレクトリプロバイダ12、Notes(登録商標)認証ディレクトリプロバイダ8である。
以下、図8に示したLocal認証ディレクトリプロバイダ12に登録されているグループのメンバーの一例を、図9を用いて説明する。図9は、図8に示したLocal認証ディレクトリプロバイダに登録されているグループのメンバーの一例を説明するための図である。
図9に示されるように、図8のLocal認証ディレクトリプロバイダ12は、他のプロバイダのユーザやグループをLocal認証ディレクトリプロバイダ12のグループのメンバーとして保持する。
したがって、図8に示したLocal認証ディレクトリプロバイダ12のグループgroup1は、例えば、Windows(登録商標)認証ディレクトリプロバイダ7のユーザkanaと、Windows(登録商標)認証ディレクトリプロバイダ7のユーザmaedaと、Notes(登録商標)認証ディレクトリプロバイダ8のユーザkanaとをメンバーとして持つ。
また、図8に示したLocal認証ディレクトリプロバイダ12は、他のプロバイダのユーザ情報等をユーザIDとして保持する。
以下、図8に示したLocal認証ディレクトリプロバイダ12のユーザIDの構造の一例を、図10を用いて説明する。図10は、図8に示したLocal認証ディレクトリプロバイダのユーザIDの構造の一例を説明するための図である。
図10(A)に示すように、図8のLocal認証ディレクトリプロバイダ12のユーザIDは、IDタイプと、認証を行ったプロバイダの識別子と、認証を行ったプロバイダにおけるユーザの識別子とを含む。
IDタイプはユーザかグループかを表し、認証を行ったプロバイダの識別子は、例えばWindows(登録商標)、Notes(登録商標)などを表す。また認証を行ったプロバイダにおけるユーザの識別子は、例えば、kana、kurose、maedaなどを表す。
図10(B)は、図10(A)のユーザIDの一例である。Local認証ディレクトリプロバイダ12は、図10(B)に示されるようなユーザIDを保持することによって、例えばWindows(登録商標)認証ディレクトリプロバイダ7のユーザとNotes(登録商標)認証ディレクトリプロバイダ8のユーザとを区別した形で登録することができる。
このようなユーザIDを保持するLocalプロバイダ12を導入することによって、図8のアプリケーション11は、Localプロバイダ12のユーザIDに対応することで、他のプロバイダのユーザを別々に管理することなく、統合して扱うことができる。
したがって、ユーザは、Windows(登録商標)認証ディレクトリプロバイダ7で認証しても、Notes(登録商標)認証ディレクトリプロバイダ8で認証してもアプリケーション11を使用することができるようになる。
以下、図8において示したUnionマージプロバイダ13及び/又はサブプロバイダを実装する装置の一例を、図11を用いて説明する。
図11は、本発明による融合機の一実施例の構成図を示す。融合機120は、白黒ラインプリンタ15と、カラーラインプリンタ16と、スキャナやファクシミリなどのハードウェアリソース17と、ソフトウェア群20と、融合機起動部50とを有するように構成される。また、ソフトウェア群20はアプリケーション30とプラットフォーム40とを有するように構成される。
プラットフォーム40は、アプリケーション30からの処理要求を解釈してハードウェア資源の獲得要求を発生するコントロールサービスと、1つ以上のハードウェア資源の管理を行ってコントロールサービスからの獲得要求を調停するシステムリソースマネージャ(以下、SRMという)43と、オペレーティングシステム(以下、OSという)41とを有するように構成されている。
コントロールサービスは、システムコントロールサービス(以下、SCSという)42、エンジンコントロールサービス(以下、ECSという)44、メモリコントロールサービス(以下、MCSという)45、オペレーションパネルコントロールサービス(以下、OCSという)46、ファックスコントロールサービス(以下、FCSという)47、ネットワークコントロールサービス(以下、NCSという)48、ユーザ情報管理サービス(以下、UCSという)49など一つ以上のサービスモジュールを有するように構成されている。
なお、プラットフォーム40は予め定義されている関数によりアプリケーション30からの処理要求を受信可能とするアプリケーションプログラムインターフェース(以下、APIという)を有するように構成されている。
OS41は、ユニックス(UNIX(登録商標))などのオペレーティングシステムであって、プラットフォーム40及びアプリケーション30の各ソフトウェアをプロセスとして並列実行する。
SRM43のプロセスは、SCS42と共にシステムの制御及びリソースの管理を行うものである。例えばSRM43のプロセスは、スキャナ部やプリンタ部などのエンジン、メモリ、ハードディスク装置(HDD)ファイル、ホストI/O(セントロインターフェース、ネットワークインターフェース、IEEE1394インターフェース、RS232Cインターフェースなど)のハードウェア資源を利用する上位層からの要求に従って調停を行い、実行制御する。
例えば、SRM43は、要求されたハードウェア資源が利用可能であるか(他の要求により利用されていないかどうか)を判定し、利用可能であれば要求されたハードウェア資源が利用可能である旨を上位層に通知する。また、SRM43は、上位層からの要求に対してハードウェア資源の利用スケジューリングを行い、例えばプリンタエンジンによる紙搬送と作像動作、メモリ確保、ファイル生成などの要求内容を直接実施している。
SCS42のプロセスは、アプリケーション管理、操作部制御、システム画面表示、LED表示、リソース管理、割り込みアプリケーション制御を行う。ECS44のプロセスは、白黒ラインプリンタ15、カラーラインプリンタ16、ハードウェアリソース17のエンジンの制御を行う。
MCS45のプロセスは、画像メモリの取得及び解放、ハードディスク装置(HDD)の利用、画像データの圧縮及び伸張などを行う。OCS46のプロセスは、オペレータと本体制御との間の情報伝達手段となるオペレーションパネルの制御を行う。
FCS47のプロセスは、システムコントローラの各アプリケーション層からPSTNまたはISDN網を利用したファクシミリ送受信、BKM(バックアップSRAM)で管理されている各種ファクシミリデータの登録/引用、ファクシミリ読み取り、ファクシミリ受信印刷、融合送受信を行うためのアプリケーションを提供する。
NCS48のプロセスは、ネットワークI/Oを必要とするアプリケーションに対し、共通に利用できるサービスを提供するものであり、ネットワーク側から各プロトコルによって受信したデータを各アプリケーションに振り分けたり、アプリケーションからのデータをネットワーク側に送信する際の仲介を行ったりする。
UCS49のプロセスは、ユーザ情報及び/又はユーザの所属するグループ情報の管理を行うものであり、要求に応じたユーザ情報及び/又はユーザの所属するグループ情報が格納されている記憶装置及び/又はネットワークを介して接続された他の装置を判定し、判定した記憶装置及び/又はネットワークを介して接続された他の装置からユーザ情報及び/又はユーザの所属するグループ情報を取得して各アプリケーションに供給する。
また、UCS49のプロセスは、ユーザ情報及び/又はユーザの所属するグループ情報の管理を行うと共に、ユーザに係る認証サービスを提供するようにしてもよい。
図8において説明したUnionマージプロバイダ13及び/又は他のサブプロバイダ(例えば、Local認証ディレクトリプロバイダ12など)は、UCS49に実装する。
また、アプリケーション30は、プリンタ、コピー、ファクシミリ、スキャナなどの画像形成処理にかかるユーザサービスにそれぞれ固有の処理を行うものである。アプリケーション30は、ページ記述言語(PDL、PCL)及びポストスクリプト(PS)を有するプリンタ用のアプリケーションであるプリンタアプリ31と、コピー用アプリケーションであるコピーアプリ32と、ファクシミリ用アプリケーションであるファックスアプリ33と、スキャナ用アプリケーションであるスキャナアプリ34と、ネットワークファイル用アプリケーションであるネットファイルアプリ35と、工程検査用アプリケーションである工程検査アプリ36とを有している。
融合機起動部50は、融合機120の電源投入時に最初に実行され、アプリケーション30やプラットフォーム40を起動するものである。例えば融合機起動部50は、コントロールサービスやアプリケーションのプログラムを後述するフラッシュメモリから読み出し、読み出した各プログラムをSRAMまたはSDRAM上に確保したメモリ領域に転送して起動するものである。
図12は、本発明による融合機の一実施例のハードウェア構成図を示す。図12の融合機120は、コントローラボード60と、オペレーションパネル70と、ファックスコントロールユニット(以下、FCUという)80と、USBデバイス90と、IEEE1394デバイス100と、ドライバI/F101と、エンジン部110と、を有するように構成される。
ここで、ドライバI/F101は、挿入された、Unionマージプロバイダ13及び/又はサブプロバイダ14に対応するプログラム等が格納されている記録媒体から、Unionマージプロバイダ13及び/又はサブプロバイダ14に対応するプログラム等を読み込んで、融合機120搭載するのに用いるI/Fである。なお、例えば記録媒体としては、SDメモリカード、スマートメディア、マルチメディアカード、コンパクトフラッシュ(登録商標)等がある。
オペレーションパネル70は、コントローラボード60のASIC62に直接接続されている。また、FCU80、USBデバイス90、IEEE1394デバイス100、ドライバI/F101及びエンジン部110は、コントローラボード60のASIC62にPCIバス(Peripheral Component Interconnect bus)などで接続されている。
また、コントローラボード60は、CPU61と、ASIC62と、SRAM(Static RAM)63と、SDRAM(Synchronous DRAM)64と、フラッシュメモリ65と、HDD66とを有するように構成される。コントローラボード60は、CPU61、SRAM63、SDRAM64、フラッシュメモリ65、HDD66などをASIC62に接続するように構成されている。
CPU61は、融合機120の全体制御を行うものである。CPU61は、OS41上でプラットフォーム40を形成するSCS42、SRM43、ECS44、MCS45、OCS46、FCS47及びNCS48をそれぞれプロセスとして起動して実行させると共に、アプリケーション30を形成するプリンタアプリ31、コピーアプリ32、ファックスアプリ33、スキャナアプリ34、ネットファイルアプリ35及び工程検査アプリ36を起動して実行させる。
ASIC62は、画像処理用のハードウェア要素を有する画像処理用途向けのICである。SRAM63及びSDRAM64の物理メモリ領域には、カーネルやプロセスなどの仮想メモリ領域がマッピングされる。
以下、図13から図15を用いて、UCS49の構成例について説明する。図13は、UCSの構成を説明するための図(その1)である。
図13に示すように、UCS49は、図8のUnionマージプロバイダ13と、1つ以上のサブプロバイダ14とから構成される。
図13に示される構成をとることによって、UCS49は、後述するように、サブプロバイダ14が提供するユーザ情報及び/又はユーザの所属するグループ情報をUnionマージプロバイダ13において統合し、例えば、融合機120のアプリケーション30などに、マージしたユーザ情報及び/又はユーザの所属するグループ情報を提供することができる。
図14は、UCSの構成を説明するための図(その2)である。図14に示すように、UCS49は、サブプロバイダ14を含まず、図8のUnionマージプロバイダ13のみから構成される。
図14に示される構成をとることによって、例えば他の装置に実装されているサブプロバイダ14が提供するユーザ情報及び/又はユーザの所属するグループ情報をUnionマージプロバイダ13においてマージし、例えば、融合機120のアプリケーション30などに、マージしたユーザ情報及び/又はユーザの所属するグループ情報を提供することができる。
図15は、UCSの構成を説明するための図(その3)である。図15に示すように、UCS49は、図8のUnionマージプロバイダ13を含まず、少なくとも1つ以上のサブプロバイダ14から構成される。
図15に示される構成をとることによって、例えば他の装置に実装されているUnionマージプロバイダ13からの要求に応じてユーザ情報及び/又はユーザの所属するグループ情報を提供することができる。
以下では、説明の簡略化のため、Unionマージプロバイダ13とサブプロバイダ14とを用いて説明を行う。
図16は、本発明の第一実施例におけるUnionマージプロバイダとサブプロバイダとの機能ブロック図である。
なお、第一の実施例においては、説明の簡略化のため、Unionマージプロバイダ13及びサブプロバイダ14は、ユーザ情報及び/又はユーザの所属するグループ情報を提供し、ユーザの認証は行わないものとする。
図16に示すように、Unionマージプロバイダ13は、プロバイダI/F130と、マージ処理部133と、サブプロバイダ呼び出し部134と、マージプロバイダXML処理部135と、サブプロバイダ登録部136と、セッション管理部137とから構成される。
また、プロバイダI/F130は、XML処理部131と、UID変換部132とから構成される。
プロバイダI/F130は、Unionマージプロバイダ13と他のプロバイダ及び/又は他のアプリケーションとをつなぐインターフェースである。なお、後述するように、サブプロバイダ14も同様のプロバイダI/F130を有する。
XML処理部131は、他のアプリケーションやWebポータルなどから送信されてきたXMLメッセージを解析して、Unionマージプロバイダ13内においてプログラムが利用可能な形に処理する。
また、逆に、UID変換部132から渡されたデータなどを基にXMLメッセージを作成し、アプリケーションやWebポータルなどに送信する。
なお、アプリケーションやWebポータルは、図11を用いて説明したアプリケーション30であってもよいし、融合機120とネットワークを介して接続された他の融合機120又は他の装置のアプリケーションであってもよい。
UID変換部132は、必要があれば、XMLメッセージに含まれているユーザID(以下、UIDという)を変換する。
例えば、XMLメッセージに含まれていたUIDが従来の技術の図10において説明したU:Windows(登録商標):kanaの構成であり、プロバイダ内部でのUIDの構成がkanaだった場合は、UID変換部132は、U:Windows(登録商標):kanaからkanaにUIDを変換する。同様に、プロバイダからXMLメッセージを送信する場合で、必要な場合は、kanaからU:Windows(登録商標):kanaへのUIDの変換も行う。
マージ処理部133は、後述するように、サブプロバイダ14に登録されているユーザのユーザ情報及び/又はユーザの所属するグループ情報をマージする。
サブプロバイダ呼び出し部134は、サブプロバイダ14に送信するXMLメッセージを作成するのに必要なデータを、後述するマージプロバイダXML処理部135に渡す。
また、サブプロバイダ呼び出し部134は、後述するマージプロバイダXML処理部135を介してサブプロバイダ14から取得したユーザ情報及び/又はユーザの所属するグループ情報を、マージ処理部133に渡す。
マージプロバイダXML処理部135は、サブプロバイダ呼び出し部134より渡されたデータを基にXMLメッセージを作成し、指定されたサブプロバイダ14に送信する。
また、マージプロバイダXML処理部135は、サブプロバイダ14から送信されたXMLメッセージを受信して、XMLメッセージに含まれているデータをサブプロバイダ呼び出し部134に渡す。
サブプロバイダ登録部136には、管理対象となるサブプロバイダ14に関するデータが登録されている。サブプロバイダ登録部136には、例えば、サブプロバイダ14の識別子、サブプロバイダ14の名前、サブプロバイダ14の管理用ID、サブプロバイダ14の管理用パスワードなどがそれぞれサブプロバイダ14ごとに登録されている。
例えば、新たなサブプロバイダ14をUnionマージプロバイダ13に登録する際は、前記サブプロバイダ14の識別子、サブプロバイダ14の名前、サブプロバイダ14の管理用ID、サブプロバイダ14の管理用パスワードをそれぞれサブプロバイダ登録部136に登録する。
セッション管理部137は、Unionマージプロバイダ13と他のサブプロバイダ14及び他のアプリケーションやWebポータルなどとのセッションを管理する。
例えば、XML処理部131において取得したXMLメッセージに、Unionプロバイダ13の利用を許可した有効なセッションチケット200のセッションチケットID210が含まれているかどうかを解析する。
また、セッション管理部137は、サブプロバイダ登録部136に登録されているサブプロバイダ14の管理用IDとサブプロバイダ14の管理用パスワードとを用いて、サブプロバイダ14から匿名のセッションチケット300のセッションチケットID310を取得する。
セッション管理部137は、取得したサブプロバイダ14のセッションチケットID310などを用いて、後述するUnionマージプロバイダ13のセッションチケット200を作成する。
セッション管理部137は、例えば、ユーザがUIDとパスワードとを用いてセッションチケット400の作成を要求したサブプロバイダ14以外のサブプロバイダ14からも匿名のセッションチケット300のセッションチケットID310を取得することができるため、Unionマージプロバイダ13は、管理対象としているサブプロバイダ14全てからユーザ情報及び/又はユーザの所属するグループ情報を取得することができる。
図17は、Unionマージプロバイダのセッションチケットの構造を説明するための概念図である。
図17に示すように、Unionマージプロバイダ13のセッションチケット200は、セッションチケットID210と、プロバイダタイプと、公開するプロバイダ名と、1つ以上のサブプロバイダ名と、1つ以上のサブプロバイダのセッションチケット300及び/又はセッションチケット400とを構造として持つ。
セッションチケットID210は、当該セッションチケットを識別する識別子である。プロバイダタイプは、例えば「Unionマージ」など、プロバイダのタイプである。
公開するプロバイダ名は、例えば「Unionマージ1」など、公開するUnionマージプロバイダ13の名前である。
サブプロバイダ名は、登録されている1つ以上のサブプロバイダ14の名前である。サブプロバイダのセッションチケットには、前記登録されている1つ以上のサブプロバイダ14とUnionマージプロバイダ13とのセッションチケット300及び/又はセッションチケット400が格納されている。
また、セッションチケット400は、ユーザによって入力されたUIDとパスワードとを基に作成されたサブプロバイダ14のセッションチケットであり、セッションチケット300は、サブプロバイダ登録部136に格納されている管理者権限の管理用IDと管理用パスワードと基に作成されたサブプロバイダ14のセッションチケットである。
なお、以下では説明の簡略化のため、Unionマージプロバイダ13のセッションチケット200に含まれるサブプロバイダ14のセッションチケットは、匿名のセッションチケット300のみであるとして説明を行う。
図17に示すような階層構造を持つことによって、サブプロバイダ14がUnionマージプロバイダ13となることも可能となる。
なお、図17においては、サブプロバイダのセッションチケットには、前記登録されている1つ以上のサブプロバイダ14とUnionマージプロバイダ13とのセッションチケット300及び/又はセッションチケット400が格納されている例を用いて説明を行ったが、デコードされたセッションチケット300及び/又はセッションチケット400が格納されていてもよい。
図16のサブプロバイダ14は、プロバイダI/F130と、ディレクトリ操作ラッパー141と、セッション管理部142とから構成される。
ディレクトリ操作ラッパー141は、サブプロバイダ14内のデータをディレクトリ150のユーザ情報保存部152に保存されているユーザ情報やグループ情報保存部153に保存されているユーザの所属するグループ情報を操作可能なデータに変形し、前記ユーザ情報や前記ユーザの所属するグループ情報をディレクトリ150から取得する。
また、取得したユーザ情報やグループ情報をサブプロバイダ14内において処理可能なデータに変形する。
ディレクトリ操作ラッパー141のデータの変形の一例は、後述する図18を用いて説明する。
セッション管理部142は、サブプロバイダ14とUnionマージプロバイダ13とのセッションを管理する。
例えば、XML処理部131において取得したXMLメッセージに、サブプロバイダ14の利用を許可した有効なセッションチケット300のセッションチケットID310が含まれているかどうかを解析する。
また、セッション管理部142は、プロバイダI/F130を介して、Unionマージプロバイダ13から管理用IDと管理用パスワードと含む匿名のセッションチケット300の作成リクエストを取得すると、匿名のセッションチケット300を作成する。
また、セッション管理部142は、前記作成した匿名のセッションチケット300のセッションチケットID310をプロバイダI/F130に渡し、セッションチケットID310を含む匿名のセッションチケット300の作成レスポンスをUnionマージプロバイダ13に送信する。
また、図16のディレクトリ150は、ユーザ情報保存部152と、グループ情報保存部153とを含む。
ユーザ情報保存部152は、サブプロバイダ14に登録されているユーザのユーザ情報が保存されている。例えば、UIDや、ユーザの名前、ユーザのパスワードなどが保存されている。
また、グループ情報保存部153には、サブプロバイダ14に登録されているユーザが所属するグループ情報が保存されている。例えば、グループID、グループの名前、グループのメンバーなどが保存されている。
図18は、ディレクトリ操作ラッパーのデータの変形の一例を説明するための図である。
図18(A)は、サブプロバイダ14内のデータをディレクトリ150のユーザ情報保存部152に保存されているユーザ情報やグループ情報保存部153に保存されているユーザの所属するグループ情報を操作可能なデータに変形した一例である。
図18(B)は、ディレクトリ150のユーザ情報保存部152に保存されているユーザ情報やグループ情報保存部153に保存されているユーザの所属するグループ情報のデータをサブプロバイダ14内で処理可能なデータに変形した一例である。
図19は、Unionマージプロバイダにおけるユーザの所属グループ取得処理の一例のフローチャートである。
なお、以下では、説明の簡略化のため、Unionマージプロバイダ13にユーザが所属するグループ情報の取得リクエストを送信するアプリケーション又はWebポータルなどを単にクライアントという。
ステップS20では、Unionマージプロバイダ13のXML処理部131は、クライアントよりユーザの所属グループの取得リクエストを受信する。
クライアントからUnionマージプロバイダ13へのグループ取得リクエストの一例は、後述する図21を用いて説明する。
ステップS20に続いてステップS21に進み、セッション管理部137は、ステップS20において受信したユーザの所属グループの取得リクエストに含まれるUnionマージプロバイダ13のセッションチケット200のセッションチケットID210が有効なセッションチケットID210であるかどうかを判定する。
有効なセッションチケット200のセッションチケットID210であると判定すると(ステップS21においてYES)、ステップS22に進み、無効なセッションチケット200のセッションチケットID210であると判定すると(ステップS21においてNO)、ステップS26に進む。
ステップS22では、セッション管理部137は、Unionマージプロバイダ13のセッションチケット200に含まれる全てのサブプロバイダ14のセッションチケット300のセッションチケットID310と、サブプロバイダ名とをサブプロバイダ呼び出し部134に渡す。
ステップS22に続いてステップS23に進み、マージプロバイダXML処理部135は、サブプロバイダ呼び出し部134を介して取得した、サブプロバイダ14のセッションチケット300のセッションチケットID310を含む各サブプロバイダ14に対するユーザの所属グループの取得リクエストを作成し、各サブプロバイダ14に送信する。
Unionマージプロバイダ13から各サブプロバイダ14へのグループ取得リクエストの一例は、後述する図22を用いて説明する。
ステップS23に続いてステップS24に進み、サブプロバイダ呼び出し部134は、マージプロバイダXML処理部135を介して、各サブプロバイダ14からユーザの所属グループの取得リクエストに対する所属グループ取得レスポンスを受信する。
各サブプロバイダ14からUnionマージプロバイダ13へのグループ取得レスポンスの一例は、後述する図23を用いて説明する。
ステップS24に続いてステップS25に進み、サブプロバイダ呼び出し部134は、ステップS24において受信した各サブプロバイダ14からの所属グループ取得レスポンスに、指定したユーザの所属グループ情報が含まれているかどうかを判定する。
ユーザの所属グループ情報が1つでも含まれていると判定すると(ステップS25においてYES)、ステップS27に進み、ユーザの所属グループが1つも含まれていないと判定すると(ステップS25においてNO)、ステップS26に進む。
ステップS26では、Unionマージプロバイダ13のXML処理部131は、ユーザの所属グループの取得が失敗した旨のレスポンスを作成し、クライアントに送信する。
ステップS27では、マージ処理部133が、ステップS24において取得した各サブプロバイダ14からの所属グループ取得レスポンスに含まれるユーザの所属グループをマージする。
ステップS27に続いてステップS28に進み、Unionマージプロバイダ13のXML処理部131は、ステップS27においてマージしたユーザの所属グループの情報を含む所属グループ取得レスポンスを作成し、クライアントに送信する。
Unionマージプロバイダ13からクライアントへのグループ取得レスポンスの一例は、後述する図24を用いて説明する。
図20は、サブプロバイダにおけるユーザの所属グループ取得処理の一例のフローチャートである。
サブプロバイダ14は、図19のステップS23においてUnionマージプロバイダ13が、ユーザの所属グループの取得リクエストを各サブプロバイダ14に送信すると、以下に示すステップS30からの処理を開始する。
ステップS30では、サブプロバイダ14のXML処理部131は、Unionマージプロバイダ13よりユーザの所属グループの取得リクエストを受信する。
上述したように、Unionマージプロバイダ13から各サブプロバイダ14へのグループ取得リクエストの一例は、後述する図22を用いて説明する。
ステップS30に続いてステップS31に進み、サブプロバイダ14のUID変換部132は、ステップS30において受信したユーザの所属グループの取得リクエストに含まれるUIDをディレクトリ150固有のUIDに変換する。
ステップS31に続いてステップS32に進み、セッション管理部142は、ステップS30において受信したユーザの所属グループの取得リクエストに含まれるサブプロバイダ14のセッションチケット300のセッションチケットID310が有効なセッションチケット300のセッションチケットID310であるかどうかを判定する。
有効なセッションチケット300のセッションチケットID310であると判定すると(ステップS32においてYES)、ステップS34に進み、無効なセッションチケット300のセッションチケットID310であると判定すると(ステップS32においてNO)、ステップS33に進む。
ステップS33では、サブプロバイダ14のXML処理部131は、ユーザの所属グループの取得が失敗した旨の所属グループ取得レスポンスを作成し、Unionマージプロバイダ13に送信する。
ステップS34では、サブプロバイダ14は、ディレクトリ操作ラッパー141を介してディレクトリ150からユーザの所属するグループ情報を取得する。
ステップS34に続いてステップS35に進み、サブプロバイダ14のUID変換部132は、ディレクトリ150固有のUIDをUnionマージプロバイダ13が利用可能なUIDに変換する。
ステップS35に続いてステップS36に進み、サブプロバイダ14のXML処理部131は、ユーザの所属グループの情報を含む所属グループ取得レスポンスを作成し、Unionマージプロバイダ13に送信する。
上述したように、各サブプロバイダ14からUnionマージプロバイダ13へのグループ取得レスポンスの一例は、後述する図23を用いて説明する。
なお、図19のステップS24は、図20のステップS33又はステップS36において送信した所属グループ取得レスポンスを受信する。
図21は、クライアントからUnionマージプロバイダへのグループ取得リクエストの一例のXMLメッセージである。
図21に示すように、クライアントからUnionマージプロバイダ13へのユーザの所属するグループの取得リクエストには、<sessionTicket></sessionTicket>のタグに、Unionマージプロバイダ13のセッションチケット200のセッションチケットID210が含まれている。
また、<id></id>のタグには、ユーザを特定するUIDが含まれている。
クライアントは、ユーザのUIDとUnionマージプロバイダ13のセッションチケット200のセッションチケットID210とを含むユーザの所属するグループ取得リクエストをUnionマージプロバイダ13へ送信する。
図22は、Unionマージプロバイダからサブプロバイダへのグループ取得リクエストの一例のXMLメッセージである。
図22(A)は、Unionマージプロバイダ13からサブプロバイダ14の1つであるLocalディレクトリプロバイダ160へのグループ取得リクエストの一例のXMLメッセージである。
図22(A)に示すように、Unionマージプロバイダ13からLocalディレクトリプロバイダ160へのユーザの所属するグループの取得リクエストには、<sessionTicket></sessionTicket>のタグに、Localディレクトリプロバイダ160のセッションチケット300のセッションチケットID310が含まれている。
また、<id></id>のタグには、ユーザを特定するUIDが含まれている。なお、このUIDは、図21のXMLメッセージに含まれるUIDと同様のものである。
図22(B)は、Unionマージプロバイダ13からサブプロバイダ14の1つであるWinNT4ディレクトリプロバイダ161へのグループ取得リクエストの一例のXMLメッセージである。
図22(B)に示すように、Unionマージプロバイダ13からWinNT4ディレクトリプロバイダ161へのユーザの所属するグループの取得リクエストには、<sessionTicket></sessionTicket>のタグに、WinNT4ディレクトリプロバイダ161のセッションチケット300のセッションチケットID310が含まれている。
また、<id></id>のタグには、ユーザを特定するUIDが含まれている。なお、このUIDは、図21のXMLメッセージに含まれるUIDと同様のものである。
図22(C)は、Unionマージプロバイダ13からサブプロバイダ14の1つであるNotes(登録商標)R5ディレクトリプロバイダ162へのグループ取得リクエストの一例のXMLメッセージである。
図22(C)に示すように、Unionマージプロバイダ13からNotes(登録商標)R5ディレクトリプロバイダ162へのユーザの所属するグループの取得リクエストには、<sessionTicket></sessionTicket>のタグに、Notes(登録商標)R5ディレクトリプロバイダ162のセッションチケット300のセッションチケットID310が含まれている。
また、<id></id>のタグには、ユーザを特定するUIDが含まれている。なお、このUIDは、図21のXMLメッセージに含まれるUIDと同様のものである。
Unionマージプロバイダ13は、図17において説明したように、セッションチケットを階層的な構造で管理しているため、クライアントから送信されたユーザのグループの取得リクエストに含まれるUnionマージプロバイダ13のセッションチケット200のセッションチケットID210を基に、サブプロバイダ14であるLocalディレクトリプロバイダ160や、WinNT4ディレクトリプロバイダ161及びNotes(登録商標)R5ディレクトリプロバイダ162のセッションチケット300のセッションチケットID310を取得し、該セッションチケットID310をそれぞれへのXMLメッセージに含めることができる。
図23は、サブプロバイダからUnionマージプロバイダへのグループ取得レスポンスの一例のXMLメッセージである。
図23(A)は、サブプロバイダ14の1つであるLocalディレクトリプロバイダ160からUnionマージプロバイダ13へのグループ取得レスポンスの一例のXMLメッセージである。
図23(A)に示すように、Localディレクトリプロバイダ160からUnionマージプロバイダ13へのユーザの所属するグループの取得レスポンスには、<groupList></groupList>のタグに含まれる各<item></item>のタグに、指定されたユーザのLocalディレクトリプロバイダ160における所属するグループ情報が含まれている。
図23(B)は、サブプロバイダ14の1つであるWinNT4ディレクトリプロバイダ161からUnionマージプロバイダ13へのグループ取得レスポンスの一例のXMLメッセージである。
図23(B)に示すように、WinNT4ディレクトリプロバイダ161からUnionマージプロバイダ13へのユーザの所属するグループの取得レスポンスには、<groupList></groupList>のタグに含まれる各<item></item>のタグに、指定されたユーザのWinNT4ディレクトリプロバイダ161における所属するグループ情報が含まれている。
図23(C)は、サブプロバイダ14の1つであるNotes(登録商標)R5ディレクトリプロバイダ162からUnionマージプロバイダ13へのグループ取得レスポンスの一例のXMLメッセージである。
図23(C)に示すように、Notes(登録商標)R5ディレクトリプロバイダ161は、指定されたユーザが所属するグループ情報が存在しない場合には、<item></item>のタグを含まない取得レスポンスを、Unionマージプロバイダ13へ送信する。
各サブプロバイダ14は、指定されたユーザが所属するグループが存在する場合は、該所属するグループの情報をディレクトリ150から取得し、Unionマージプロバイダ13に送信する。
図24は、Unionマージプロバイダからクライアントへのグループ取得レスポンスの一例のXMLメッセージである。
図24に示されるように、Unionマージプロバイダ13は、1つの<groupList></groupList>のタグに、各サブプロバイダ14から取得した、グループ情報が含まれる<item></item>のタグをマージして格納し、クライアントへ送信する。
クライアントは、Unionマージプロバイダ13のセッションチケット200のセッションチケットID210とユーザを特定するUIDとを含むユーザの所属するグループの取得リクエストを、Unionマージプロバイダ13に送信することによって、Unionマージプロバイダ13が管理している、ディレクトリ150に係るサービスを提供する各サブプロバイダ14に登録されているユーザの所属するグループの情報を、Unionマージプロバイダ13から取得することができる。
例えば、図24の<item>G:Local:group1</item>と<item>G:Local:group2</item>とは、WinNT4ディレクトリプロバイダ161のユーザとしてLocalディレクトリプロバイダ160に登録されているユーザ323−53454244が所属するグループの情報であり、図24の<item>G:WinNT4:group1</item>と<item>G:WinNT4:group2</item>とは、WinNT4ディレクトリプロバイダ161のユーザとしてWinNT4ディレクトリプロバイダ161に登録されているユーザ323−53454244が所属するグループの情報である。
なお、第一の実施例の説明においては、Unionマージプロバイダ13とサブプロバイダ14との間、及びUnionマージプロバイダ13とクライアントとの間は、セッションチケットID210及び/又はセッションチケットID310を送受信する場合を例にとって説明したが、これは本実施を制限するものではなく、セッションチケット200及び/又はセッションチケット300を送受信してもよい。
以上、第一の実施例においては、サブプロバイダ14が、認証を必要としない場合について説明を行ったが、以下に示す第二の実施例においては、サブプロバイダ14が認証を必要とする場合について説明する。
図25は、本発明の第二実施例におけるUnionマージプロバイダとサブプロバイダとの機能ブロック図である。
なお、上述したように、第二の実施例においては、サブプロバイダ14は、ユーザ情報及び/又はユーザの所属するグループ情報を提供すると共に、ユーザに係る認証サービスを提供するものとする。
図25に示すように、Unionマージプロバイダ13は、プロバイダI/F130と、マージ処理部133と、サブプロバイダ呼び出し部134と、マージプロバイダXML処理部135と、サブプロバイダ登録部136と、セッション管理部137と、IDパスワード解析部138と、認証チケット管理部139とから構成される。
また、プロバイダI/F130は、XML処理部131と、UID変換部132とから構成される。
図25の第二実施例におけるUnionマージプロバイダ13の構成は、図16の第一実施例におけるUnionマージプロバイダ13の構成と比べて、IDパスワード解析部138と、認証チケット管理部139とが新たに追加されている。
IDパスワード解析部138は、クライアント(例えば、Webポータル)から送信されたUnionマージプロバイダ13におけるユーザを認証する認証チケット500の作成リクエストに含まれるIDとパスワードとを取得して、サブプロバイダ呼び出し部134に渡す。
サブプロバイダ呼び出し部134は、IDパスワード解析部138より渡されたIDとパスワードとを後述するマージプロバイダXML処理部135に渡す。
また、サブプロバイダ呼び出し部134は、後述するように、マージプロバイダXML処理部135を介して、認証に成功した1つのサブプロバイダ14から取得した該サブプロバイダ14におけるユーザを認証する認証チケット600の認証チケットID610を、認証チケット管理部139に渡す。
マージプロバイダXML処理部135は、サブプロバイダ呼び出し部134より渡されたデータを基にXMLメッセージを作成し、サブプロバイダ登録部136に登録されている全てのサブプロバイダ14に対して送信する。
また、マージプロバイダXML処理部135は、サブプロバイダ14からのXMLメッセージを受信して、データをサブプロバイダ呼び出し部134に渡す。
例えば、認証に成功した1つのサブプロバイダ14からの認証レスポンスを受信すると、該サブプロバイダ14におけるユーザを認証する認証チケット600の認証チケットID610をサブプロバイダ呼び出し部134に渡す。
認証チケット管理部139は、認証に成功したサブプロバイダ14より取得した認証チケット600の認証チケットID610を基に、Unionマージプロバイダ13におけるユーザを認証する認証チケット500を作成し、管理する。
また、認証チケット管理部139は、前記作成したUnionマージプロバイダ13におけるユーザを認証する認証チケット500の認証チケットID510を、Unionマージプロバイダ13のプロバイダI/F130を介して、認証の要求を行ったクライアント(例えば、Webポータル)に送信する。
図26は、Unionマージプロバイダの認証チケットの構造を説明するための概念図である。
図26に示すように、Unionマージプロバイダ13の認証チケット500は、認証チケットID510と、プロバイダタイプと、公開するプロバイダ名と、サブプロバイダ名と、サブプロバイダの認証チケット600とを構造として持つ。
認証チケットID510は、当該認証チケットを識別する識別子である。プロバイダタイプは、例えば「Unionマージ」など、プロバイダのタイプである。
公開するプロバイダ名は、例えば「Unionマージ1」など、公開するUnionマージプロバイダ13の名前である。
サブプロバイダ名は、登録されているサブプロバイダ14の内、認証が成功し、認証チケット600の送信があったサブプロバイダ14の名前である。サブプロバイダの認証チケットは、認証が成功し、認証チケット600の送信があったサブプロバイダ14の認証チケット600である。
図26に示すような構造を持つことによって、ユーザは認証を一回で終えることが可能となる。
なお、サブプロバイダの認証チケットとして、認証が成功し、認証チケット600の送信があったサブプロバイダ14の認証チケット600をデコードしたものを含むようにしてもよい。
図25のサブプロバイダ14は、プロバイダI/F130と、ディレクトリ操作ラッパー141と、セッション管理部142と、IDパスワード解析部143と、認証チケット管理部144とから構成される。
図25の第二実施例におけるサブプロバイダ14の構成は、図16の第一実施例におけるサブプロバイダ14の構成に比べて、IDパスワード解析部143と、認証チケット管理部144とが新たに追加されている。
IDパスワード解析部143は、Unionマージプロバイダ13から送信された認証チケット600の作成リクエストに含まれるIDとパスワードとを取得して、ディレクトリ操作ラッパー141を介して、IDとパスワードとが正しい組み合わせであるかどうかをディレクトリ150のユーザ情報保存部152を参照して確認する。
また、IDパスワード解析部143は、IDとパスワードとが正しい組み合わせであった場合は、ディレクトリ操作ラッパー141を介して、対応するユーザのユーザ情報をディレクトリ150から取得して、認証チケット管理部144に渡す。
認証チケット管理部144は、IDパスワード解析部143から渡されたユーザ情報を基に、サブプロバイダ14におけるユーザを認証する認証チケット600を作成する。
図27は、Unionマージプロバイダにおける認証チケット作成処理の一例のフローチャートである。
ステップS40では、Unionマージプロバイダ13のXML処理部131は、クライアント(例えば、Webポータル)よりUnionマージプロバイダ13におけるユーザを認証する認証チケット500の作成リクエストを受信する。
クライアント(例えば、Webポータル)からUnionマージプロバイダ13への認証チケット作成リクエストの一例は、後述する図29を用いて説明する。
ステップS40に続いてステップS41に進み、IDパスワード解析部138は、ステップS40においてクライアント(例えば、Webポータル)から受信した認証チケットの作成リクエストに含まれるIDとパスワードとをサブプロバイダ呼び出し部134に渡す。
ステップS41に続いてステップS42に進み、サブプロバイダ呼び出し部134は、サブプロバイダ登録部136に登録されているサブプロバイダ14の一覧を取得する。
ステップS42に続いてステップS43に進み、マージプロバイダXML処理部135は、サブプロバイダ呼び出し部134を介して取得したIDとパスワードとを含む、サブプロバイダ14におけるユーザを認証する認証チケット600の作成リクエストを作成し、サブプロバイダ14の一覧に登録されている各サブプロバイダ14に対して送信する。
Unionマージプロバイダ13からサブプロバイダ14への認証チケット作成リクエストの一例は、後述する図30を用いて説明する。
ステップS43に続いてステップS44に進み、サブプロバイダ呼び出し部134は、マージプロバイダXML処理部135を介して、各サブプロバイダ14から認証チケット600の作成リクエストに対する認証チケット作成レスポンスを受信する。
サブプロバイダ14からUnionマージプロバイダ13への認証チケット作成レスポンスの一例は、後述する図31を用いて説明する。
ステップS44に続いてステップS45に進み、サブプロバイダ呼び出し部134は、ステップS44において受信した各サブプロバイダ14からの認証チケット作成レスポンスの1つに、認証チケット600を識別する認証チケットID610が含まれているかどうかを判定する。
認証チケット作成レスポンスの1つに、認証チケット600を識別する認証チケットID610が含まれていると判定すると(ステップS45においてYES)、ステップS47に進み、認証チケット600を識別する認証チケットID610が含まれていないと判定すると(ステップS45においてNO)、ステップS46に進む。
ステップS46では、Unionマージプロバイダ13のXML処理部131は、認証チケット500の作成が失敗した旨のレスポンスを作成し、クライアント(例えば、Webポータル)に送信する。
ステップS47では、認証チケット管理部139が、サブプロバイダ14の認証チケットID610を用いて図26において説明したUnionマージプロバイダ13におけるユーザを認証する認証チケット500を作成する。
ステップS47に続いてステップS48に進み、Unionマージプロバイダ13のXML処理部131は、ステップS47において作成した認証チケット500の認証チケットID510を含む認証チケット作成レスポンスを作成し、クライアント(例えば、Webポータル)に送信する。
Unionマージプロバイダ13からクライアント(例えば、Webポータル)への認証チケット作成レスポンスの一例は、後述する図32を用いて説明する。
図28は、サブプロバイダにおける認証チケット作成処理の一例のフローチャートである。
サブプロバイダ14は、図27のステップS43においてUnionマージプロバイダ13が、サブプロバイダ14におけるユーザを認証する認証チケット600の作成リクエストを各サブプロバイダ14に送信すると、以下に示すステップS50からの処理を開始する。
ステップS50では、サブプロバイダ14のXML処理部131は、Unionマージプロバイダ13よりサブプロバイダ14におけるユーザを認証する認証チケット600の作成リクエストを受信する。
上述したように、Unionマージプロバイダ13からサブプロバイダ14への認証チケット作成リクエストの一例は、後述する図30を用いて説明する。
ステップS50に続いてステップS51に進み、IDパスワード解析部143は、ステップS50において受信した認証チケット600の作成リクエストに含まれるIDとパスワードとが正しい組み合わせかどうかを、ディレクトリ操作ラッパー141を介してディレクトリ150に確認し、判定する。
正しい組み合わせであると判定すると(ステップS51においてYES)、ステップS53に進み、正しい組み合わせではないと判定すると(ステップS51においてNO)、ステップS52に進む。
ステップS52では、サブプロバイダ14のXML処理部131は、認証チケット600の作成が失敗した旨の認証チケット作成レスポンスを作成し、Unionマージプロバイダ13に送信する。
ステップS53では、認証チケット管理部144は、ディレクトリ操作ラッパー141を介してディレクトリ150からIDに対応したユーザ情報を取得する。
ステップS53に続いてステップS54に進み、認証チケット管理部144は、サブプロバイダ14におけるユーザを認証する認証チケット600を作成する。
ステップS54に続いてステップS55に進み、サブプロバイダ14のXML処理部131は、ステップS54において作成した認証チケット600の認証チケットID610を含む認証チケット作成レスポンスを作成し、Unionマージプロバイダ13に送信する。
上述したように、サブプロバイダ14からUnionマージプロバイダ13への認証チケット作成レスポンスの一例は、後述する図31を用いて説明する。
なお、図27のステップS44は、図28のステップS52又はステップS55において送信した認証チケット作成レスポンスを受信する。
図29は、クライアントからUnionマージプロバイダへの認証チケット作成リクエストの一例のXMLメッセージである。
図29に示すように、クライアント(例えば、Webポータル)からUnionマージプロバイダ13への認証チケット500の作成リクエストには、<domainName></domainName>のタグにドメインネームが、<Name></Name>のタグにユーザの名前が、<passwd></passwd>のタグにパスワードが含まれている。
クライアント(例えば、Webポータル)は、ドメインネームとユーザ名とパスワードとを含む認証チケット500の作成リクエストをUnionマージプロバイダ13へ送信する。
図30は、Unionマージプロバイダからサブプロバイダへの認証チケット作成リクエストの一例のXMLメッセージである。
図30に示すように、Unionマージプロバイダ13は、クライアント(例えば、Webポータル)から送信された認証チケット500の作成リクエストに含まれるドメインネームとユーザ名とパスワードとをそのまま含むサブプロバイダ14におけるユーザを認証する認証チケット600の作成リクエストをサブプロバイダ14へ送信する。
図31は、サブプロバイダからUnionマージプロバイダへの認証チケット作成レスポンスの一例のXMLメッセージである。
図31に示すように、サブプロバイダ14からUnionマージプロバイダ13への認証チケット作成レスポンスには、<authTicket></authTicket>のタグに、サブプロバイダ14において作成した認証チケット600の認証チケットID610が含まれる。
サブプロバイダ14は、認証が成功すると、サブプロバイダ14におけるユーザを認証する認証チケット600を作成し、該認証チケット600の認証チケットID610を含む認証チケット作成レスポンスをUnionマージプロバイダ13に送信する。
図32は、Unionマージプロバイダからクライアントへの認証チケット作成レスポンスの一例のXMLメッセージである。
図32に示すように、Unionマージプロバイダ13からクライアント(例えば、Webポータル)への認証チケット作成レスポンスには、<authTicket></authTicket>のタグに、Unionマージプロバイダ13において作成した認証チケット500の認証チケットID510が含まれる。
Unionマージプロバイダ13は、サブプロバイダ14から図31において説明したように、サブプロバイダ14において作成した認証チケット600の認証チケットID610を取得すると、図26において説明したUnionマージプロバイダ13におけるユーザを認証する認証チケット500を作成し、該認証チケット500の認証チケットID510を含んだ認証チケット作成レスポンスをクライアント(例えば、Webポータル)に送信する。
以下、前記認証チケット作成レスポンスにおいて送信した認証チケットID510の確認リクエストが、クライアント(例えば、アプリケーション)から送信された場合のUnionマージプロバイダ13及びサブプロバイダ14の処理を以下において説明する。
図33は、Unionマージプロバイダにおける認証チケットID確認処理の一例のフローチャートである。
ステップS60では、Unionマージプロバイダ13のXML処理部131は、クライアント(例えば、アプリケーション)より認証チケットID510の確認リクエストを受信する。
クライアント(例えば、アプリケーション)からUnionマージプロバイダ13への認証チケットID確認リクエストの一例は、後述する図35を用いて説明する。
ステップS60に続いてステップS61に進み、認証チケット管理部139は、ステップS60において受信した認証チケットID510の確認リクエストに含まれる認証チケットID510を取得する。
ステップS61に続いてステップS62に進み、認証チケット管理部139は、ステップS61において取得した認証チケットID510が正しい認証チケットID510かどうかを判定する。
正しい認証チケットID510であると判定すると(ステップS62においてYES)、ステップS63に進み、正しい認証チケットID510でないと判定すると(ステップS62においてNO)、ステップS67に進む。
ステップS63では、認証チケット管理部139は、Unionマージプロバイダ13の認証チケット500に含まれるサブプロバイダ14の認証チケット600の認証チケットID610と、サブプロバイダ名とをサブプロバイダ呼び出し部134に渡す。
ステップS63に続いてステップS64に進み、マージプロバイダXML処理部135は、サブプロバイダ呼び出し部134を介して取得したサブプロバイダ14の認証チケット600の認証チケットID610を用いて、認証チケットID610を含むサブプロバイダ14に対する認証チケットID確認リクエストを作成し、サブプロバイダ14に対して送信する。
Unionマージプロバイダ13からサブプロバイダ14への認証チケットID確認リクエストの一例は、後述する図36を用いて説明する。
ステップS64に続いてステップS65に進み、サブプロバイダ呼び出し部134は、マージプロバイダXML処理部135を介して、前記認証チケットID確認リクエストを送信したサブプロバイダ14から、認証チケットID610の確認レスポンスを受信する。
サブプロバイダ14からUnionマージプロバイダ13への認証チケットID確認レスポンスの一例は、後述する図37を用いて説明する。
ステップS65に続いてステップS66に進み、サブプロバイダ呼び出し部134は、ステップS65において受信した認証チケットID610の確認レスポンスに、ユーザ情報が含まれているかどうかを判定する。
ユーザ情報が含まれていると判定すると(ステップS66においてYES)、ステップS68に進み、ユーザ情報が含まれていないと判定すると(ステップS66においてNO)、ステップS67に進む。
ステップS67では、Unionマージプロバイダ13のXML処理部131は、認証チケットID510の確認が失敗した旨のレスポンスを作成し、クライアント(例えば、アプリケーション)に送信する。
ステップS68では、サブプロバイダ呼び出し部134は、ステップS66において取得したユーザ情報に含まれるUIDと、セッション管理部137において管理されている各サブプロバイダ14のセッションチケット300のセッションチケットID310と、サブプロバイダ名とを取得して、マージプロバイダXML処理部135に提供する。
ステップS69では、マージプロバイダXML処理部135は、第一実施例において説明したように、ユーザを特定するUIDと各サブプロバイダ14のセッションチケット300のセッションチケットID310と含むユーザの所属するグループの取得リクエストを作成し、各サブプロバイダ14に送信する。
ステップS69に続いてステップS70に進み、サブプロバイダ呼び出し部134は、マージプロバイダXML処理部135を介して、各サブプロバイダ14から所属グループの取得リクエストに対する所属グループ取得レスポンスを受信する。
ステップS70に続いてステップS71に進み、マージ処理部133は、ステップS66において取得したユーザ情報と、ステップS70において取得した所属グループ取得レスポンスに含まれるユーザの所属するグループ情報をマージする。
ステップS71に続いてステップS72に進み、Unionマージプロバイダ13のXML処理部131は、ステップS71においてマージしたユーザ情報とユーザの所属するグループ情報とを含む認証チケットID確認レスポンスを作成し、クライアント(例えば、アプリケーション)に送信する。
Unionマージプロバイダ13からクライアントへの認証チケットID確認レスポンスの一例は、後述する図38を用いて説明する。
図34は、サブプロバイダにおける認証チケットID確認処理の一例のフローチャートである。
サブプロバイダ14は、図33のステップS64においてUnionマージプロバイダ13が、認証チケットID610の確認リクエストをサブプロバイダ14に送信すると、以下に示すステップS80からの処理を開始する。
ステップS80では、サブプロバイダ14のXML処理部131は、Unionマージプロバイダ13より認証チケットID610の確認リクエストを受信する。
上述したように、Unionマージプロバイダ13からサブプロバイダ14への認証チケットID確認リクエストの一例は、後述する図36を用いて説明する。
ステップS80に続いてステップS81に進み、サブプロバイダ14のUID変換部132は、ステップS80において受信した認証チケットID610の確認リクエストに含まれるUIDをディレクトリ150固有のUIDに変換する。
ステップS81に続いてステップS82に進み、認証チケット管理部144は、ステップS80において受信した認証チケットID610の確認リクエストに含まれる認証チケットID610が有効な認証チケット600の認証チケットID610であるかどうかを判定する。
有効な認証チケット600の認証チケットID610であると判定すると(ステップS82においてYES)、ステップS84に進み、無効な認証チケット600の認証チケットID610であると判定すると(ステップS82においてNO)、ステップS83に進む。
ステップS83では、サブプロバイダ14のXML処理部131は、認証チケットID610の確認が失敗した旨の認証チケットID確認レスポンスを作成し、Unionマージプロバイダ13に送信する。
ステップS84では、サブプロバイダ14は、ディレクトリ操作ラッパー141を介してディレクトリ150からユーザ情報を取得する。
ステップS84に続いてステップS85に進み、サブプロバイダ14のUID変換部132は、ディレクトリ150固有のUIDをUnionマージプロバイダ13が利用可能なUIDに変換する。
ステップS85に続いてステップS86に進み、サブプロバイダ14のXML処理部131は、ステップS84において取得したユーザ情報を含む認証チケットID確認レスポンスを作成し、Unionマージプロバイダ13に送信する。
上述したように、サブプロバイダ14からUnionマージプロバイダ13への認証チケットID確認レスポンスの一例は、後述する図37を用いて説明する。
なお、図33のステップS65は、図34のステップS83又はステップS86において送信した認証チケットID確認レスポンスを受信する。
図35は、クライアントからUnionマージプロバイダへの認証チケットID確認リクエストの一例のXMLメッセージである。
図35に示すように、クライアント(例えば、アプリケーション)からUnionマージプロバイダ13への認証チケットID確認リクエストには、<authTicket></authTicket>のタグに、Unionマージプロバイダ13におけるユーザを認証する認証チケット500の認証チケットID510が含まれている。
クライアント(例えば、アプリケーション)は、Unionマージプロバイダ13におけるユーザを認証する認証チケット500の認証チケットID510を含む認証チケットID510の確認リクエストをUnionマージプロバイダ13へ送信する。
図36は、Unionマージプロバイダからサブプロバイダへの認証チケットID確認リクエストの一例のXMLメッセージである。
図36に示すように、Unionマージプロバイダ13からサブプロバイダ14への認証チケットID確認リクエストには、<authTicket></authTicket>のタグに、サブプロバイダ14におけるユーザを認証する認証チケット600の認証チケットID610が含まれている。
Unionマージプロバイダ13は、図26において説明したように、認証に成功したサブプロバイダ14の認証チケット600を当該Unionマージプロバイダ13の認証チケット500に含めて管理しているため、クライアント(例えば、アプリケーション)から送信された認証チケット確認リクエストに含まれるUnionマージプロバイダ13の認証チケット500の認証チケットID510を基に、認証に成功したサブプロバイダ14の認証チケット600の認証チケットID610を取得し、該認証チケットID610をXMLメッセージに含めることができる。
図37は、サブプロバイダからUnionマージプロバイダへの認証チケットID確認レスポンスの一例のXMLメッセージである。
図37に示すように、サブプロバイダ14からUnionマージプロバイダ13への認証チケットID610の確認レスポンスには、<name></name>のタグにユーザの名前が含まれ、<id></id>のタグにユーザのUIDが含まれ、<groupList></groupList>のタグに含まれる各<item></item>のタグに、ユーザの該サブプロバイダ14における所属するグループ情報が含まれている。
サブプロバイダ14は、ユーザ情報と、該ユーザが所属するグループが存在する場合は、該ユーザが所属するグループ情報とをディレクトリ150から取得し、Unionマージプロバイダ13に送信する。
図38は、Unionマージプロバイダからクライアントへの認証チケットID確認レスポンスの一例のXMLメッセージである。
図38に示されるように、Unionマージプロバイダ13は、<name></name>のタグにユーザの名前を、<id></id>のタグにユーザのUIDを、1つの<groupList></groupList>のタグに含まれる1つ以上の<item></item>のタグに各サブプロバイダ14から取得したグループ情報を格納し、クライアントへ送信する。
Unionマージプロバイダ13は、図37において説明したように、1つのサブプロバイダ14からUIDを取得することができるので、第一の実施例において説明したように、前記UIDと、登録しているサブプロバイダ14のセッションチケット300のセッションID310とを用いて、各サブプロバイダ14からユーザの所属するグループ情報を取得することができる。
第二の実施例において説明したように、サブプロバイダ14が認証を必要とした場合でも、ユーザはUnionマージプロバイダ13に対してユーザ名とパスワードとを一度送信して認証を行うだけで、全てのサブプロバイダ14からユーザの所属するグループ情報を取得することができる。
なお、第二の実施例の説明においては、Unionマージプロバイダ13とサブプロバイダ14との間、及びUnionマージプロバイダ13とクライアントとの間は、認証チケットID510及び/又は認証チケットID610を送受信する場合を例にとって説明したが、これは本実施を制限するものではなく、認証チケット500及び/又は認証チケット600を送受信してもよい。これは以下においても、同様である。
また、第一の実施例、第二の実施例共にディレクトリ150は、サブプロバイダ14とは独立させて説明を行ったが、各サブプロバイダ14は、ディレクトリ150をその内部に含む構成としてもよい。
以下では説明の簡略化のため、ディレクトリ150は、各サブプロバイダ14内に含まれているとして説明を行う。
以下に、Unionマージプロバイダ13を導入した場合の一例を、図39を用いて説明する。
図39は、Unionマージプロバイダを利用してユーザの認証を行い、リポジトリサービスが蓄積している蓄積文書を取得する一例を説明するための図である。
ステップS100では、Webブラウザ1が、ユーザによって入力されたログイン名とパスワードとをWebポータル2に送信する。
ステップS100に続いてステップS101に進み、Webポータル2は、ステップS1において受信したログイン名とパスワードとを含むUnionマージプロバイダ13における認証チケット500の作成リクエストをUnionマージプロバイダ13に送信する。
ステップS101に続いてステップS102に進み、Unionマージプロバイダ13は、サブプロバイダ14であるWinNT認証ディレクトリプロバイダ7とNotes(登録商標)R5認証ディレクトリプロバイダ12とLocal認証ディレクトリプロバイダ8とに前記ログイン名とパスワードとを含むサブプロバイダ14における認証チケット600の作成のリクエストを送信する。
サブプロバイダ14であるWinNT認証ディレクトリプロバイダ7とNotes(登録商標)R5認証ディレクトリプロバイダ12とLocal認証ディレクトリプロバイダ8とは、前記ログイン名とパスワードとを用いて認証を行い、認証が成功した場合は、認証チケット600の作成を行う。
ステップS102に続いてステップS103に進み、サブプロバイダ14であるWinNT認証ディレクトリプロバイダ7とNotes(登録商標)R5認証ディレクトリプロバイダ12とLocal認証ディレクトリプロバイダ8とは、認証チケット作成リクエストに対する認証チケット作成レスポンスを作成し、Unionマージプロバイダ13に送信する。
例えば、ユーザがWinNTのログイン名とパスワードとをWebブラウザ1に入力した場合は、WinNT認証ディレクトリプロバイダ7で認証が成功し、認証チケット600が作成される。
この場合、WinNT認証ディレクトリプロバイダ7からUnionマージプロバイダ13に送信された認証チケット作成レスポンスには、作成された認証チケット600の認証チケットID610が含まれ、他のサブプロバイダ14からUnionマージプロバイダ13に送信された認証チケット作成レスポンスには、認証チケット600の作成が失敗した旨の情報が含まれる。
ステップS103に続いてステップS104に進み、Unionマージプロバイダ13は、サブプロバイダ14の1つから認証チケットID610が含まれた認証チケット作成レスポンスを取得すると、Unionマージプロバイダ13におけるユーザを認証する認証チケット500を作成し、該作成した認証チケット500の認証チケットID510を含んだ認証チケット作成レスポンスをWebポータル2に送信する。
ステップS104に続いてステップS105に進み、Webポータル2は、認証が成功した旨をWebブラウザ1に送信する。
ステップS105に続いてステップS106に進み、Webブラウザ1は、リポジトリサービス170が提供するサービスを利用する旨の利用開始リクエストをWebポータル2に送信する。
ステップS106に続いてステップS107に進み、Webポータル2は、ステップS104において取得したUnionマージプロバイダ13におけるユーザを認証する認証チケット500の認証チケットID510を含むサービスの利用を許可するセッションチケット700の作成リクエストを、リポジトリサービス170に送信する。
ステップS107に続いてステップS108に進み、リポジトリサービス170は、ステップS107において受信したセッションチケット700の作成リクエストが、有効なユーザからのリクエストかどうかを確認するために、前記セッションチケット700の作成リクエストに含まれる認証チケットID510を含む認証チケットID確認リクエストをUnionマージプロバイダ13に送信する。
ステップS108に続いてステップS109に進み、Unionマージプロバイダ13は、ステップS103においてサブプロバイダ14の内の1つから取得した認証チケットID610の確認リクエストをサブプロバイダ14に送信する。
なお、Unionマージプロバイダ13は、ステップS103において、どのサブプロバイダ14において認証が成功したかの情報を保持しているため、該認証が成功したサブプロバイダ14に対してのみ、認証チケットID610の確認リクエストを送信するようにしてもよい。
ステップS109に続いてステップS110に進み、サブプロバイダ14であるWinNT認証ディレクトリプロバイダ7とNotes(登録商標)R5認証ディレクトリプロバイダ12とLocal認証ディレクトリプロバイダ8とは、認証チケットID610の確認リクエストに対する認証チケットID610の確認レスポンスをUnionマージプロバイダ13に送信する。
例えば、前記認証が成功したサブプロバイダ14がWinNT認証ディレクトリプロバイダ7であった場合は、WinNT認証ディレクトリプロバイダ7は、認証チケットID610に対応するユーザのUIDを含む認証チケットID610の確認レスポンスをUnionマージプロバイダ13に送信する。
ステップS110に続いてステップS111に進み、Unionマージプロバイダ13は、ステップS110において取得したUIDと、各サブプロバイダ14のセッションチケット300のセッションチケットID310とを含んだ、UIDに対応するユーザの所属するグループ情報の取得リクエストを各サブプロバイダ14に送信する。
ステップS111に続いてステップS112に進み、各サブプロバイダ14は、取得したUIDに対応するユーザの所属するグループ情報を含む取得レスポンスを作成し、Unionマージプロバイダ13に送信する。
ステップS112に続いてステップS113に進み、Unionマージプロバイダ13は、ステップS110において取得したユーザ情報及びステップS112において取得したユーザの所属するグループ情報をマージして、該マージした情報を含む認証チケットID確認レスポンスを作成し、リポジトリサービス170に送信する。
ステップS113に続いてステップS114に進み、例えば、リポジトリサービス170は、ステップS113において取得したグループの中に当該リポジトリサービス170が提供するサービスの利用を許可しているグループが存在した場合は、サービスの利用を許可するセッションチケット700を作成し、該セッションチケット700のセッションチケットID710を含むセッションチケットの作成レスポンスをWebポータル2に送信する。
ステップS114に続いてステップS115に進み、Webポータル2は、Webブラウザ1に対してサービスの利用開始が許可された旨のレスポンスを送信する。
ステップS115に続いてステップS116に進み、Webブラウザ1は、リポジトリサービス170が蓄積している蓄積文書を取得する旨のリクエストをWebポータル2に送信する。
ステップS116に続いてステップS117に進み、Webポータル2は、ステップS114において取得したセッションチケット700のセッションチケットID710を含む蓄積文書の取得リクエストをリポジトリサービス170に送信する。
ステップS117に続いてステップS118に進み、リポジトリサービス170は、ステップS117において取得した蓄積文書の取得リクエストに含まれるセッションチケットID710が有効なセッションチケット700のセッションチケットID710かどうかを判定し、有効なセッションチケットID710であると判定した場合には、指定された蓄積文書を含む蓄積文書の取得レスポンスをWebポータル2に送信する。
ステップS118に続いてステップS119に進み、Webポータル2は、ステップS118において取得した蓄積文書をWebブラウザ1に送信する。
上述したように、Unionマージプロバイダ13を導入することによって、例えばリポジトリサービス170に蓄積されている文書を取得する権限がLocal認証ディレクトリプロバイダ8に登録されているグループにしか与えられていない場合であっても、Unionマージプロバイダ13は、ユーザの所属する他のサブプロバイダ14のグループの情報もマージして管理するため、WinNT認証ディレクトリプロバイダ7で認証したユーザであっても、同一のユーザがLocal認証ディレクトリプロバイダ8の前記グループに属していた場合は、リポジトリサービス170に蓄積されている文書を取得することができる。
図40は、Unionマージプロバイダが複数存在する場合の統合の一例を説明するための図である。
図17を用いて説明したように、Unionマージプロバイダ13は、セッションチケット200を階層的な構造で有しているため、図40に示すように、Unionマージプロバイダ13を有する既存のシステムが複数存在している場合も、これらのシステムを統合するUnionマージプロバイダ13(図40のUnionマージプロバイダ0)を導入し、新たなグループに統合することができる。
以下、Unionマージプロバイダ13と、サブプロバイダ14と、の構成に係る情報(構成情報)を、Unionマージプロバイダ13の外に出して、後述するコンフィグレーションマネージャ22で保持、管理するようにした例を、以下の実施例において説明する。
図41は、UCSの構成を説明するための図(その4)である。なお、図41では、説明の簡略化のため、図13において説明したように、UCS49内に、Unionマージプロバイダ13も、サブプロバイダ14の全ても含まれているものとして説明を行う。但し、上述したように、例えばサブプロバイダ14の一部又は全ては、他の融合機120に含まれていてもよい。
図41に示されるUCS49は、ディスパッチャー21と、コンフィグレーションマネージャ22と、Unionマージプロバイダ13と、サブプロバイダ141から14nと、を含む。
ディスパッチャー21は、クライアントからの要求を受け取って、コンフィグレーションマネージャ22やUnionマージプロバイダ13等に要求を振り分けたり、振り分けた要求に応じてコンフィグレーションマネージャ22又はUnionマージプロバイダ13等が処理した処理結果をクライアントに送信したりする。
コンフィグレーションマネージャ22は、Unionマージプロバイダ13と、サブプロバイダ141〜14nと、の構成を管理する管理部であり、構成情報等を格納部に保持する。
なお、Unionマージプロバイダ13及びサブプロバイダ14は上述した実施例1又は実施例2において説明したのと同様である。
以下、プロバイダ一覧取得シーケンスの一例を、図42を用いて説明する。図42は、プロバイダ一覧取得シーケンスの一例を説明するための図である。
図42に示されるように、クライアントは、例えばUnionマージプロバイダ13のサブプロバイダ14として新たなプロバイダを追加する場合、該新たに追加するプロバイダを選択するため、ディスパッチャー21に対して、ディスパッチャー21のgetProviderListメソッドを含むプロバイダ一覧取得リクエストを送信する(シーケンスSQ1)。なお、プロバイダ一覧取得リクエストの一例は、後述する図43を用いて示す。
プロバイダ一覧取得リクエストを受信したディスパッチャー21は、コンフィグレーションマネージャ22のenumerateProviderNameメソッドを呼び出す(シーケンスSQ2)。
enumerateProviderNameメソッドを呼び出されたコンフィグレーションマネージャ22は、格納部よりプロバイダ名等を取得し、プロバイダ一覧としてディスパッチャー21に返す。
ディスパッチャー21は、プロバイダ一覧を含むプロバイダ一覧取得レスポンスを作成し、要求元のクライアントに送信する。なお、プロバイダ一覧取得レスポンスの一例は、後述する図44を用いて示す。
図42に示すような処理を行うことによって、例えばクライアントはプロバイダの一覧を表示し、ユーザはプロバイダの一覧の中からUnionマージプロバイダ13のサブプロバイダ14として新たに追加するプロバイダを選択することができる。
以下、プロバイダ一覧取得リクエストの一例を、図43を用いて示す。図43は、クライアントからディスパッチャーへのプロバイダ一覧取得リクエストの一例のXMLメッセージである。
図43に示されるように、プロバイダ一覧取得リクエストには、getProviderListメソッドが含まれている。
以下、プロバイダ一覧取得レスポンスの一例を、後述する図44を用いて示す。図44は、ディスパッチャーからクライアントへのプロバイダ一覧取得レスポンスの一例のXMLメッセージである。
図44に示されるように、<item></item>のタグには、プロバイダの名前(又はプロバイダを識別する識別子)が格納されている。
以下、サブプロバイダ追加シーケンスの一例を、図45を用いて説明する。図45は、サブプロバイダ追加シーケンスの一例を説明するための図である。
図45に示されるように、クライアントは、例えば後述するGUI(Graphical User Interface)等を用いて、ユーザが、プロバイダ一覧から追加するプロバイダを選択すると、ディスパッチャー21に対して、ディスパッチャー21のcreateProviderメソッドを含むサブプロバイダ追加リクエストを送信する(シーケンスSQ10)。なお、サブプロバイダ追加リクエストの一例は、後述する図46を用いて示す。図45では、省略してあるが、サブプロバイダ追加リクエストには、例えば、どのUnionマージプロバイダ13に、どのサブプロバイダ14を追加するか等の情報が含まれる。
サブプロバイダ追加リクエストを受信したディスパッチャー21は、コンフィグレーションマネージャ22のcreateProviderConfigurationメソッドを呼び出す(シーケンスSQ11)。
createProviderConfigurationメソッドを呼び出されたコンフィグレーションマネージャ22は、構成情報を格納するための新たな領域を格納部において確保し、該領域に係る格納領域情報(例えば、新たに確保した領域の先頭アドレス等)をディスパッチャー21に返す。
格納領域情報を取得したディスパッチャー21は、該格納領域情報を引数として、追加するサブプロバイダ14のcreateProviderメソッドを呼び出す(シーケンスSQ12)。
createProviderメソッドを呼び出されたサブプロバイダ14は、createProviderメソッドの引数として渡された格納領域情報と、例えば当該サブプロバイダ14の識別子及びサブプロバイダ14の名前等のデフォルトの構成情報と、を引数として、コンフィグレーションマネージャ22のsetAttributeメソッドを呼び出す(シーケンスSQ13)。
setAttributeメソッドを呼び出されたコンフィグレーションマネージャ22は、setAttributeメソッドの引数として渡されたサブプロバイダ14のデフォルトの構成情報を含む構成情報を、setAttributeメソッドの引数として渡された格納領域情報に基づいて、対応する格納領域に、格納する。
コンフィグレーションマネージャ22より構成情報を格納した旨の情報を受け取ったディスパッチャー21は、プロバイダの追加が正常に終了した旨の情報を含むサブプロバイダ追加レスポンスを作成し、要求元のクライアントに送信する。なお、サブプロバイダ追加レスポンスの一例は、後述する図47を用いて示す。
図45に示されるような処理を行うことによって、プロバイダをUnionマージプロバイダ13のサブプロバイダ14として新たに追加することができる。
以下、サブプロバイダ追加リクエストの一例を、図46を用いて説明する。図46は、クライアントからディスパッチャーへのサブプロバイダ追加リクエストの一例のXMLメッセージである。
図46に示されるように、サブプロバイダ追加リクエストには、createProviderメソッドが含まれている。また、createProviderメソッドの引数として、<unionMergeproviderName></unionMergeproviderName>のタグには、Unionマージプロバイダの識別子又は名前が含まれている。また、<item></item>のタグの、<subproviderName></subproviderName>には、新たに追加するサブプロバイダの識別子又は名前が含まれている。
以下、サブプロバイダ追加レスポンスの一例を、図47を用いて説明する。図47は、ディスパッチャーからクライアントへのサブプロバイダ追加レスポンスの一例のXMLメッセージである。
図47に示されるように、サブプロバイダ追加レスポンスの<returnValue></returnValue>のタグには、サブプロバイダの追加が成功したかどうかを表す情報(図47の例においてはOK)が含まれている。
以下、クライアントの一例のハードウェア構成を、図48を用いて説明する。図48は、クライアントの一例のハードウェア構成図である。
図48に示されるクライアントのハードウェア構成は、それぞれバスで相互に接続されている入力装置51と、表示装置52と、ドライブ装置53と、記録媒体54と、ROM55と、RAM56と、CPU57と、インターフェース装置58と、HDD59と、から構成されている。
入力装置51は、クライアントの利用者が操作するキーボード及びマウス等で構成され、クライアントに各種操作信号を入力するのに用いられる。表示装置52は、クライアントの利用者が利用するディスプレイ等で構成され、各種情報を表示する。インターフェース装置58は、クライアントをネットワーク5等に接続するインターフェースである。
クライアントにおける各処理を実行するアプリケーションプログラム等は、例えば、CD−ROM等の記録媒体54によってクライアントに提供されるか、ネットワーク5を通じてダウンロードされる。記録媒体54は、ドライブ装置53にセットされ、アプリケーションプログラムが記録媒体54からドライブ装置53を介してHDD59にインストールされる。
ROM55は、データ等を格納する。RAM56は、クライアントの起動時にHDD59からアプリケーションプログラム等を読み出して格納する。CPU57は、RAM56に読み出され格納されたアプリケーションプログラム等に従って処理を実行する。また、HDD59は、データやファイル等を格納する。
なお、上述した実施例においては、Unionマージプロバイダ13及び/又はサブプロバイダ14が実装される装置の例として融合機120を用いて説明を行ったが、図48に示したようなPC(パーソナルコンピュータ)に実装するようにしてもよい。
以下、クライアントの機能の一例を、図49を用いて説明する。図49は、クライアントの機能ブロック図である。
図49に示されるように、クライアントは、GUI表示部71と、制御部72と、サーバ呼び出し部73と、XML生成解析部74と、を含む。
GUI表示部71は、後述するGUIを作成し、クライアントのディスプレイ等に表示する表示部である。制御部72は、クライアント全体の処理を制御する制御部である。サーバ呼び出し部73は、Unionマージプロバイダ13等を含むサーバを呼び出す呼び出し部である。XML生成解析部74は、XMLを生成し、サーバに送信すると共に、サーバ等から受信したXMLメッセージを解析し、該XMLメッセージに含まれるデータ等を取得する。
以下、クライアントにおけるプロバイダの設定に係るGUIの一例を、図50に示す。図50は、クライアントにおけるプロバイダの設定に係るGUIを示す図(その1)である。
クライアントは、例えば図44に示されるようなプロバイダ一覧取得レスポンスを受信すると、該プロバイダ一覧取得レスポンスに含まれるプロバイダの一覧に基づいて、図50(A)に示されるように、プロバイダの一覧をドロップダウンメニューの中に含むユーザ認証プロバイダ設定画面を作成し、表示する。
なお、図50(A)に示されるユーザ認証プロバイダ設定画面のドロップダウンメニューの下に表示されているグループボックス内は、ユーザが、ドロップダウンメニューの中から選択したプロバイダによって変化する。
例えば、ユーザが、図50(A)において「認証サービス参照」を選択して「参照」ボタンをクリックすると、クライアントは、図50(B)に示されるような外部認証の参照画面を表示する。なお、外部認証とは、実際の認証を行う認証エンジン(図25の例では、例えばIDパスワード解析部143及び認証チケット管理部144等)を外部のサーバ等で行わせる認証である。
ユーザが図50(B)において「参照」ボタンをクリックすると、クライアントは、図50(C)に示されるようなユーザ認証サービス管理参照画面を表示する。
以下、クライアントにおけるプロバイダの設定に係るGUIの他の例を、図51に示す。図51は、クライアントにおけるプロバイダの設定に係るGUIを示す図(その2)である。
図51には、ユーザが、ドロップダウンメニューの中からWindows(登録商標)NT認証を選んだ場合の、一例の画面が示されている。なお、図51の「ドメインコントローラの設定」ボタンは、ユーザが「自認証設定」を選択した場合のみ有効となる。
以下、クライアントにおけるプロバイダの設定に係るGUIの他の例を、図52に示す。図52は、クライアントにおけるプロバイダの設定に係るGUIを示す図(その3)である。
図52には、ユーザが、ドロップダウンメニューの中からActiveDirectory(登録商標)認証を選んだ場合の、一例の画面が示されている。なお、図52の「ドメインコントローラの設定」ボタンは、ユーザが「自認証設定」を選択した場合のみ有効となる。
以下、クライアントにおけるプロバイダの設定に係るGUIの他の例を、図53に示す。図53は、クライアントにおけるプロバイダの設定に係るGUIを示す図(その4)である。
図53には、ユーザが、ドロップダウンメニューの中からNotes(登録商標)認証を選んだ場合の、一例の画面が表示されている。
以下、リモートプロバイダの一例を、図54を用いて説明する。図54は、リモートプロバイダの一例を説明するための図である。
Unionマージプロバイダ13及び/又はサブプロバイダ14は、例えば定義ファイル等にis_exported属性が真に設定されていると、後述するようなリモートプロバイダとして処理を行うようにしてもよい。ここで、リモートプロバイダとは、例えば、プロバイダが、認証プロバイダであった場合、上述したように、認証エンジンを自身では持たず、他のプロバイダ等に含まれる認証エンジンを利用して、クライアント等からの要求に応じて処理を行うプロバイダのことである。なお、定義ファイルは、例えばコンフィグレーションマネージャ22等に含まれる。
例えば、サブプロバイダ141は、クライアント又はUnionマージプロバイダ13等よりサービス(例えば、認証サービス等)の利用要求を受け取ると(シーケンスSQ20)、例えば定義ファイル等を参照し、is_exported属性が真かどうかを判定する。
サブプロバイダ141は、is_exported属性が真であると判定すると、当該自身はリモートプロバイダであるとして、レジストリ等に格納されている接続先情報を取得し、該接続先に対してサービスの利用要求を転送する(シーケンスSQ21)。
サービスの利用要求を受け取ったサブプロバイダ14nは、例えば定義ファイル等を参照し、is_shared属性が真かどうかを判定する。
サブプロバイダ14nは、is_shared属性が真であると判定すると、サービスの利用要求に応じて、処理を行って実行結果をリモートプロバイダ(サブプロバイダ141)に返す。
リモートプロバイダ(サブプロバイダ141)は、サブプロバイダ14nより実行結果を受け取ると、該実行結果に必要な後処理を加え、該後処理を加えた実行結果を要求元のクライアント又はUnionマージプロバイダ13等に返す。
以下、リモートプロバイダに係る処理の一例を、図55を用いて説明する。図55は、リモートプロバイダに係る処理の一例を説明するための図である。
ステップS200において、例えばサブプロバイダ141は、クライアント又はUnionマージプロバイダ13等よりサービスの利用要求を受け取る。
ステップS200に続いてステップS201に進み、サブプロバイダ141は、定義ファイル等を参照し、is_exported属性が真かどうかを判定する。サブプロバイダ141は、is_exported属性が真であると判定すると、ステップS202に進み、is_exported属性が偽であると判定すると、例えばis_shared属性が真であるかどうか判定する。なお、説明の簡略化のため、is_exported属性が偽であると判定した場合の処理は図55では省略してある。
ステップS202では、サブプロバイダ141は、リモートプロバイダであるとして、レジストリ等に格納されている接続先情報を取得する。
ステップS202に続いてステップS203に進み、サブプロバイダ141は、ステップS200において受け取ったサービスの利用要求をステップS202において取得した接続先に転送する。
ステップS203に続いてステップS204に進み、接続先のサブプロバイダ14nは、リモートプロバイダより、サービスの利用要求の転送を受け取る。
ステップS204に続いてステップS205に進み、接続先のサブプロバイダ14nは、定義ファイル等を参照し、is_shared属性が真かどうかを判定する。接続先のサブプロバイダ14nは、is_shared属性が真であると判定すると、ステップS206に進み、is_shared属性が偽であると判定すると、NGをリモートプロバイダに返す。
ステップS206では、接続先のサブプロバイダ14nが、コンフィグレーションマネージャ22より、要求元のリモートプロバイダの信頼関係を読み出す。
ステップS206に続いてステップS207に進み、接続先のサブプロバイダ14nは、当該サブプロバイダ14nと、要求元のリモートプロバイダと、に信頼関係が有るかどうかを判定する。接続先のサブプロバイダ14nは、当該サブプロバイダ14nと、要求元のリモートプロバイダと、に信頼関係が有ると判定すると、ステップS208に進み、当該サブプロバイダ14nと、要求元のリモートプロバイダと、に信頼関係は無いと判定すると、NGをリモートプロバイダに返す。
ステップS208では、接続先のサブプロバイダ14nが、要求に応じて処理を実行する。
ステップS208に続いてステップS209に進み、接続先のサブプロバイダ14nは、実行結果を要求元のリモートプロバイダに返す。
ステップS209に続いてステップS210に進み、リモートプロバイダは、接続先のサブプロバイダ14nより実行結果を受け取る。
ステップS210に続いてステップS211に進み、リモートプロバイダは、ステップS210において受け取った実行結果に、必要な後処理を加える。
ステップS211に続いてステップS212に進み、リモートプロバイダは、ステップS211において必要な後処理を加えた実行結果を、要求元のクライアント又はUnionマージプロバイダ13に返す。
なお、実施例3においては、サブプロバイダ14の追加を例にとって説明を行ったが、サブプロバイダ14が1つも登録されていない場合の、サブプロバイダ14の登録等も同様である。
以上、本発明の好ましい実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
認証プロバイダを利用してユーザの認証を行い、アプリケーションが提供するサービスを利用する一例を説明するための図である。
1つのWebポータルが、複数のアプリケーションと複数の認証ディレクトリプロバイダとをサポートする一例を説明するための図である。
Webポータルにおけるアクセスモジュールを1つに統合した一例を説明するための図である。
図3の構成に新たなアプリケーションを追加した一例を説明するための図である。
Local認証ディレクトリプロバイダを導入した一例を説明するための図である。
図5に示したLocal認証ディレクトリプロバイダ12に登録されているグループのメンバーの一例を説明するための図である。
従来のプロバイダの問題点を説明するための図である。
本発明によるUnionマージプロバイダを導入した一例を説明するための図である。
図8に示したLocal認証ディレクトリプロバイダのグループのメンバーの一例を説明するための図である。
図8に示したLocal認証ディレクトリプロバイダのユーザIDの構造を説明するための図である。
本発明による融合機の一実施例の構成図である。
本発明による融合機の一実施例のハードウェア構成図である。
UCSの構成を説明するための図(その1)である。
UCSの構成を説明するための図(その2)である。
UCSの構成を説明するための図(その3)である。
本発明の第一実施例におけるUnionマージプロバイダとサブプロバイダとの機能ブロック図である。
Unionマージプロバイダのセッションチケットの構造を説明するための概念図である。
ディレクトリ操作ラッパーのデータの変形の一例を説明するための図である。
Unionマージプロバイダにおけるユーザの所属グループ取得処理の一例のフローチャートである。
サブプロバイダにおけるユーザの所属グループ取得処理の一例のフローチャートである。
クライアントからUnionマージプロバイダへのグループ取得リクエストの一例のXMLメッセージである。
Unionマージプロバイダからサブプロバイダへのグループ取得リクエストの一例のXMLメッセージである。
サブプロバイダからUnionマージプロバイダへのグループ取得レスポンスの一例のXMLメッセージである。
Unionマージプロバイダからクライアントへのグループ取得レスポンスの一例のXMLメッセージである。
本発明の第二実施例におけるUnionマージプロバイダとサブプロバイダとの機能ブロック図である。
Unionマージプロバイダの認証チケットの構造を説明するための概念図である。
Unionマージプロバイダにおける認証チケット作成処理の一例のフローチャートである。
サブプロバイダにおける認証チケット作成処理の一例のフローチャートである。
クライアントからUnionマージプロバイダへの認証チケット作成リクエストの一例のXMLメッセージである。
Unionマージプロバイダからサブプロバイダへの認証チケット作成リクエストの一例のXMLメッセージである。
サブプロバイダからUnionマージプロバイダへの認証チケット作成レスポンスの一例のXMLメッセージである。
Unionマージプロバイダからクライアントへの認証チケット作成レスポンスの一例のXMLメッセージである。
Unionマージプロバイダにおける認証チケットID確認処理の一例のフローチャートである。
サブプロバイダにおける認証チケットID確認処理の一例のフローチャートである。
クライアントからUnionマージプロバイダへの認証チケットID確認リクエストの一例のXMLメッセージである。
Unionマージプロバイダからサブプロバイダへの認証チケットID確認リクエストの一例のXMLメッセージである。
サブプロバイダからUnionマージプロバイダへの認証チケットID確認レスポンスの一例のXMLメッセージである。
Unionマージプロバイダからクライアントへの認証チケットID確認レスポンスの一例のXMLメッセージである。
Unionマージプロバイダを利用してユーザの認証を行い、リポジトリサービスが蓄積している蓄積文書を取得する一例を説明するための図である。
Unionマージプロバイダが複数存在する場合の統合の一例を説明するための図である。
UCSの構成を説明するための図(その4)である。
プロバイダ一覧取得シーケンスの一例を説明するための図である。
クライアントからディスパッチャーへのプロバイダ一覧取得リクエストの一例のXMLメッセージである。
ディスパッチャーからクライアントへのプロバイダ一覧取得レスポンスの一例のXMLメッセージである。
サブプロバイダ追加シーケンスの一例を説明するための図である。
クライアントからディスパッチャーへのサブプロバイダ追加リクエストの一例のXMLメッセージである。
ディスパッチャーからクライアントへのサブプロバイダ追加レスポンスの一例のXMLメッセージである。
クライアントの一例のハードウェア構成図である。
クライアントの機能ブロック図である。
クライアントにおけるプロバイダの設定に係るGUIを示す図(その1)である。
クライアントにおけるプロバイダの設定に係るGUIを示す図(その2)である。
クライアントにおけるプロバイダの設定に係るGUIを示す図(その3)である。
クライアントにおけるプロバイダの設定に係るGUIを示す図(その4)である。
リモートプロバイダの一例を説明するための図である。
リモートプロバイダに係る処理の一例を説明するための図である。
符号の説明
1 Webブラウザ
2 Webポータル
3 アプリケーション
4 認証ディレクトリプロバイダ
5 Windows(登録商標)アプリケーション
6 Notes(登録商標)アプリケーション
7 Windows(登録商標)認証ディレクトリプロバイダ
8 Notes(登録商標)認証ディレクトリプロバイダ
9 プロバイダ
10 アクセスモジュール
11 アプリケーション
12 Local認証ディレクトリプロバイダ
13 Unionマージプロバイダ
14 サブプロバイダ
15 白黒ラインプリンタ
16 カラーラインプリンタ
17 ハードウェアリソース
20 ソフトウェア群
30 アプリケーション
31 プリンタアプリ
32 コピーアプリ
33 ファックスアプリ
34 スキャナアプリ
35 ネットファイルアプリ
36 工程検査アプリ
40 プラットフォーム
41 オペレーティングシステム(OS)
42 システムコントロールサービス(SCS)
43 システムリソースマネージャ(SRM)
44 エンジンコントロールサービス(ECS)
45 メモリコントロールサービス(MCS)
46 オペレーションパネルコントロールサービス(OCS)
47 ファックスコントロールサービス(FCS)
48 ネットワークコントロールサービス(NCS)
49 ユーザ情報管理サービス(UCS)
50 融合機起動部
51 入力装置
52 表示装置
53 ドライブ装置
54 記録媒体
55 ROM
56 RAM
57 CPU
58 インターフェース装置
59 HDD
60 コントローラボード
61 CPU
62 ASIC(Application Specific Integrated Circuit)
63 SRAM(Static RAM)
64 SDRAM(Synchronous DRAM)
65 フラッシュメモリ
66 ハードディスク装置(HDD)
70 オペレーションパネル
71 GUI表示部
72 制御部
73 サーバ呼び出し部
74 XML生成解析部
80 ファックスコントロールユニット(FCU)
90 USBデバイス
100 IEEE1394デバイス
110 エンジン部
120 融合機
130 プロバイダI/F
131 XML処理部
132 UID変換部
133 マージ処理部
134 サブプロバイダ呼び出し部
135 マージプロバイダXML処理部
136 サブプロバイダ登録部
137 セッション管理部
141 ディレクトリ操作ラッパー
142 セッション管理部
150 ディレクトリ
152 ユーザ情報保存部
153 グループ情報保存部
160 Localディレクトリプロバイダ
161 WinNT4ディレクトリプロバイダ
162 Notes(登録商標)R5ディレクトリプロバイダ
170 リポジトリサービス
200 セッションチケット(Unionマージプロバイダのセッションチケット)
210 セッションチケットID(UnionマージプロバイダのセッションチケットのID)
300 セッションチケット(サブプロバイダの匿名のセッションチケット)
310 セッションチケットID(サブプロバイダの匿名のセッションチケットのID)
400 セッションチケット(サブプロバイダのセッションチケット)
410 セッションチケットID(サブプロバイダのセッションチケットのID)
500 認証チケット(Unionマージプロバイダの認証チケット)
510 認証チケットID(Unionマージプロバイダの認証チケットのID)
600 認証チケット(サブプロバイダの認証チケット)
610 認証チケットID(サブプロバイダの認証チケットのID)
700 セッションチケット(リポジトリサービスのセッションチケット)
710 セッションチケットID(リポジトリサービスのセッションチケットのID)