...
eduPersonTargetedID(ePTID)を生成するときにLDAP上の属性としてuidを代表とした属性値が利用されますが、これら の属性値では再割り当ての問題があります。例えばuidとして を生成するときにLDAP上の属性としてuidを代表とした属性値が利用されますが、これらの属性値では再割り当ての問題があります。例えばuidとして test001 を使っていた人が異動になり、さらに年月が経って同じuidを使いたいという人が現われた場合にはそのまま割り当ててしまうことはできません。これはSP 側で uid=test001 という属性値を基に生成されたePTIDで個人を識別していた場合に、再割り当て前の人物と、再割り当て後の人物を区別できず同一人物とみなして再割り当 て前のアカウントの情報を利用してしまうことが起こるためです。
ePTIDでStoredIDを利用している場合には失効処理を行うことで新しいePTIDを生成することができることから、ソースとなる属性値の 再割り当てをすることは可能です。今回は別の方法として、uidの付加情報としてLDAPエントリの作成時間ePTIDでStoredIDを利用している場合には失効処理を行うことで新しいePTIDを生成することができることから、ソースとなる属性値の再割り当てをすることは可能です。今回は別の方法として、uidの付加情報としてLDAPエントリの作成時間(createTimestamp)を加えた 値をソースとしてePTIDを生成する方法を調査しました。例えば を加えた値をソースとしてePTIDを生成する方法を調査しました。例えば uid-createTimestamp のように2つの属性値をハイフンでつなげて test001-20130314110740Z といった値をソースとしてePTIDを生成すれば、uid再割り当てごとの失効処理が不要となります。ただし、再割り当ての際に必ず「作成時間」が変更さ れるように処理することが前提となります。
...