[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[upki-fed:00662] Re: 複数のId体系のの扱い方

西村です。

尾崎さん、針木さん、
フォローありがとうございます！人によってやり方が違っておもしろいですね。

> name="urn:oid::1.3.6.1.4.1.5923.1.1.1.6"
> は、
> name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"
> の間違いですね。(test-sp1でもNOT RECEIVEDになってしまい焦りました)

大変申し訳ありませんでした！コピー範囲をミスしていたようです。

> のようにSAML1Stringも入れた形にしてしまったのですが、問題ないでしょうか？

SAML2とSAML1ではスコープの表現方法が異なる(*1)ので、そのままでは
うまくいかないのではないかと思いました。
https://test-sp3.gakunin.nii.ac.jp/
でお使いのIdPで認証して、ePPNがちゃんと渡っていますでしょうか？

尾崎さんと針木さんにフォローいただきました方法で、スコープ部分を削除
した上で、あらためてスコープ付き属性として"eduPersonPrincipalNameSAML1"
を定義し送信する必要があると思っています。

ただ、今調べたところ、学認のSPでまだSAML2に対応していなくて、ePPNを必須とし
ているSPは無いようですので、この際SAML1 ePPNの対応をばっさり切るというのも
選択肢の一つとして考えられるかもしれません。

*1 -
http://middleware.internet2.edu/dir/docs/internet2-mace-dir-saml-attributes-latest.pdf
の「2.5 Examples」にありますように、SAML2では
> <saml:AttributeValue xsi:type="xsd:string">xxxxxxxx@xxxxxxx</saml:AttributeValue>
のように属性値が送られますが、SAML1では
> <saml:AttributeValue Scope="osu.edu">cantor.2</saml:AttributeValue>
のように、スコープ部とローカル部を厳密に区別する必要があります。
これを考慮しない"SAML1String"では、SAML1でも前者のようにエンコードして送信してしまい、
この構造に依存する一部SPにて問題が発生すると考えられます。


(2013/06/24 13:10), Tatsumi Hosokawa wrote:
> 西村様
> 
> やってみたところ、無事にePPNがLDAP由来の値になりました。ありがとうございます。
> 
> ところで、
> 
> <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
>   name="urn:oid::1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" />
> 
> の、
> 
> name="urn:oid::1.3.6.1.4.1.5923.1.1.1.6"
> 
> は、
> 
> name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"
> 
> の間違いですね。(test-sp1でもNOT RECEIVEDになってしまい焦りました)
> 
> というわけで、ここのエントリは結局
> 
>      <resolver:AttributeDefinition id="eduPersonPrincipalName" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
>          sourceAttributeID="eduPersonPrincipalName">
>          <resolver:Dependency ref="myLDAP" />
>          
>          <resolver:AttributeEncoder xsi:type="SAML1String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
>              name="urn:mace:dir:attribute-def:eduPersonPrincipalName" />
>          
>          <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
>              name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" />
>      </resolver:AttributeDefinition>
> 
> のようにSAML1Stringも入れた形にしてしまったのですが、問題ないでしょうか？
> 
> この後、eduPersonTargetedIDの方の修正をやってみます。
> 
> よろしくお願いします。
> 
> 細川
> 
> (2013/06/21 12:37), Takeshi NISHIMURA wrote:
>> 西村です。
>>
>>> 昨日の、同じePPNで複数のエントリを作ることをやってみたのですが、なぜか片
>>> 方のエントリからのみePPNが渡されないという現象が生じてしまっており、首を
>>
>> # よくぞ聞いていただけました！
>>
>> ePPNなど一部の属性のみ渡らない（受け取るがSPが捨てている）ような
>> 場合の原因としてスコープの不一致が考えられます。
>> テストフェデレーションに参加しているIdPであれば テストSP2
>> https://test-sp2.gakunin.nii.ac.jp/
>> で認証していただければ、（このSPは全てのスコープを受け入れるので）
>> どのような値が送られているか確認できるはずです。
>> 詳しい内容は、このテストSP2トップページにも説明がございますので、ご参照ください。
>>
>> そして、先走って説明してしまうと、
>>> uid: xxxxxxxx@xxxxxxxxxx
>> にさらにスコープが付いた値(xxxxxxxx@xxxxxxxxxx@keio.ac.jp？)がePPNとして
>> 送られていると思います。
>> これをSPが受け取ると、最初の@以降、"@xxxxxxxxxx@xxxxxxxxxx"の部分をスコープと
>> 解釈してしまい、「これは不正な値である」として捨ててしまいます。
>> これがIdPのデフォルトの動作で、attribute-resolver.xmlで設定します。
>> 具体的には、下記の「属性定義の例」の通りに書かれていれば、上記のような
>> 動作となります。
>> https://www.gakunin.jp/docs/fed/technical/attribute/eduPersonPrincipalName
>> # つまり、デフォルトの動作では、LDAP上にeduPersonPrincipalNameが
>> # あっても、無視されます。
>>
>> さらに先走って、「LDAPに"eduPersonPrincipalName"を定義してその値をそのまま
>> 流したい」場合は、他の定義を参考にして以下のような設定にするとよいでしょう。
>>
>>       <resolver:AttributeDefinition id="eduPersonPrincipalName" xsi:type="Simple" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
>>           sourceAttributeID="eduPersonPrincipalName">
>>           <resolver:Dependency ref="myLDAP" />
>>           <resolver:AttributeEncoder xsi:type="SAML2String" xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
>>               name="urn:oid::1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" />
>>       </resolver:AttributeDefinition>
>>
>> 実は、SAML1対応のために、文字列からスコープ部分を分離する方法が私には分かりません。
>> どなたかご存知でしたら教えてください。_o_
>>
>>
>> (2013/06/21 9:21), Tatsumi Hosokawa wrote:
>>> 慶應義塾ITC本部の細川です。
>>>
>>> 昨日の、同じePPNで複数のエントリを作ることをやってみたのですが、なぜか片
>>> 方のエントリからのみePPNが渡されないという現象が生じてしまっており、首を
>>> 傾げています。
>>>
>>> LDAPの内容は、2エントリのみで
>>>
>>> % ldapsearch -x -D "cn=olmgr,o=keio,dc=ac,c=JP" -w ******** \
>>>      -b "ou=user,o=keio,dc=ac,c=JP" "uid=*"
>>> # extended LDIF
>>> #
>>> # LDAPv3
>>> # base <ou=user,o=keio,dc=ac,c=JP> with scope subtree
>>> # filter: uid=*
>>> # requesting: ALL
>>> #
>>>
>>> # aa097025, user, keio, ac, JP
>>> dn: uid=aa097025,ou=user,o=keio,dc=ac,c=JP
>>> objectClass: eduPerson
>>> cn: xxxxxxxx@xxxxxxxxxx
>>> ou: user
>>> sn: Hosokawa
>>> jao:: 5oW25oeJ576p5aG+
>>> uid: aa097025
>>> jaou:: 44Om44O844K2
>>> jasn:: 57Sw5bed
>>> mail: xxxxxxxx@xxxxxxxxxx
>>> givenName: Tatsumi
>>> displayName: Tatsumi Hosokawa
>>> jaGivenName:: 6YGU5bex
>>> userPassword:: ******
>>> jaDisplayName:: 57Sw5bedIOmBlOW3sQ==
>>> eduPersonAffiliation: staff
>>> eduPersonPrincipalName: xxxxxxxx@xxxxxxxxxx
>>> eduPersonScopedAffiliation: xxxxx@xxxxxxxxxx
>>>
>>> # xxxxxxxx@xxxxxxxxxx, user, keio, ac, JP
>>> dn: uid=xxxxxxxx@xxxxxxxxxx,ou=user,o=keio,dc=ac,c=JP
>>> objectClass: eduPerson
>>> cn: xxxxxxxx@xxxxxxxxxx
>>> ou: user
>>> sn: Hosokawa
>>> jao:: 5oW25oeJ576p5aG+
>>> uid: xxxxxxxx@xxxxxxxxxx
>>> jaou:: 44Om44O844K2
>>> jasn:: 57Sw5bed
>>> mail: xxxxxxxx@xxxxxxxxxx
>>> givenName: Tatsumi
>>> displayName: Tatsumi Hosokawa
>>> jaGivenName:: 6YGU5bex
>>> userPassword:: ******
>>> jaDisplayName:: 57Sw5bedIOmBlOW3sQ==
>>> eduPersonAffiliation: staff
>>> eduPersonPrincipalName: xxxxxxxx@xxxxxxxxxx
>>> eduPersonScopedAffiliation: xxxxx@xxxxxxxxxx
>>>
>>> # search result
>>> search: 2
>>> result: 0 Success
>>>
>>> # numResponses: 3
>>> # numEntries: 2
>>>
>>> のような感じです。
>>>
>>> ここで、test-sp1.gakunin.nii.ac.jpを用いて前者のエントリで認証すると、正
>>> 常にePPNが表示されるのですが、後者のエントリで認証すると、ePPNが「NOT
>>> RECEIVED」になってしまいます。
>>>
>>> ログで何が起こっているのか調べてみたのですが、関係有りそうな場所は次のよ
>>> うな感じです。でもなぜePPNにフィルタがかかってしまったのか、よくわかりま
>>> せん。
>>>
>>> 2013-06-21 09:07:43 DEBUG Shibboleth.AttributeFilter [2]: applying
>>> filtering rule(s) for attribute (eppn) from
>>> (https://gakunin1.keio.ac.jp/idp/shibboleth)
>>> 2013-06-21 09:07:43 WARN Shibboleth.AttributeFilter [2]: removed value
>>> at position (0) of attribute (eppn) from
>>> (https://gakunin1.keio.ac.jp/idp/shibboleth)
>>> 2013-06-21 09:07:43 WARN Shibboleth.AttributeFilter [2]: no values left,
>>> removing attribute (eppn) from (https://gakunin1.keio.ac.jp/idp/shibboleth)
>>>
>>> 同じePPNが複数あるのが問題かと思い、後者のみを残して1個のエントリにして
>>> 認証を行なってみたのですが、状況は変わりません。
>>>
>>> 申し訳ありませんが、どなたかこの状況がわかる方、教えていただけますでしょ
>>> うか。よろしくお願いします。

-- 
西村健
国立情報学研究所 TEL:03-4212-2890