JP2009129289A - 情報処理装置及び情報処理方法及びプログラム - Google Patents

Abstract

【課題】人事異動により所属組織が変更になった際の新旧両組織での業務を可能とするための登録作業を効率的に行う。
【解決手段】猶予ポリシーテーブル（３−２）に、引継ぎ業務等に必要な旧組織の属性値の種類を予め保持種類として定め、異動情報（５）の入力の際に、ポリシー評価部（１−２）が新組織での属性値を示す新アカウント情報を生成し、ＩＤ管理リポジトリ（２）に格納されている旧組織での属性値を示す旧アカウント情報と新アカウント情報を比較し、猶予評価部（１−３）が、差異のある属性値が保持種類に合致するか否かを判断し、保持種類に合致する場合にその保持期限を指定し、ユーザ情報同期部（１−４）が新アカウント情報と当該属性値とをＩＤ管理リポジトリ及び認証形式Ａ用リポジトリ（４−１）等に格納し、保持期限が経過したら、ユーザ情報同期部がＩＤ管理リポジトリ（２）等の旧組織の属性値を消去する。
【選択図】図１

Description

この発明は、分散システムのユーザＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）情報および権限情報を整合性をとりながら統合管理するシステムに関するものである。

従来のＩＤ管理システムにおけるユーザ情報の同期は、即時の同期または、指定日時の同期のみが可能であり、企業における人事異動にともなうユーザ情報の同期に関しては、新旧どちらかの情報のみを同期するものが一般的である。

この点、例えば、特許文献１の「情報管理システムおよびその権限管理方法」では、所属組織の変更時、旧所属での業務引継ぎが円滑に行えるように、所定の期間、個人の識別情報を所属変更前の組織と所属変更後の組織の両方の組織識別情報に対応づけて登録しておくことにより、両方の組織のおける権限でシステムを使用可能とすることが記載されている。
特開２００１−５１９０２号公報

現在、企業内のシステムでは、内部統制の点から企業内のシステムのユーザＩＤの管理を統合するケースが増加している。
日本の企業では、人事異動発令とともに即異動先の業務のみを行うことよりも一定期間の引継ぎ期間、残務作業期間を設けていることが多い。
この期間は、新旧の部署における権限が必要となる。

従来のＩＤ管理システムによるユーザ情報同期では、人事異動時に新旧どちらかの権限のみの同期を行う。
そのため、新組織の権限の同期のみが行われると、引継ぎ期間中、残務作業期間中の作業に滞りが発生し、都度特別対応を実施する必要があるとの課題ある。

また、特許文献１の技術では、人事異動があった際に人事担当者がユーザ端末を用いてマニュアルで所属変更前の組織の組織識別情報と所属変更後の組織の組織識別情報の両方に対応づけて人事異動のあった従業員の個人識別情報を登録することが必要である。
このため、当該企業で使用するシステムが多い場合は、システムごとの登録が必要であり、登録作業に時間がかかり、人事担当者の負担となるという課題がある。

この発明は上記のような課題を解決することを主な目的の一つとしており、人事異動等により所属組織が変更になった際の新旧両組織での業務を可能とするための登録作業が効率的に行われる技術を提供することを主な目的とする。

本発明に係る情報処理装置は、
組織に所属するユーザの複数種の属性値が示される属性値情報を記憶する属性値情報記憶部と、
前記属性値情報に示される複数種の属性値のうち前記ユーザの所属組織が変更になった後も保持する属性値の種類を保持種類として示す保持種類情報を記憶する保持種類情報記憶部と、
前記ユーザの所属組織の変更を通知する所属組織変更通知を受信し、受信した所属組織変更通知に基づき、所属組織変更後の前記ユーザの属性を判定するとともに、判定した所属組織変更後の前記ユーザの属性に従って所属組織変更後の属性値情報を生成する属性値情報生成部と、
前記属性値情報生成部により生成された所属組織変更後の属性値情報と前記属性値情報記憶部に記憶されている所属組織変更前の属性値情報との差異を属性値ごとに分析する差異分析部と、
前記差異分析部により差異があると判断された属性値が保持種類に該当するか否かを判定し、差異のある属性値が保持種類に該当する場合に、当該属性値を保持属性値として指定する保持属性値指定部と、
前記属性情報記憶部に記憶されている所属組織変更前の属性値情報を、所属組織変更後の属性値情報と保持属性値とに更新する属性値情報更新部とを有することを特徴とする。

本発明によれば、所属変更後も保持する属性値の種類を保持種類として予め定めておき、所属組織変更通知を受信した際に、新旧の属性値情報間で差異のある属性値が保持種類に該当する場合に、所属組織変更後の属性値情報と所属変更前の当該属性値とが自動的に保持され、所属組織が変更になった際の新旧両組織での業務を可能とするための登録作業が効率的に行われる。

実施の形態１．
本実施の形態では、ユーザ情報変更にともなうポリシー評価時に、権限属性に差異が発生した場合、一定期間新旧情報を保持し、エンドユーザが引継ぎ期間中に新旧権限でシステムを利用することができる権限情報の同期技術を説明する。

図１は、本実施の形態に係るＩＤ管理システムの構成例を示す図である。
本実施の形態に係るシステムは、ＩＤ管理サーバ装置（１）（以下、ＩＤ管理サーバともいう）、ＩＤ管理リポジトリ（２）、猶予情報リポジトリ（３）、認証形式Ａ用リポジトリ（４−１）、認証形式Ｂ用リポジトリ（４−２）からなる。

本実施の形態では、猶予ポリシーテーブル（３−２）に、引継ぎ業務等に必要な旧組織の属性値の種類を予め保持種類として指定しておき、異動情報（５）が入力された際に、ポリシー評価部（１−２）が新組織での属性値を示す新アカウント情報を生成し、ＩＤ管理リポジトリ（２）に格納されている旧組織での属性値を示す旧アカウント情報と新アカウント情報を属性値ごとに比較する。そして、差異のある属性値が存在すれば、猶予評価部（１−３）が、差異のある対象属性値が猶予ポリシーテーブル（３−２）に示されている保持種類に合致するか否かを判断し、保持種類に合致する場合にその属性値の保持期限を指定し、旧情報管理テーブル（３−１）において当該属性値とその保持期限を管理する。
また、ユーザ情報同期部（１−４）が新アカウント情報と保持対象の属性値（保持属性値）とをＩＤ管理リポジトリ（２）、認証形式Ａ用リポジトリ（４−１）及び認証形式Ｂ用リポジトリ（４−２）に格納し、保持属性値の保持期限が経過したら、ユーザ情報同期部（１−４）がＩＤ管理リポジトリ（２）認証形式Ａ用リポジトリ（４−１）及び認証形式Ｂ用リポジトリ（４−２）の保持属性値を消去する。

