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

[upki-fed:00804] Re: Filter Per SP (FPSP) の動作に関する質問



オープンソース・ソリューション・テクノロジ 相本様

ありがとうございます。安心しました。

SPに送信されない属性を用いてFPSPで制限する術があるかどうかは、
引き続き今後の課題として検討してみたいと思います。

重要なパッチを有難うございました。よろしくお願いします。

細川

(2014/03/24 17:21), AIMOTO Norihito wrote:
> 慶應義塾ITC本部 細川さま
> 
> オープンソース・ソリューション・テクノロジ 相本です。
> 
> 細川さまのパッチで、問題ないことを確認しました。
> sendRedirectメソッドを使用しなくても、uApprove.jp に遷移しません。
> 
> 私の送付した事象対応のパッチでは、FPSP拒否時に LoginContext を無効します。
> uApprove.jp のソースを確認したところ、LoginContext が取れなければ
> 動作しないようになっていました。
> よって FPSP 拒否時はuApprove.jp に遷移しません。
> 
> 私が FPSP の動作確認をしたときに下記の順番で問題を見つけました。
>   (1) uApprove.jp に遷移してから拒否画面となる
>   (2) 一度でも拒否した SP にアクセスすると他のSPを使えなくなる
>   (3) IdP にログインしなかった場合に、SP が使えなくなる
> 
> (1) の対処として、sendRedirectメソッドを使用するとしていたのですが
> その後(2)の対処で、(1)の問題も解決しておりました。
> 
> パッチを適用しない状態の FPSP では、(1)の事象が発生すると思います。
> 
> 
>> SPに送信されない属性を条件に使うことは原理的に難しいのでしょうか?
>> (Shibbolethの内部構造はよくわかっていないのだけれどもなんとなく難しそ
> うな気がします)
> この観点で調べたことがないため、申し訳ありませんが私にはわかりません。
> 
> 
> 以上、よろしくお願い致します。
> 
> 
> (2014年03月24日 16:06), Tatsumi Hosokawa wrote:
>> オープンソース・ソリューション・テクノロジ 相本様
>>
>> 慶應義塾ITC本部の細川です。
>>
>> 試しに、doError()を使うようにパッチを書き換えてみたのですが(パッチを添付します)、
>> なんと、当方の目的として全く問題ない動作をしてしまいました。
>>
>> 1. FPSPで禁止されたサイトへのアクセス
>> → エラーメッセージ付きのエラー画面が出てアクセス出来ない
>>
>> 2. FPSPで許可されたサイトへのアクセス
>> → uApprove.jpの画面が表示され、承認後にアクセスできる
>>
>> 3. FPSPが設定されていないサイトへのアクセス
>> → uApprove.jpの画面が表示され、承認後にアクセスできる
>>
>> となってしまい、非常にハッピーなのですが、何か私が勘違いをしているのでしょうか?
>>
>> 一方、よく読むと
>> https://meatwiki.nii.ac.jp/confluence/pages/viewpage.action?pageId=12158554
>> の下の方にも中で書いてありますが、
>>
>> 「注意3:条件に使用できる Attribute は当該SPに送信されるもの
>> (つまり attribute-filter.xml 等でフィルタされていないもの)に限ります」
>>
>> というのはなかなか厳しい制限ですね。
>> 実は一番使いたいのは、SPに送信されない属性でのFPSP制限なのですが…。
>>
>> まあ、該当属性を不必要でも送ってしまうというのもアリとは思うのですが、
>> それも属性によりますからね…。
>>
>> # 今回判断条件に使いたいAffiliation程度なら考え方としてアリかとも思うのですが、
>> # gakuninScopedPersonalUniqueCodeとかだといくら何でも無理ですよね。便利そうですが。
>>
>> SPに送信されない属性を条件に使うことは原理的に難しいのでしょうか?
>> (Shibbolethの内部構造はよくわかっていないのだけれどもなんとなく難しそうな気がします)
>>
>> 細川
>>
>> (2014/03/24 14:31), AIMOTO Norihito wrote:
>>> 慶應義塾ITC本部 細川さま
>>>
>>> お世話になっております。
>>> オープンソース・ソリューション・テクノロジ 相本です。
>>>
>>>> 該当の処理を行っていたdoError()の代わりに
>>> httpServletResponse.sendRedirect()になっているので、
>>>> その通りに動作しているのだと思いますが、これは何か理由があるのでしょうか?
>>> 申し訳ないです、本事象とは別件の部分まで含めてしまいました。
>>> sendRedirect()を呼び出している理由は下記のとおりです。
>>>
>>> uApprove.jp と一緒に使用している場合に限りますが
>>> doError() ではforwardメソッドのため uApprove.jp も動作します。
>>> ユーザーの画面遷移として、Shibboleht IdP ログイン → 属性送信同意 →
>>> エラー画面 となり、ユーザーに不親切です。
>>> そのために sendRedirectメソッドとして FPSP 動作時は
>>> Shibboleht IdP ログイン → エラー画面 と遷移する目的でこのようにしています。
>>>
>>> 以上、よろしくお願い致します。
>>>
>>>
>>>
>>> (2014年03月24日 13:11), Tatsumi Hosokawa wrote:
>>>> オープンソース・ソリューション・テクノロジ 相本様
>>>>
>>>> 慶應義塾ITC本部の細川です。
>>>>
>>>> 貴重な情報有り難うございます。パッチを適用してみたところ、問題なくログインが可能となりました。
>>>>
>>>> ところで一方、送信拒否時のerror.jspの呼び出しでエラー原因が表示されなくなってしまいました。
>>>>
>>>> 該当の処理を行っていたdoError()の代わりにhttpServletResponse.sendRedirect()になっているので、
>>>> その通りに動作しているのだと思いますが、これは何か理由があるのでしょうか?
>>>>
>>>> # たとえば、単にHttpServletHelper.unbindLoginContext()の後に、
>>>> # doError()を呼び出したりするわけにはいかないのでしょうか?
>>>>
>>>> よろしくお願いします。
>>>>
>>>> 細川
>>>>
>>>> (2014/03/24 11:52), AIMOTO Norihito wrote:
>>>>> オープンソース・ソリューション・テクノロジ 相本 と申します。
>>>>>
>>>>> これは FPSP のバグだと考えています。
>>>>>
>>>>> 【原因】
>>>>> filter条件が、/profile/* ですがこれは各SPからのSAML Request時にも動作し
>>>>> ます。
>>>>> このとき、SPのEntityIDなどを保持しているセッション(_idp_authn_lc_key)が
>>>>> 前回の
>>>>> アクセス時のまま残っているため、以前のSPへのEntityIDへのアクセスとして
>>>>> FPSPが判定してしまいます。
>>>>>
>>>>> 【対策】
>>>>> FPSPで"拒否"した際に_idp_authn_lc_keyを破棄することで事象を解消できます。
>>>>> 下記のようなコードを入れることで本事象を解消できることを確認しました。
>>>>>                HttpServletHelper.unbindLoginContext(
>>>>>                    HttpServletHelper.getStorageService(m_servletContext),
>>>>> m_servletContext, httpServletRequest, httpServletResponse);
>>>>>
>>>>> 【補足】
>>>>> 私が確認した限りですが、本来拒否されなければならないユーザーが許可となる
>>>>> という事象は発生しません。
>>>>> 認証済みの状態でも、「(1) /idp/profile/SAML2/Redirect/SSO(SAMLリクエス
>>>>> ト)」 → 「(2) /idp/AuthnEngine」 → 「(3) /idp/profile/SAML2/Redirect
>>>>> /SSO(SAMLレスポンス)」と
>>>>> 遷移し、(1)のfilter(FPSP)では以前のEntityIDで判定されますが、
>>>>> このアクセスでSAMLリクエストを解析された結果がセッション
>>>>> (_idp_authn_lc_key)に入り再発行されるため
>>>>> (3)のアクセス時には(1)のSAMLリクエストの内容でFPSPは判定します。
>>>>> よって「前回が許可」、「今回か拒否」のパターンでは
>>>>> 前回の内容で判定されることはありませんでした。
>>>>>
>>>>>
>>>>> この事象とは別に FPSP を利用していて、もう1件バグと思われる事象が
>>>>> ありましたので合わせて報告します。
>>>>>
>>>>> 【事象】
>>>>> FPSPで定義されたいるSPにアクセスして、Shibboleth IdPのログイン画面を表示後
>>>>> Shibboleth IdPにログインしなかった場合、以降どのSPでもFPSPで拒否となる。
>>>>>
>>>>> 【再現手順】
>>>>> あるSPへアクセスし、Shibboleth IdPのログイン画面が表示された後
>>>>> ログインせずに別のSPへアクセスし、ログインを試みようとするもFPSPで拒否さ
>>>>> れる。
>>>>>
>>>>> 【原因】
>>>>> Shibboleth IdPにログインされていない状態でも FPSP が動作してしまう。
>>>>>
>>>>> 【対策】
>>>>> FPSPはShibboleth IdPに未ログイン状態では動作しないようにします。
>>>>> 下記のようなコードを入れることで本事象を解消できることを確認しました。
>>>>>         if (!loginCtx.isPrincipalAuthenticated()) {
>>>>>             // まだログインしていない場合はログイン処理へ
>>>>>             filterChain.doFilter(servletRequest, servletResponse);
>>>>>             return;
>>>>>         }
>>>>>
>>>>> この2件に関してのパッチを添付致します。
>>>>> 参考にしていただければと思います。
>>>>>
>>>>> 以上、よろしくお願い致します。
>>>>>
>>>>>
>>>>> (2014年03月24日 10:22), Tatsumi Hosokawa wrote:
>>>>>> 慶應義塾ITC本部の細川です。
>>>>>>
>>>>>> 現在、
>>>>>>
>>>>>> https://meatwiki.nii.ac.jp/confluence/pages/viewpage.action?pageId=12158554
>>>>>>
>>>>>> のFilter Per SP (FPSP)をテストしており、一応動作はするようになったのですが、
>>>>>> これで属性送信を一旦拒否された場合、それ以降その他のSPにSSOする際も、
>>>>>> 全て拒否されるようになってしまっています。
>>>>>>
>>>>>> ブラウザを再起動すればまた他サービスにはログインできるのですが、
>>>>>> これはそのような仕様なのでしょうか?
>>>>>>
>>>>>> 現在のSampleFilterPerSP_allow.xmlの内容は、
>>>>>>
>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>> <!DOCTYPE EntitiesDescriptor [
>>>>>>        <!ELEMENT EntitiesDescriptor (EntityDescriptor+)>
>>>>>>        <!ELEMENT EntityDescriptor   (Attribute+)>
>>>>>>        <!ELEMENT Attribute          (#PCDATA)>
>>>>>>
>>>>>>        <!ATTLIST EntityDescriptor   entityID    CDATA #REQUIRED>
>>>>>>        <!ATTLIST Attribute          attributeID CDATA #REQUIRED>
>>>>>> ]>
>>>>>>
>>>>>> <EntitiesDescriptor>
>>>>>>      <EntityDescriptor entityID="https://testsp1.itc.keio.ac.jp/shibboleth-sp">
>>>>>>        <Attribute attributeID="eduPersonAffiliation">
>>>>>>           student
>>>>>>        </Attribute>
>>>>>>      </EntityDescriptor>
>>>>>> </EntitiesDescriptor>
>>>>>>
>>>>>> となっており、 https://testsp1.itc.keio.ac.jp/ へのログインは、
>>>>>> 私のeduPersonAffiliationがstaff;memberなので拒絶されます。
>>>>>>
>>>>>> ここまではいいのですが、その後他のSPに接続する際も、
>>>>>>
>>>>>> Deny you(xxxxxxxx@xxxxxxxxxx) login to Service Provider https://testsp1.itc.keio.ac.jp/shibboleth-sp
>>>>>>
>>>>>> のメッセージがブラウザに表示され、拒絶されてしまいます。
>>>>>> ここで、testsp1.itc.keio.ac.jpにアクセスする前であれば、
>>>>>> 他のサービスにも問題なくログインできます。
>>>>>>
>>>>>>
>>>>>> idp-process.logには何も表示されないのですが、catalina.outには次のようなエラーが出ます。
>>>>>>
>>>>>> 1. まず最初に https://testsp1.itc.keio.ac.jp にアクセスした時
>>>>>>
>>>>>> SampleFilterPerSP spEntityId = https://testsp1.itc.keio.ac.jp/shibboleth-sp
>>>>>> SampleFilterPerSP don't match any attributes.
>>>>>> SampleFilterPerSP   eduPersonAffiliation=member
>>>>>> SampleFilterPerSP   eduPersonAffiliation=staff
>>>>>> SampleFilterPerSP   eduPersonPrincipalName=xxxxxxxxxxx@xxxxxxxxxx
>>>>>> SampleFilterPerSP   transientId=xxxxxxxxxxxx
>>>>>>
>>>>>> 2. その後 https://security-learning.nii.ac.jp にアクセスした時
>>>>>>
>>>>>> SampleFilterPerSP spEntityId = https://testsp1.itc.keio.ac.jp/shibboleth-sp
>>>>>> SampleFilterPerSP don't match any attributes.
>>>>>> SampleFilterPerSP   eduPersonAffiliation=member
>>>>>> SampleFilterPerSP   eduPersonAffiliation=staff
>>>>>> SampleFilterPerSP   eduPersonPrincipalName=xxxxxxxxxxx@xxxxxxxxxx
>>>>>> SampleFilterPerSP   transientId=xxxxxxxxxxxx
>>>>>>
>>>>>> 3. ブラウザを再起動して https://security-learning.nii.ac.jp にアクセスした時(問題なくログインできます)
>>>>>> SampleFilterPerSP spEntityId = https://security-learning.nii.ac.jp/shibboleth-sp
>>>>>> SampleFilterPerSP spEntityId = https://security-learning.nii.ac.jp/shibboleth-sp
>>>>>>
>>>>>>
>>>>>> 1,2のエラーは全く同一です。このような状況なのですが、どなたかFPSPを利用されている方、
>>>>>> これが異常な動作なのかどうか教えていただけますでしょうか?
>>>>>>
>>>>>> よろしくお願いします。
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 
> 


-- 
慶應義塾ITC本部  細川達己  xxxxxxxx@xxxxxxxxxxxxxx
Tel. 03-5427-1685  Fax. 03-5427-1722