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

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

慶應義塾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を利用されている方、
>>> これが異常な動作なのかどうか教えていただけますでしょうか？
>>>
>>> よろしくお願いします。
>>>
>>
> 
>