ＩＤ管理リポジトリ（２）には、ユーザマスタテーブル（２−１）、アカウントマスタテーブル（認証形式Ｂ用）（２−２）、アカウントマスタテーブル（認証形式Ａ用）（２−３）、同期ポリシーテーブル（２−４）が記憶されている。
ＩＤ管理リポジトリ（２）は、属性値情報記憶部の例である。

ユーザマスタテーブル（２−１）では、図２に示すようにユーザＩＤ、部、課、役職が管理されている。
ユーザマスタテーブル（２−１）は、アカウントマスタテーブル（認証形式Ｂ用）（２−２）及びアカウントマスタテーブル（認証形式Ａ用）（２−３）の生成の基礎となる。

アカウントマスタテーブル（認証形式Ｂ用）（２−２）では、図６に示すようにユーザＩＤ、部、課、権限グループが管理されている。
アカウントマスタテーブル（認証形式Ａ用）（２−３）では、図７に示すようにユーザＩＤ、部、課、役職、権限グループが管理されている。
権限グループの値は、ユーザのデータアクセス権限を示すアクセス権限属性値である。アカウントマスタテーブル（認証形式Ｂ用）（２−２）及びアカウントマスタテーブル（認証形式Ａ用）では、アクセス権限属性値である権限グループの値とその他の属性値とが管理されている。
アカウントマスタテーブル（認証形式Ｂ用）（２−２）は認証形式Ｂに対応するテーブルであり、アカウントマスタテーブル（認証形式Ａ用）（２−３）は認証形式Ａに対応するテーブルである。
アカウントマスタテーブル（認証形式Ｂ用）（２−２）及びアカウントマスタテーブル（認証形式Ａ用）（２−３）の各レコードに示される情報及びユーザの所属組織の変更があった際にアカウントマスタテーブル（認証形式Ｂ用）（２−２）及びアカウントマスタテーブル（認証形式Ａ用）（２−３）の各レコードと同じ形式で生成される情報をアカウント情報という。
アカウントマスタテーブル（認証形式Ｂ用）（２−２）及びアカウントマスタテーブル（認証形式Ａ用）（２−３）に示されるアカウント情報、ユーザの所属組織の変更があった際に生成されるアカウント情報は、組織に所属するユーザ（企業の従業員等）の複数種の属性値を示しており、属性値情報の例である。

同期ポリシーテーブル（２−４）では、図５に示されるように、ターゲット、属性名、設定ポリシーが管理される。
ターゲットとは、アカウントマスタテーブル（認証形式Ａ用）（２−３）又はアカウントマスタテーブル（認証形式Ｂ用）（２−２）であり、ターゲットの欄のＡはアカウントマスタテーブル（認証形式Ａ用）（２−３）を表し、Ｂはアカウントマスタテーブル（認証形式Ｂ用）（２−２）を表している（他のテーブルにおいても同様）。
同期ポリシーテーブル（２−４）は、アカウントマスタテーブル（認証形式Ｂ用）（２−２）及びアカウントマスタテーブル（認証形式Ａ用）（２−３）に含まれる要素を定義するテーブルであり、ユーザの所属組織の変更があった際に生成されるアカウント情報は、同期ポリシーテーブル（２−４）の定義に従って生成される。

猶予情報リポジトリ（３）には、旧情報管理テーブル（３−１）及び猶予ポリシーテーブル（３−２）が記憶されている。
猶予情報リポジトリ（３）は、保持種類情報記憶部の例である。

旧情報管理テーブル（３−１）では、図３に示されるように、ユーザＩＤ、ターゲット、属性名、値、保持期限が管理される。
旧情報管理テーブル（３−１）は、ユーザの所属組織が変更になった後も、所属組織変更前の旧組織での引継ぎ業務を円滑にするために、旧組織のアカウント情報（属性値情報）（以下、旧アカウント情報という）のうちの一部の属性値を一定期間保持するためのテーブルである。
つまり、旧情報管理テーブル（３−１）のユーザＩＤは、旧アカウント情報の一部の属性値が保持されるユーザを示し、ターゲットは、旧アカウント情報の一部の属性値を保持するのはアカウントマスタテーブル（認証形式Ｂ用）（２−２）及びアカウントマスタテーブル（認証形式Ａ用）（２−３）のどちらであるかを示し、属性名は旧アカウント情報のうち値が保持される属性名を示し、値は旧アカウント情報のうち保持される属性値（保持属性値）を示し、保持期限は旧アカウント情報の保持属性値を保持する期間を示す。

猶予ポリシーテーブル（３−２）では、図４に示されるように、ターゲット、属性名が管理される。
猶予ポリシーテーブル（３−２）は、保持種類情報の例である。
猶予ポリシーテーブル（３−２）は、旧アカウント情報に示される複数種の属性値のうちユーザの所属組織が変更になった後も保持する属性値の種類（属性名）をターゲットごとに示している。ユーザの所属組織が変更になった後も保持する属性値の種類を保持種類という。

また、図１８及び図１９に示すように、ターゲット（認証形式）ごとに異なる保持種類が指定されている猶予ポリシーテーブル（３−２）を用いてもよい。
また、図１及び図４の例では、アクセス権限属性値である権限グループが保持種類として示されているが、引継ぎ業務等に必要な属性値であれば保持種類は他の属性値であってもよく、例えば、図１８に示すように、認証形式Ａに対して権限グループ以外に役職という属性を保持種類として指定する猶予ポリシーテーブル（３−２）を用いてもよい。
また、図１９に示すように、認証形式Ａに対して権限グループを保持種類として指定せずに、権限グループ以外の属性を保持種類として指定する猶予ポリシーテーブル（３−２）を用いてもよい。なお、図１及び図５の同期ポリシーテーブル（２−４）、図１及び図７のアカウントマスタテーブル（認証形式Ａ用）（２−３）にはメールアドレスという属性は含まれていないが、メールアドレスという属性を含ませるようにしてもよく、図１９は同期ポリシーテーブル（２−４）、アカウントマスタテーブル（認証形式Ａ用）（２−３）にメールアドレスという属性が含まれている場合に対応している。

