[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[upki-fed:53] Re: [upki-fed:52] RE: [upki-fed:51] Re: [upki-fed:50] 【質問】Shibboleth IdP 2.1.2にしたらeduPersonTargetedIDのフォーマットが変わりますか？
- Subject: [upki-fed:53] Re: [upki-fed:52] RE: [upki-fed:51] Re: [upki-fed:50] 【質問】Shibboleth IdP 2.1.2にしたらeduPersonTargetedIDのフォーマットが変わりますか？
- Date: Thu, 20 Aug 2009 13:02:54 +0900
- From: Toyokazu Akiyama <xxxxxxx@xxxxxxxxxxxxxxxxxx>
京産大の秋山です．
ComputedID からの移行部分については全然テストできていなかったのですが，
開発者の意図した動作は以下のページによると，
https://spaces.internet2.edu/display/SHIB2/ResolverStoredIDDataConnector
The first ID created for a given requester is always the same as those
created by the computed ID data connector in order to provide a
migration path from that data connector. Every subsequently generated
ID for a given user/IdP/SP triple, if the first one is revoked, is a
Type 4 UUID.
ということで，最初は computed ID data connector と同じ方法で eduPersonTargetedID
を生成し，それ移行は UUID Type4（- で区切られたもの）を生成するらしいです．
最初は Computed ID data connector で，次から UUID って，どういうことだ？と思ってた
のですが，伊藤先生が指摘されているところを見ると，どうもちゃんと実装できてない
ですね．初回は当然 numberOfExistingEntries は 0 になるので ComputedID のロジックで
persistentID が生成されるのですが，do - while のループで上書きされていました．
# Eclipse の JPDA デバッグモードで確認しました．
もしこの方法を使うのであれば，本家にバグ報告した方がよさそうですね．
おそらく，正しい使い方としては，最初 ComputedID で登録しておいて，特定の SP に
ついて UUID に移行することを決定した時点で ComputedID のエントリの deactivationDate
を NOT NULL にすれば，新しく UUID のエントリが成功されて，そちらが使われるという
ロジックなんだと思います．
# つまりすべての SP について，１つは無効なエントリを作成する必要がある？
2009年8月20日10:53 に Tomohiro Ito<xxxxxxxx@xxxxxxxxxxxxxxxxxxx> さんは書きました:
> 山地先生
>
> 山形大学の伊藤です。
> ご返事、ありがとうございます。
>
> こんなところにコードがあったのですね。
>
> なんとなーく、問題点がわかってきました。間違っているかも
> しれませんので、詳しい方フォローしていただけると幸いです。
> Javaは、勉強不足なものですから、間違っている可能性があります。
>
> edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataC
> onnector.StoredIDDataConnector.PersistentIdEntry
>
> のメソッドが変更されたようです。
>
> Version 1.1.2には、新たに、
>
> do {
> log.debug("Generated persistent ID was already assigned to
> another user, regenerating");
> persistentId = UUID.randomUUID().toString();
> } while (pidStore.getPersistentIdEntry(persistentId, false) !=
> null);
>
> が追加されたようです。
> 開発者の意図としては、既に同じ、persistent IDがデータベースにあるときには、
> 新しいUUIDをランダムに生成するようにコーディングをしたのではないでしょうか？
>
> ここからは、Javaのことが詳しくないので推測ですが、
> JavaでDo { } while (式) 分を使うときは、
> 最初の１ループは実行するという構文ではないでしょうか？
>
> ただ、この動作がShibboleth IdP 2.1.2の仕様で、全て、UUID.randowmUUIDを使用す
> るということで
> あれば、正常動作と判断します。LocalEntityId、PeerEntityId、LocalId, saltが同
> 一条件下で
> 生成してみると同じＩＤが生成されないようで、ちょっと、気になっていました。
>
> 以上。よろしくお願いします。
>
> 〇Version 1.0.0
>
> protected PersistentIdEntry createPersistentId(ShibbolethResolutionContext
> resolutionContext, String localId,
> byte[] salt) throws SQLException {
> PersistentIdEntry entry = pidStore.new PersistentIdEntry();
>
> entry.setLocalEntityId(resolutionContext.getAttributeRequestContext().getLoc
> alEntityId());
>
> entry.setPeerEntityId(resolutionContext.getAttributeRequestContext().getInbo
> undMessageIssuer());
>
> entry.setPrincipalName(resolutionContext.getAttributeRequestContext().getPri
> ncipalName());
> entry.setLocalId(localId);
>
> String persisentId;
> int numberOfExistingEntries =
> pidStore.getNumberOfPersistentIdEntries(entry.getLocalEntityId(), entry
> .getPeerEntityId(), entry.getLocalId());
> if (numberOfExistingEntries == 0) {
> try {
> MessageDigest md = MessageDigest.getInstance("SHA");
> md.update(entry.getPeerEntityId().getBytes());
> md.update((byte) '!');
> md.update(localId.getBytes());
> md.update((byte) '!');
> persisentId = Base64.encodeBytes(md.digest(salt));
> } catch (NoSuchAlgorithmException e) {
> log.error("JVM error, SHA-1 is not supported, unable to
> compute ID");
> throw new SQLException("SHA-1 is not supported, unable to
> compute ID");
> }
> } else {
> persisentId = UUID.randomUUID().toString();
> }
> entry.setPersistentId(persisentId);
>
> entry.setCreationTime(new Timestamp(System.currentTimeMillis()));
>
> return entry;
> }
>
> 〇Version 1.1.2
> protected PersistentIdEntry createPersistentId(ShibbolethResolutionContext
> resolutionContext, String localId,
> byte[] salt) throws SQLException {
> PersistentIdEntry entry = pidStore.new PersistentIdEntry();
>
> entry.setLocalEntityId(resolutionContext.getAttributeRequestContext().getLoc
> alEntityId());
>
> entry.setPeerEntityId(resolutionContext.getAttributeRequestContext().getInbo
> undMessageIssuer());
>
> entry.setPrincipalName(resolutionContext.getAttributeRequestContext().getPri
> ncipalName());
> entry.setLocalId(localId);
>
> String persistentId;
> int numberOfExistingEntries =
> pidStore.getNumberOfPersistentIdEntries(entry.getLocalEntityId(), entry
> .getPeerEntityId(), entry.getLocalId());
> if (numberOfExistingEntries == 0) {
> try {
> MessageDigest md = MessageDigest.getInstance("SHA");
> md.update(entry.getPeerEntityId().getBytes());
> md.update((byte) '!');
> md.update(localId.getBytes());
> md.update((byte) '!');
> persistentId = Base64.encodeBytes(md.digest(salt));
> } catch (NoSuchAlgorithmException e) {
> log.error("JVM error, SHA-1 is not supported, unable to
> compute ID");
> throw new SQLException("SHA-1 is not supported, unable to
> compute ID");
> }
> } else {
> persistentId = UUID.randomUUID().toString();
> }
>
> do {
> log.debug("Generated persistent ID was already assigned to
> another user, regenerating");
> persistentId = UUID.randomUUID().toString();
> } while (pidStore.getPersistentIdEntry(persistentId, false) !=
> null);
>
> entry.setPersistentId(persistentId);
>
> entry.setCreationTime(new Timestamp(System.currentTimeMillis()));
>
> return entry;
> }
>
>> -----Original Message-----
>> From: xxxxxxxxxxxxxx@xxxxxxxxx [mailto:xxxxxxxxxxxxxx@xxxxxxxxx] On
>> Behalf Of xxxxxx@xxxxxxxxx
>> Sent: Thursday, August 20, 2009 12:16 AM
>> To: xxxxxxxx@xxxxxxxxx
>> Subject: [upki-fed:51] Re: [upki-fed:50] 【質問】Shibboleth IdP 2.1.2
>> にしたらeduPersonTargetedIDのフォーマットが変わりますか？
>>
>> ** On Wed, 19 Aug 2009 19:44:09 +0900
>> ** Tomohiro Ito <xxxxxxxx@xxxxxxxxxxxxxxxxxxx> writes:
>>
>> > Shibboleth IdP 2.1.2にしたら、eduPersonTargetedIDのフォーマットが、
>> >
>> > 0b000ab7-2fa7-4ebf-b387-fdd63dc15cf6
>>
>> StoreするIDのフォーマット自体が違ったということですか？
>> ということであれば，
>>
>> http://svn.middleware.georgetown.edu/view/java-shib-common/tags/1.0.0/
>> src/edu/internet2/middleware/shibboleth/common/attribute/resolver/prov
>> ider/dataConnector/StoredIDStore.java?view=log
>> と
>> http://svn.middleware.georgetown.edu/view/java-shib-common/tags/1.1.2/
>> src/main/java/edu/internet2/middleware/shibboleth/common/attribute/res
>> olver/provider/dataConnector/StoredIDStore.java?view=log
>>
>> あたりを比較したら違いがありますか？
>> --
>> Kazu
>
--
Toyokazu AKIYAMA
Faculty of Computer Science and Engineering,
Kyoto Sangyo University
TEL/FAX: +81-75-705-1531