認証形式Ａ用リポジトリ（４−１）は、図７のアカウントマスタテーブル（認証形式Ａ用）（２−３）と同じテーブル（コピーテーブル）を記憶している。
認証形式Ｂ用リポジトリ（４−２）は、図６のアカウントマスタテーブル（認証形式Ｂ用）（２−２）と同じテーブル（コピーテーブル）を記憶している。
認証形式Ａ用リポジトリ（４−１）に記憶されているアカウントマスタテーブル（認証形式Ａ用）（２−３）と同じテーブル（コピーテーブル）は認証形式Ａによる認証の際に実際に認証されるテーブルであり、同様に、認証形式Ｂ用リポジトリ（４−２）に記憶されているアカウントマスタテーブル（認証形式Ｂ用）（２−２）と同じテーブル（コピーテーブル）は認証形式Ｂによる認証の際に実際に認証されるテーブルである。
ＩＤ管理リポジトリ２においてアカウントマスタテーブル（認証形式Ａ用）（２−３）及びアカウントマスタテーブル（認証形式Ｂ用）（２−２）の更新の際に同期処理により認証形式Ａ用リポジトリ（４−１）及び認証形式Ｂ用リポジトリ（４−２）のテーブルも、更新後のアカウントマスタテーブル（認証形式Ａ用）（２−３）及び更新後のアカウントマスタテーブル（認証形式Ｂ用）（２−２）と同じ内容に更新される。
認証形式Ａ用リポジトリ（４−１）及び認証形式Ｂ用リポジトリ（４−２）は、アカウントマスタテーブル（認証形式Ａ用）（２−３）及びアカウントマスタテーブル（認証形式Ａ用）（２−３）と同じテーブル（コピーテーブル）を記憶しているため、アカウント情報（属性値情報）を記憶しており、属性値情報記憶部の例である。

ＩＤ管理サーバ（１）内には、ユーザ情報更新部（１−１）、ポリシー評価部（１−２）、猶予評価部（１−３）、ユーザ情報同期部（１−４）が含まれる。
なお、後述するように、ユーザ情報更新部（１−１）、ポリシー評価部（１−２）、猶予評価部（１−３）、ユーザ情報同期部（１−４）はプログラムとすることができ、ＩＤ管理サーバ（１）に搭載されているＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）が、プログラムを実行することで、以下に示すユーザ情報更新部（１−１）、ポリシー評価部（１−２）、猶予評価部（１−３）、ユーザ情報同期部（１−４）の各機能を実現することができる。
なお、ＩＤ管理サーバ装置（１）は、情報処理装置の例である。

ユーザ情報更新部（１−１）は、ユーザの所属組織の変更を通知する異動情報（５）（所属組織変更通知）を受信し、受信した異動情報（５）に基づき、所属組織変更後のユーザの属性を判定してユーザマスタテーブル（２−１）を更新する。
異動情報（５）は、例えばテキスト形式のファイルとしてＩＤ管理サーバ（１）の入力となる。異動情報（５）には、ユーザマスタテーブル（２−１）の項目に合わせて、新組織の部、課、ユーザの新組織における役職が示される。

ポリシー評価部（１−２）は、ユーザ情報更新部（１−１）により更新されたユーザマスタテーブル（２−１）及び同期ポリシーテーブル（２−４）に基づいて、所属組織変更後のユーザの属性に従って所属組織変更後のアカウント情報（以下、新アカウント情報という）を生成する。
また、ポリシー評価部（１−２）は、新アカウント情報とＩＤ管理リポジトリ（２）に記憶されている所属組織変更前の旧アカウント情報との差異を属性値ごとに分析する。

ユーザ情報更新部（１−１）とポリシー評価部（１−２）の一部の機能（新アカウント情報の生成）を合わせたものが属性値情報生成部の例となる。
また、ポリシー評価部（１−２）の残りの機能（属性値ごとの差異の分析）が、差異分析部の例となる。

猶予評価部（１−３）は、ポリシー評価部（１−２）により差異があると判断された属性値が保持種類に該当するか否かを猶予ポリシーテーブル（３−２）を参照して判定し、差異のある属性値が保持種類に該当する場合に、当該属性値を保持属性値として指定する。
また、猶予評価部（１−３）は、保持属性値の保持期限も指定する。
猶予評価部（１−３）により指定された保持属性値及び保持期限は旧情報管理テーブル（３−１）で管理される。
猶予評価部（１−３）は、保持属性値指定部の例である。

ユーザ情報同期部（１−４）は、ＩＤ管理リポジトリ（２）、認証形式Ａ用リポジトリ（４−１）及び認証形式Ｂ用リポジトリ（４−２）に記憶されている旧アカウント情報（所属組織変更前の属性値情報）を、新アカウント情報（所属組織変更後の属性値情報）と保持属性値とに更新する。
また、ユーザ情報同期部（１−４）は、猶予評価部（１−３）により指定された保持期間が経過した際に、保持属性値をＩＤ管理リポジトリ（２）、認証形式Ａ用リポジトリ（４−１）及び認証形式Ｂ用リポジトリ（４−２）から消去する。
ユーザ情報同期部（１−４）は、属性値情報更新部の例である。

次に動作について説明する。
図８に実施の形態１におけるＩＤ管理サーバ（１）のユーザ情報更新からアカウント情報の同期までのフローチャートを示す。

例えば人事部門のコンピュータより送付された異動情報（５）をＩＤ管理サーバ（１）のユーザ情報更新部（１−１）が受信する（Ｓ１）（属性値情報生成ステップ）。
受信した異動情報（５）を元に、ユーザ情報更新部（１−１）がユーザマスタテーブル（２−１）上の該当ユーザの情報を更新する（Ｓ２）（属性値情報生成ステップ）。
次に、ポリシー評価部（１−２）が、同期ポリシーテーブル（２−４）の情報に従い、更新されたユーザ情報から、各ターゲット（認証形式Ｂ、認証形式Ａ用）の新アカウント情報を作成する（Ｓ３）（属性値情報生成ステップ）。
次に、ポリシー評価部（１−２）が、Ｓ３で作成した新アカウント情報（認証形式Ｂ、認証形式Ａ用）とアカウントマスタテーブル（認証形式Ｂ用）（２−２）及びアカウントマスタテーブル（認証形式Ａ用）（２−３）上の旧アカウント情報と属性値ごとに比較を行う（Ｓ４）（差異分析ステップ）。
次に、ポリシー評価部（１−２）は、新旧属性値で差異があるかのチェックをし（Ｓ５）（保持属性値指定ステップ）、差異があればＳ６へ、差異がなければＳ１０へ移行する。

Ｓ５の判断において、差異があった場合、猶予評価部（１−３）が、猶予ポリシーテーブル（３−２）を参照し（Ｓ６）、差異のあった対象属性値の属性名が猶予ポリシーテーブル（３−２）に登録されているかをチェックする（Ｓ７）（保持属性値指定ステップ）。
登録されていればＳ８へ、登録されていなければＳ１０へ移行する。
差異のある対象属性値の属性名が猶予ポリシーテーブル（３−２）に登録されていれば、猶予評価部（１−３）は、旧情報（旧アカウント情報の対象属性値）を旧情報管理テーブル（３−１）に保持期限とともに保管する（Ｓ８）（保持属性値指定ステップ）。
次に、猶予評価部（１−３）は、新旧情報をあわせてアカウント情報を再生成する（Ｓ９）（保持属性値指定ステップ）。
つまり、猶予評価部（１−３）は、新アカウント情報に旧情報管理テーブル（３−１）に登録した旧アカウント情報の対象属性値（保持属性値）を加えて新たなアカウント情報とする。
次に、ポリシー評価部（１−２）が、新旧属性値の比較が全属性についてチェック完了したかを確認し（Ｓ１０）（保持属性値指定ステップ）、完了していればＳ１１へ、完了していなければＳ４へ移行する。

全属性の差異有無のチェックが完了したら、ユーザ情報同期部（１−４）が、Ｓ９で再生成されたアカウント情報（新アカウント情報と、旧アカウント情報の全ての対象属性値とが含まれているアカウント情報）をＩＤ管理リポジトリ（２）に格納するとともに、同じアカウント情報を各ターゲットのリポジトリ（認証形式Ａ用リポジトリ（４−１）、認証形式Ｂ用リポジトリ（４−２））に格納して、アカウント同期を行う（Ｓ１１）（属性値情報更新ステップ）。

ここで、ユーザＡ（ユーザＩＤ：ｕｓｅｒ０１）が部１１０、課１０から部１１１、課１１に異動したときの例を示す。
このとき、ｕｓｅｒ０１は異動前は、認証形式Ａの権限グループとして、同期ポリシーテーブルの定義により、１１０、１１０＿１０とを持ち、認証形式Ｂの権限グループとして１１０をもつこととなる。
異動に伴い、認証形式Ａの新権限グループは１１１、１１１＿１１となり、認証形式Ｂの新権限グループは１１１となる。
また、猶予ポリシーテーブル（３−２）には「権限グループ」が登録されているため、旧情報管理テーブル（３−１）には旧権限グループをターゲットごとに保管することになる。
つまり、アカウントマスタテーブル（認証形式Ａ用）（２−３）及び認証形式Ａ用リポジトリ（４−１）では、ユーザＡ（ユーザＩＤ：ｕｓｅｒ０１）の権限グループとして１１１、１１１＿１１（新権限グループ）と１１０、１１０＿１０（旧権限グループ）が示され、アカウントマスタテーブル（認証形式Ｂ用）（２−２）及び認証形式Ｂ用リポジトリ（４−２）では、権限グループとして１１１（新権限グループ）と１１０（旧権限グループ）が示されることになる（他の属性値では新旧で差異がない）。

旧情報管理テーブル（３−１）に保管された情報は、ユーザ情報同期部（１−４）が、日次処理にて期限の超えたものを削除する。
削除に伴い、ユーザ情報同期部（１−４）は、同期ポリシー評価を行い、各ターゲットの旧情報の削除も行う。
つまり、ユーザ情報同期部（１−４）は、保持期限が経過した際に、該当するレコードを旧情報管理テーブル（３−１）から消去するとともに、保持期限が経過した保持属性値をアカウントマスタテーブル（認証形式Ａ用）（２−３）及び認証形式Ａ用リポジトリ（４−１）から消去し、アカウントマスタテーブル（認証形式Ｂ用）（２−２）及び認証形式Ｂ用リポジトリ（４−２）から消去する。

なお、図１８、図１９に示す猶予ポリシーテーブル（３−２）を用いる場合は、猶予評価部（１−３）は、認証形式ごとに、新旧アカウント情報で差異のある対象属性値が保持種類に該当するか否かを判定し、差異のある対象属性値が対応する認証形式の保持種類に該当する場合に、当該対象属性値を当該認証形式の保持属性値として指定する。
その他の処理は、上述したものと同様である。

以上のように、本実施の形態では、あらかじめ設定しておいたポリシーにより旧情報を一定期間保持することで、ユーザが認証形式Ａ、認証形式Ｂを使用したときに、旧権限で必要なコンテンツへのアクセスが可能となる。
これにより、引継ぎ業務を円滑に行うことができる。
また、期限の超えた情報を定期的にチェックして削除することで、旧権限をターゲットから削除し、セキュリティホールをなくすことができる。
また、異動情報（５）を受信した際に、人事担当者等のオペレータが介在することなく、ＩＤ管理サーバ（１）がユーザマスタテーブル（２−１）を更新し、更新されたユーザマスタテーブル（２−１）を用いて新アカウント情報を生成するとともに、予め設定されている猶予ポリシーテーブル（３−２）に基づいて保持すべき旧アカウント情報の属性値を選択することができるので、人事異動のある者と新旧の組織との対応付け作業の効率化が図れる。

また、上記の説明では、猶予ポリシーテーブル（３−２）チェック後、属性ごとにアカウント情報を再作成しているが、全属性のチェック完了後にアカウント情報を再作成する方法でもよい。
また、上記の説明では、権限情報の新旧情報保持について記述しているが、ターゲットが複数値をとりうる属性について実施することも可能である。

以上、本実施の形態では、ＩＤ管理リポジトリを保有しているＩＤ管理サーバにおいて、ユーザ情報更新部、ポリシー評価部、権限猶予部、ユーザ情報同期部と猶予情報リポジトリを備え、アカウント情報の評価時に、旧情報と新情報とを比較し、一定期間旧情報を保管かつ同期情報に含めるＩＤ管理方式およびＩＤ管理システムについて説明した。

実施の形態２．
以上の実施の形態１では、猶予ポリシーにおいて、常に旧情報、新情報を同時に管理するものであった。
次に、属性同期ポリシーにて同期を行う情報を属性ごと、ターゲットごとにポリシーを変えることのできる実施の形態を示す。

図９にシステム構成例を、図１０に猶予ポリシーテーブル（３−２）の例を示す。
猶予ポリシーテーブル（３−２）には、ターゲットごとにポリシーを設定できるように同期ポリシーを追加する。
図１０の例では、認証形式Ａでは、権限グループについて、新アカウント情報の属性値と旧アカウント情報の属性値の両方を保持することとしているが、認証形式Ｂでは、権限グループについて、旧アカウント情報の属性値のみ保持することとしている。

次に動作について説明する。
図１１に、実施の形態２におけるＩＤ管理サーバ（１）のユーザ情報更新からアカウント情報の同期までのフローチャートを示す。

Ｓ６までは実施の形態１と同様であり、説明を省略する。
Ｓ７にて、猶予評価部（１−３）が、猶予ポリシーテーブル（３−２）をチェックし（保持属性値指定ステップ）、対象属性値の属性名が猶予ポリシーテーブル（３−２）に存在すればＳ１３へ、なければＳ１０へ移行する。
Ｓ１３にて、猶予評価部（１−３）は、猶予ポリシーテーブル（３−２）の同期ポリシーをチェックし、同期ポリシーが「新旧保持」ならばＳ９へ、「旧のみ」ならばＳ１４へ、「新のみ」ならばＳ３１に移行する（保持属性値指定ステップ）。

Ｓ９では、猶予評価部（１−３）が、実施の形態１と同様に新旧情報をあわせてアカウント情報を作成する（保持属性値指定ステップ）。
Ｓ１４では、猶予評価部（１−３）は、「新情報」で作成されていたアカウント情報を旧情報で再作成を行う（保持属性値指定ステップ）。つまり、その対象属性については、新アカウント情報の対象属性値を破棄し、旧アカウント情報の対象属性値のみを保持するようにする。
一方、Ｓ３１では、猶予評価部（１−３）は、「新情報」でアカウント情報を再生成する０。つまり、つまり、その対象属性については、旧アカウント情報の対象属性値を破棄し、新アカウント情報の対象属性値のみを保持するようにする。
また、Ｓ３２において、猶予評価部（１−３）は、Ｓ９又はＳ１４の処理が行われた場合は旧情報を削除する削除期限を設定する（保持属性値指定ステップ）。
全属性のチェックが完了したら、実施の形態１と同様に、ユーザ情報同期部（１−４）が、各ターゲットのリポジトリ（認証形式Ａ用リポジトリ（４−１）、認証形式Ｂ用リポジトリ（４−２））へアカウント同期を行う（Ｓ１１）（保持属性値指定ステップ）。

以上のように、ターゲット毎に猶予のポリシーを設定することが可能となることで、新旧どちらかしか属性値を保有できないターゲットへの対応も可能となる。

なお、上記の説明では、猶予ポリシーテーブル（３−２）チェック後、属性ごとにアカウント情報を再作成しているが、全属性のチェック完了後にアカウント情報を再作成する方法でもよい。

また、ターゲットによっては、旧情報は別属性に設定しなければならないケースもあるが、猶予ポリシーテーブル（３−２）の同期ポリシーに旧属性値をどの属性に設定するかを記述することにより、アカウント情報作成で、別の属性に旧属性値を設定し、同期を取ることも可能となる。

また、図２０に示すように、図１８の猶予ポリシーテーブル（３−２）に同期ポリシーを追加した猶予ポリシーテーブル（３−２）を用いてもよいし、図２１に示すように、図１９の猶予ポリシーテーブル（３−２）に同期ポリシーを追加した猶予ポリシーテーブル（３−２）を用いてもよい。
図２１の例では、認証形式Ａについて（１）役職に対しては（１）新旧を保持する同期ポリシーが適用され、（２）メールアドレスに対しては（２）新のみを保持する同期ポリシーが適用されることになっており、認証形式ごと、保有種類ごとに同期ポリシーを変えてもよい。

以上、本実施の形態では、旧情報の保管・同期を外部条件に応じてアカウントターゲットごとに制御するＩＤ管理システムについて説明した。

実施の形態３．
以上の実施の形態１では、すべての処理が同一サーバで行われる構成であった。
次に猶予処理部分を別サーバに配置する実施の形態を示す。

図１２は、本実施の形態に係るシステム構成例を示す図である。
実施の形態１の構成に加え、猶予管理サーバ装置（６）（以下、猶予管理サーバともいう）が追加される。
なお、ＩＤ管理サーバ装置（１）は第１のサーバ装置の例であり、猶予管理サーバ装置（６）は第２のサーバ装置の例である。

以下に、実施の形態１との差異を示す。
図１２内のＩＤ管理サーバ（１）は、ユーザ情報更新部（１−１）、ポリシー評価部（１−２）、ユーザ情報同期部（１−４）を保有している。

また、ＩＤ管理リポジトリ（２）内では、図２に示すようにユーザマスタテーブル（２−１）においてユーザＩＤ、部、課、役職が管理され、図６に示すようにアカウントマスタテーブル（認証形式Ｂ用）（２−２）においてユーザＩＤ、部、課、権限グループが管理され、図７に示すようにアカウントマスタテーブル（認証形式Ａ用）（２−３）においてユーザＩＤ、部、課、役職、権限グループが管理され、図５に示されるように同期ポリシーテーブル（２−４）においてターゲット、属性名、設定ポリシーが管理される。

猶予管理サーバ（６）は、猶予評価部（１−３）を保有し、猶予情報リポジトリ（３）では、旧情報管理テーブル（３−１）において図３に示されるようにユーザＩＤ、ターゲット、属性名、値、保持期限が管理され、猶予ポリシーテーブル（３−２）において図４に示されるようにターゲット、属性名、同期ポリシーが管理される。

ＩＤ管理サーバ（１）から猶予管理サーバ（６）へ送信される情報として、猶予チェック情報（７−１）があり、猶予評価処理の結果として猶予管理サーバ（６）からＩＤ管理サーバ（１）へ送信される情報として、猶予チェック結果情報（７−２）がある。
猶予チェック情報（７−１）は、新旧のアカウント情報間で差異のある対象属性値が示される情報であり、ＩＤ管理サーバ（１）が猶予管理サーバ（６）に対象属性値の属性名が猶予ポリシーテーブル（３−２）に示されているか否かのチェックを依頼する情報である。猶予チェック情報（７−１）は差異属性値情報の例である。
猶予チェック結果情報（７−２）は、猶予チェック情報（７−１）に示される対象属性値に対するチェックが行われ、猶予管理サーバ（６）により保持対象の属性値（保持属性値）として指定された属性値が示される情報である。猶予チェック結果情報（７−２）は、保持属性値情報の例である。

次に、図１３及び図１４を参照して、本実施の形態に係る動作について説明する。
なお、Ｓ１〜Ｓ１６及びＳ２０〜Ｓ１１の処理はＩＤ管理サーバ（１）で行われ、Ｓ１７〜Ｓ１９の処理は猶予管理サーバ（６）で行われる。

Ｓ５までは実施の形態１と同様であり、説明を省略する。
Ｓ５にて新旧アカウント情報間で属性値に差異がある場合にはＳ１５へ、ない場合はＳ１０へ移行する。
Ｓ１５では、ポリシー評価部（１−２）が、猶予チェック情報（７−１）に属性名と旧情報（対象属性値）を追加する。
Ｓ１０にて、ポリシー評価部（１−２）は、全属性チェックが完了したかを確認し、完了していればＳ１６へ、完了していなければＳ４へ移行する。
全属性チェックが完了している場合には、ポリシー評価部（１−２）は、猶予チェック情報（７−１）を猶予管理サーバ（６）に送信する（Ｓ１６）。

猶予管理サーバ（６）では、猶予評価部（１−３）が、猶予チェック情報（７−１）を受信し（Ｓ１７）、猶予チェック情報（７−１）にある属性名と対象属性値について猶予ポリシーテーブル（３−２）をチェックする（Ｓ６）。
対象属性値の属性名が猶予ポリシーテーブル（３−２）に登録されていればＳ８へ、登録されていなければＳ１０へ移行する（Ｓ７）。
登録されていた場合、猶予評価部（１−３）は、旧情報（対象属性値）を保持期限とともに旧情報管理テーブル（３−１）に保管する（Ｓ８）とともに猶予チェック結果情報（７−２）に属性名と対象属性値を追加する（Ｓ１８）。
Ｓ６からＳ１８までを猶予チェック情報（７−１）に載っている属性すべてについて実施した後に、猶予評価部（１−３）は、猶予チェック結果情報（７−２）をＩＤ管理サーバ（１）に送信する（Ｓ１９）。

ＩＤ管理サーバ（１）では、ユーザ情報同期部（１−４）が猶予チェック結果情報（７−２）を受信する（Ｓ２０）とともに、受信した猶予チェック結果情報（７−２）を元に旧情報、新情報とを合わせて、アカウント情報を再作成する（Ｓ２１）。
アカウント情報作成後、実施の形態１と同様に、ユーザ情報同期部（１−４）が、各ターゲットのリポジトリ（認証形式Ａ用リポジトリ（４−１）、認証形式Ｂ用リポジトリ（４−２））へアカウント同期を行う（Ｓ１１）。

以上のようにＩＤ管理サーバと猶予管理サーバとを分離することにより、必要に応じてＩＤ管理機能と猶予管理機能とを連携させることや、ＩＤ管理機能を停止させずに猶予管理機能のメンテナンスが可能となる。

以上、本実施の形態では、権限猶予部、猶予情報リポジトリとを別サーバにて構成するＩＤ管理システムについて説明した。

実施の形態４．
以上の実施の形態３では、常に新旧情報をターゲットに同期をとる場合のＩＤ管理サーバと猶予管理サーバとを分離した実施の形態であるが、次にターゲットごとに同期ポリシーを制御可能としたＩＤ管理サーバと猶予管理サーバとを分離した実施の形態を示す。

図１５は、実施の形態４に係るシステム構成例を示す。
実施の形態３の構成図を示す図１２との差異についてのみ説明する。
図１５では、猶予ポリシーテーブル（３−２）に同期ポリシーカラムをもつ。
つまり、本実施の形態は、実施の形態３で示したシステム構成に実施の形態２で説明した猶予ポリシーテーブルを適用するものである。

実施の形態４におけるフローは実施の形態３が基本となり、猶予評価後に値を設定する部分（図１４のＳ２１）が実施の形態２のフロー（図１１のＳ９、Ｓ１４、Ｓ３１）となる。

以上のようにＩＤ管理機能と猶予管理機能とを分離させたときにも、ターゲット毎に猶予のポリシーを設定することが可能となることで、新旧どちらかしか属性値を保有できないターゲットへの対応も可能となる。

以上、本実施の形態では、権限猶予部、猶予情報リポジトリとを別サーバにて構成するとともに、旧情報の保管・同期を外部条件に応じてアカウントターゲットごとに制御するＩＤ管理システムについて説明した。

実施の形態５．
以上の実施の形態３では、ＩＤ管理サーバと猶予管理サーバとが１対１であったが、１台の猶予管理サーバにて複数台のＩＤ管理サーバの猶予管理を行う実施の形態を示す。

図１６は、実施の形態５に係るシステム構成例を示す図である。
実施の形態３の構成図を示す図１２との差異についてのみ説明する。
猶予管理サーバ（６）と連携をとるＩＤ管理サーバＡ（１ａ）とＩＤ管理サーバＢ（１ｂ）とそれぞれのＩＤ管理サーバの同期ターゲットである認証形式Ａ用リポジトリＡ（４−１ａ）、認証形式Ｂ用リポジトリＡ（４−２ａ）、認証形式Ａ用リポジトリＢ（４−１ｂ）、認証形式Ｂ用リポジトリＢ（４−２ｂ）がある。
また、旧情報管理テーブル（３−１）にサーバを特定するためのサーバカラムが追加される。
このように、本実施の形態は、一つの猶予管理サーバ（６）（第２のサーバ装置）が複数のＩＤ管理サーバ（１）（第１のサーバ装置）から猶予チェック情報（７−１）を受信し、複数のＩＤ管理サーバ（１）（第１のサーバ装置）に猶予チェック結果情報（７−２）を送信する構成となっている。

実施の形態５におけるフローは、実施の形態３と基本的に同様となる。旧情報を旧情報管理テーブル（３−１）に登録する際（図１４のＳ８）にサーバ名も登録する部分が異なる。

以上のように、１台の猶予管理サーバで複数台のＩＤ管理サーバの猶予管理機能をサポートすることにより、グループ企業のようなＩＤ管理はそれぞれ別に行う必要があるが、猶予ポリシーは統一する場合に、猶予管理機能を冗長構成にすることなく、猶予ポリシーの管理コストを下げることができる。

以上、本実施の形態では、１台の猶予管理サーバで、複数台のＩＤ管理サーバの猶予管理処理を実施するＩＤ管理システムについて説明した。

実施の形態６．
以上の実施の形態５では、常に新旧情報をターゲットに同期をとる場合の１台の猶予管理サーバで複数台のＩＤ管理サーバの猶予管理機能をサポートする実施の形態を説明したが、次にターゲットごとに同期ポリシーを制御可能とした１台の猶予管理サーバで複数台のＩＤ管理サーバの猶予管理機能をサポートする実施の形態を示す。

図１７は、実施の形態６に係るシステム構成例を示す。
実施の形態５の構成図を示す図１６との差異についてのみ説明する。
図１７では、猶予ポリシーテーブル（３−２）に同期ポリシーカラムをもつ。

実施の形態６におけるフローは実施の形態３が基本となり、猶予評価後に値を設定する部分（図１５のＳ２１）が実施の形態２のフロー（図１１のＳ９、Ｓ１４、Ｓ３１）となる。

以上のように１台の猶予管理サーバで複数台のＩＤ管理サーバの猶予機能をサポートするときにも、ターゲット毎に猶予のポリシーを設定することが可能となることで、新旧どちらかしか属性値を保有できないターゲットへの対応も可能となる。

他にも、猶予ポリシーテーブル（３−２）でもサーバ情報を管理することによりサーバごとに猶予ポリシーを変えることも可能となり、ポリシー制御の自由度を広げる効果を得ることができる。

以上、本実施の形態では、１台の猶予管理サーバで、複数台のＩＤ管理サーバの猶予管理処理を実施するとともに、旧情報の保管・同期を外部条件に応じてアカウントターゲットごとに制御するＩＤ管理システムについて説明した。

最後に、実施の形態１〜６に示したＩＤ管理サーバ（１）及び猶予管理サーバ（６）のハードウェア構成例について説明する。
図２２は、実施の形態１〜６に示すＩＤ管理サーバ（１）及び猶予管理サーバ（６）のハードウェア資源の一例を示す図である。
なお、図２２の構成は、あくまでもＩＤ管理サーバ（１）及び猶予管理サーバ（６）のハードウェア構成の一例を示すものであり、ＩＤ管理サーバ（１）及び猶予管理サーバ（６）のハードウェア構成は図２２に記載の構成に限らず、他の構成であってもよい。

図２２において、ＩＤ管理サーバ（１）及び猶予管理サーバ（６）は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。
ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９１４、通信ボード９１５、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。
更に、ＣＰＵ９１１は、表示装置９０１、キーボード９０２、マウス９０３、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。
また、磁気ディスク装置９２０の代わりに、光ディスク装置、メモリカード（登録商標）読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
通信ボード９１５、キーボード９０２、マウス９０３、スキャナ装置９０７、ＦＤＤ９０４などは、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力装置の一例である。

通信ボード９１５は、ネットワークに接続されている。例えば、通信ボード９１５は、ＬＡＮ（ローカルエリアネットワーク）、インターネット、ＷＡＮ（ワイドエリアネットワーク）などに接続されていても構わない。

磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。プログラム群９２３のプログラムは、ＣＰＵ９１１、オペレーティングシステム９２１、ウィンドウシステム９２２により実行される。

ＲＯＭ９１３には、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）プログラムが格納され、磁気ディスク装置９２０にはブートプログラムが格納されている。
ＩＤ管理サーバ（１）及び猶予管理サーバ（６）の起動時には、ＲＯＭ９１３のＢＩＯＳプログラム及び磁気ディスク装置９２０のブートプログラムが実行され、ＢＩＯＳプログラム及びブートプログラムによりオペレーティングシステム９２１が起動される。

上記プログラム群９２３には、実施の形態１〜６の説明において「〜部」として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。

ファイル群９２４には、実施の形態１〜６の説明において、「〜の判断」、「〜の計算」、「〜の比較」、「〜の評価」、「〜の作成」、「〜の更新」、「〜の設定」、「〜の登録」、「〜の選択」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。
「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。
抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、実施の形態１〜６で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。

また、実施の形態１〜６の説明において「〜部」として説明しているものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。すなわち、プログラムは、実施の形態１〜６の「〜部」としてコンピュータを機能させるものである。あるいは、実施の形態１〜６の「〜部」の手順や方法をコンピュータに実行させるものである。

このように、実施の形態１〜６に示すＩＤ管理サーバ（１）及び猶予管理サーバ（６）は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータであり、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。

実施の形態１に係るＩＤ管理システムの構成例を示す図。 実施の形態１に係るユーザマスタテーブルの例を示す図。 実施の形態１に係る旧情報管理テーブルの例を示す図。 実施の形態１に係る猶予ポリシーテーブルの例を示す図。 実施の形態１に係る同期ポリシーテーブルの例を示す図。 実施の形態１に係るアカウントマスタテーブル（認証形式Ｂ用）の例を示す図。 実施の形態１に係るアカウントマスタテーブル（認証形式Ａ用）の例を示す図。 実施の形態１に係るＩＤ管理システムの動作例を示すフローチャート図。 実施の形態２に係るＩＤ管理システムの構成例を示す図。 実施の形態２に係る猶予ポリシーテーブルの例を示す図。 実施の形態２に係るＩＤ管理システムの動作例を示すフローチャート図。 実施の形態３に係るＩＤ管理システムの構成例を示す図。 実施の形態３に係るＩＤ管理システムの動作例を示すフローチャート図。 実施の形態３に係るＩＤ管理システムの動作例を示すフローチャート図。 実施の形態４に係るＩＤ管理システムの構成例を示す図。 実施の形態５に係るＩＤ管理システムの構成例を示す図。 実施の形態６に係るＩＤ管理システムの構成例を示す図。 実施の形態１に係る猶予ポリシーテーブルの例を示す図。 実施の形態１に係る猶予ポリシーテーブルの例を示す図。 実施の形態２に係る猶予ポリシーテーブルの例を示す図。 実施の形態２に係る猶予ポリシーテーブルの例を示す図。 実施の形態１〜６に係るＩＤ管理サーバ及び猶予管理サーバの例を示す図。

符号の説明

１ ＩＤ管理サーバ装置、１−１ ユーザ情報更新部、１−２ ポリシー評価部、１−３ 猶予評価部、１−４ ユーザ情報同期部、２ ＩＤ管理リポジトリ、３ 猶予情報リポジトリ、４−１ 認証形式Ａ用リポジトリ、４−２ 認証形式Ｂ用リポジトリ、５ 異動情報、６ 猶予管理サーバ装置。

Claims (9)

1. 組織に所属するユーザの複数種の属性値が示される属性値情報を記憶する属性値情報記憶部と、
   前記属性値情報に示される複数種の属性値のうち前記ユーザの所属組織が変更になった後も保持する属性値の種類を保持種類として示す保持種類情報を記憶する保持種類情報記憶部と、
   前記ユーザの所属組織の変更を通知する所属組織変更通知を受信し、受信した所属組織変更通知に基づき、所属組織変更後の前記ユーザの属性を判定するとともに、判定した所属組織変更後の前記ユーザの属性に従って所属組織変更後の属性値情報を生成する属性値情報生成部と、
   前記属性値情報生成部により生成された所属組織変更後の属性値情報と前記属性値情報記憶部に記憶されている所属組織変更前の属性値情報との差異を属性値ごとに分析する差異分析部と、
   前記差異分析部により差異があると判断された属性値が保持種類に該当するか否かを判定し、差異のある属性値が保持種類に該当する場合に、当該属性値を保持属性値として指定する保持属性値指定部と、
   前記属性情報記憶部に記憶されている所属組織変更前の属性値情報を、所属組織変更後の属性値情報と保持属性値とに更新する属性値情報更新部とを有することを特徴とする情報処理装置。
2. 前記保持属性値指定部は、
   保持属性値を指定するとともに、保持属性値の保持期間を指定し、
   前記属性値情報更新部は、
   前記保持属性値指定部により指定された保持期間が経過した際に、前記保持属性値を前記属性値情報記憶部から消去することを特徴とする請求項１に記載の情報処理装置。
3. 前記属性値情報記憶部は、
   前記ユーザのデータアクセス権限を示すアクセス権限属性値とその他の属性値とが示される属性値情報を記憶し、
   前記保持種類情報記憶部は、
   前記アクセス権限属性値及びその他の属性値の少なくともいずれかを保持種類として示す保持種類情報を記憶することを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記属性値情報記憶部は、
   複数の認証形式の各々に対応させて複数の属性値情報を記憶しており、
   前記保持種類情報記憶部は、
   認証形式ごとの保持種類を示す保持種類情報を記憶しており、
   前記保持属性値指定部は、
   前記差異分析部により差異があると判断された属性値が保持種類に該当するか否かを認証形式ごとに判定し、差異のある属性値がいずれかの認証形式の保持種類に該当する場合に、当該属性値を当該認証形式の保持属性値として指定し、
   前記属性値情報更新部は、
   認証形式ごとに、前記属性情報記憶部に記憶されている所属組織変更前の属性値情報を、所属組織変更後の属性値情報と前記保持属性値に更新することを特徴とする請求項１〜３のいずれかに記載の情報処理装置。
5. 前記属性値情報記憶部は、
   複数の認証形式の各々に対応させて複数の属性値情報を記憶しており、
   前記保持種類情報記憶部は、
   認証形式ごとに、保持種類を示すとともに、保持種類について所属組織変更前の属性値の記憶の要否及び所属組織変更後の属性値の記憶の要否を示す保持種類情報を記憶しており、
   前記保持属性値指定部は、
   保持種類情報に基づき、認証形式ごとに、保持種類について所属組織変更前の属性値の記憶の要否及び所属組織変更後の属性値の記憶の要否を判定し、
   前記属性値情報更新部は、
   前記保持属性値指定部における要否判定の結果に基づき、保持種類について所属組織変更前の属性値及び所属組織変更後の属性値の少なくともいずれかを前記属性値情報記憶部に書き込むことを特徴とする請求項１〜３のいずれかに記載の情報処理装置。
6. 前記情報処理装置は、
   前記属性値情報記憶部と、前記属性値情報生成部と、前記差異分析部と、前記属性値情報更新部とが含まれる第１のサーバ装置と、
   前記保持種類情報記憶部と、前記保持属性値指定部とが含まれる第２のサーバ装置とを有し、
   前記第１のサーバ装置において、
   前記差異分析部は、
   差異があると判断した属性値を示す差異属性値情報を前記第２のサーバ装置の前記保持属性値指定部に送信し、
   前記属性値情報更新部は、
   前記第２のサーバ装置の前記保持属性値指定部から、指定された保持属性値が示される保持属性値情報を受信し、受信した保持属性値情報に基づいて前記属性値情報記憶部の更新を行い、
   前記第２のサーバ装置において、
   前記保持属性値指定部は、
   前記第１のサーバ装置の前記差異分析部から差異属性値情報を受信し、前記差異分析部により差異があると判断された属性値が保持種類に該当するか否かを判定し、差異のある属性値が保持種類に該当する場合に、当該属性値を保持属性値として指定し、指定した保持属性値を示す保持属性値情報を前記第１のサーバ装置の前記属性値情報更新部に送信することを特徴とする請求項１〜５のいずれかに記載の情報処理装置。
7. 前記情報処理装置は、
   複数の第１のサーバ装置を有し、
   前記第２のサーバ装置において、
   前記保持属性値指定部は、各々の第１のサーバ装置の差異分析部から差異属性値情報を受信し、各々の第１のサーバ装置の属性値情報更新部に保持属性値情報を送信することを特徴とする請求項６に記載の情報処理装置。
8. 組織に所属するユーザの複数種の属性値が示される属性値情報を記憶する属性値情報記憶部と、前記属性値情報に示される複数種の属性値のうち前記ユーザの所属組織が変更になった後も保持する属性値の種類を保持種類として示す保持種類情報を記憶する保持種類情報記憶部とを有するコンピュータが、
   前記ユーザの所属組織の変更を通知する所属組織変更通知を受信し、受信した所属組織変更通知に基づき、所属組織変更後の前記ユーザの属性を判定するとともに、判定した所属組織変更後の前記ユーザの属性に従って所属組織変更後の属性値情報を生成する属性値情報生成ステップと、
   前記属性値情報生成ステップにより生成された所属組織変更後の属性値情報と前記属性値情報記憶部に記憶されている所属組織変更前の属性値情報との差異を属性値ごとに分析する差異分析ステップと、
   前記差異分析ステップにより差異があると判断された属性値が保持種類に該当するか否かを判定し、差異のある属性値が保持種類に該当する場合に、当該属性値を保持属性値として指定する保持属性値指定ステップと、
   前記属性情報記憶部に記憶されている所属組織変更前の属性値情報を、所属組織変更後の属性値情報と保持属性値とに更新する属性値情報更新ステップとを有することを特徴とする情報処理方法。
9. 組織に所属するユーザの複数種の属性値が示される属性値情報を記憶する属性値情報記憶部と、前記属性値情報に示される複数種の属性値のうち前記ユーザの所属組織が変更になった後も保持する属性値の種類を保持種類として示す保持種類情報を記憶する保持種類情報記憶部とを有するコンピュータに、
   前記ユーザの所属組織の変更を通知する所属組織変更通知を受信し、受信した所属組織変更通知に基づき、所属組織変更後の前記ユーザの属性を判定するとともに、判定した所属組織変更後の前記ユーザの属性に従って所属組織変更後の属性値情報を生成する属性値情報生成処理と、
   前記属性値情報生成処理により生成された所属組織変更後の属性値情報と前記属性値情報記憶部に記憶されている所属組織変更前の属性値情報との差異を属性値ごとに分析する差異分析処理と、
   前記差異分析処理により差異があると判断された属性値が保持種類に該当するか否かを判定し、差異のある属性値が保持種類に該当する場合に、当該属性値を保持属性値として指定する保持属性値指定処理と、
   前記属性情報記憶部に記憶されている所属組織変更前の属性値情報を、所属組織変更後の属性値情報と保持属性値とに更新する属性値情報更新処理とを実行させることを特徴とするプログラム。

Images