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

[upki-fed:00340] Re: SPのタイムアウトについての質問

西村です。

返答が遅くなりすみません。

> いただきました情報を参照していますと、
> maximumSPSessionLifetimeを0にすればSP側の
> タイムアウト値のみを見るということではないのでしょうか？
> （0だとうまく動作しないと書いてある感じですが、もし改善
> されているのであれば。）

はい。もしくはmaximumSPSessionLifetime自体を削ると所望の動作になります。

> また、AuthenticationDurationが関係してたりするのでしょうか？

これはIdP 2.0.xの場合のみだと思います。

また、SPにてDEBUGレベルでログを出していれば、取得したSAMLアサーションが
<saml2:AuthnStatement AuthnInstant="2011-04-28T0:21:36.191Z" ...
のような形で記録されていると思いますので、この中にSessionNotOnOrAfter属性
があるかどうかで判断することもできます。

>> 解決策でなくてアレなのですが、タイムアウト前再認証されるときに件の
>> "Destroyed session ..."はログに残ってますでしょうか？>  松平さん
> 
> このログにつきましては、出ていませんでした。
> SPのログアウトURLを読んだ場合には上記ログは出力されていました。
> https://idp.server/Shibboleth.sso/Logout

そうですか…
当該ログにセッションIDが記録されていると思いますが、そのIDでshibd.log
およびnative.logを検索すると、セッションの生成から消滅までを追うことが
できると思いますので、やってみることをお勧めします。特に
updated expiration of valid records in context (<ID>) to (1303979981)
のような行があればそれがタイムアウトの延長を表しますので、タイムアウトが
延長されているかどうか、いつまで延長されているか（最後の数字が時刻を表し
ます）を確認してみると良いと思います。

native.logがどこにあるか分からない/記録されないという場合はお知らせください。


(2011/04/18 14:57), Takuya Matsuhira wrote:
> NII 西村先生
> 
> お世話になっております。
> 金沢大学総合メディア基盤センター　松平です。
> 
> 返答が遅くなり、申し訳ありません。
> 
> 色々と情報をいただき、ありがとうございます。
> 非常に参考になります。
> 
> いただきました情報を参照していますと、
> maximumSPSessionLifetimeを0にすればSP側の
> タイムアウト値のみを見るということではないのでしょうか？
> （0だとうまく動作しないと書いてある感じですが、もし改善
> されているのであれば。）
> また、AuthenticationDurationが関係してたりするのでしょうか？
> 
> 
>> 解決策でなくてアレなのですが、タイムアウト前再認証されるときに件の
>> "Destroyed session ..."はログに残ってますでしょうか？>  松平さん
> 
> このログにつきましては、出ていませんでした。
> SPのログアウトURLを読んだ場合には上記ログは出力されていました。
> https://idp.server/Shibboleth.sso/Logout
> 
>> 私も同感で、何かやっている途中に再認証は勘弁してほしいので、アプリケーションが
>> 独自のセッションを持つ方がよいと思います。純粋にログイン操作（ID/パスワード入力）の
>> 部分だけをShibboleth SPに肩代わりさせるイメージですね。
>> そういう意味で、shibdのセッションはこれくらい厳しくてちょうど良いのかもしれません。
> 
> 上記の実現方法、サイボウズガルーン３でも実現できる術はありますで
> しょうか？
> 私が考える範囲では、難しいかなと思っているのですが、もし実現でき
> そうでしたらご教授いただけましたら助かります。
> （パッケージ製品の多くは上記方法での実現は厳しいと思いますので、
> 方法があると大変ありがたいです。）
> 
> 一貫性のないメールで恐縮ですが、よろしくお願いいたします。
> 
> 
> 
> (2011/04/14 19:56), Takeshi NISHIMURA wrote:
>> 西村です。
>>
>> 秋山先生からのメールがupki-fed MLに届いていないようなのですが（ML側の
>> 設定の問題でしょうか？）それはともかくとして、
>>
>>>>>> という記述があり，IdP の発行した Assertion の session Expiration と SP のExpiration
>>>>>> の短い方が採用されるように見えます．
>>
>> 「IdPの発行したAssertionのsession Expiration」というのは
>> AuthnStatementのSessionNotOnOrAfter属性のことかと思いますが、
>> （saml-schema-assertion-2.0.xsd参照）
>> Shibboleth IdPについて言えば、明示的に指定されていなければ送られることは
>> ないようです。
>>
>> Shibboleth IdP側で該当するのは
>> https://bugs.internet2.edu/jira/browse/SIDP-165
>> で、2008-04-18に
>> http://svn.middleware.georgetown.edu/view/java-idp/branches/REL_2/src/main/java/edu/internet2/middleware/shibboleth/idp/profile/saml2/SSOProfileHandler.java?r1=2724&r2=2728&pathrev=2728
>> のような形で取り込まれており、
>> 2.1.3のリリースが2009-08-21であったことから多くのShibboleth IdPが
>> これに該当するかと思います。
>>
>> "[Shib-Users] SP 2.0 session timeout issue..."
>> http://groups.google.com/group/shibboleth-users/browse_thread/thread/ead5af508e51b87f
>> によれば2.1からこの方式になっていて、maximumSPSessionLifetimeを
>> 指定することで明示することができるようです。
>>
>> 解決策でなくてアレなのですが、タイムアウト前再認証されるときに件の
>> "Destroyed session ..."はログに残ってますでしょうか？>   松平さん
>>
>>>> のようなmod_shibでアクセス制限するパスを用意して，認証成功したらアプリケーション側でセッションを生成する，制限したパスにアクセスするのはアプリケーション側でセッションが切れた時だけ，というアプローチが一番妥当な気がします．
>>
>> 私も同感で、何かやっている途中に再認証は勘弁してほしいので、アプリケーションが
>> 独自のセッションを持つ方がよいと思います。純粋にログイン操作（ID/パスワード入力）の
>> 部分だけをShibboleth SPに肩代わりさせるイメージですね。
>> そういう意味で、shibdのセッションはこれくらい厳しくてちょうど良いのかもしれません。
>>
>> ただそうしちゃうと、shibdのセッションが形骸化してIdPからの強制が効かないのでSLO
>> で問題が出るかもしれませんが、それはSLOをサポートするときに考えることにします。^^;
>>
>> On 2011/04/13, at 15:20, Takuya Matsuhira wrote:
>>
>>> 京都産業大学　秋山先生
>>>
>>> お世話になっております。
>>> 金沢大学総合メディア基盤センター　松平です。
>>>
>>> コメント、ありがとうございます。
>>> 色々、参考になります。
>>>
>>>> 今のところは，
>>>>
>>>> https://sp.hoge.jp/application/auth_path
>>>>
>>>> のようなmod_shibでアクセス制限するパスを用意して，認証成功したらアプリ
>>> ケーション側でセッションを生成する，制限したパスにアクセスするのはアプリ
>>> ケーション側でセッションが切れた時だけ，というアプローチが一番妥当な気が
>>> します．
>>>> # ただ，その場合静的コンテンツへのアクセス制御ができないのが辛いところ
>>> ですね．．．
>>>
>>> はい。こちらも、PHPなどで実装しているアプリを使用しているSPについては、
>>> アプリ側で独自セッションを生成することで対応しています。
>>>
>>> しかし、今セッション時間を延ばしたいと思っているのが、
>>> サイボウズガルーン３なのですが、サイボウズはすべて、
>>> grn.exeを使うので、上記方法では難しく、Shibboleth側で設定できないか
>>> というのが今回の趣旨です。
>>>
>>> サイボウズは、1日を通して使うが、かかりっきりではないので、
>>> 毎回接続が切れるということで、利用者からの不満が大きいです。。
>>>
>>>
>>> (2011/04/13 14:47), Toyokazu Akiyama wrote:
>>>> 金沢大学　松平先生
>>>>
>>>> 京産大の秋山です．
>>>>
>>>> おっしゃるとおり，SP側に設定権があってもよいような気がします．
>>>> ただ，同じくおっしゃられるとおり，IdP側にも制御の機能は欲しい気がします．
>>>> # 自分たちが実施した認証の有効性を保障する期間なので，下手に長くするのは無責任という見方もありそうです．
>>>>
>>>> 以前 OpenSSO というプロダクトを触っていた時には，バックチャネルでのセッションの延長機能というのがあって，ユーザのアクセスがある限りIdP側でセッションが延長されるという機能がありました．ただ，実装するのは複雑になりすぎる気もします．
>>>>
>>>> 今のところは，
>>>>
>>>> https://sp.hoge.jp/application/auth_path
>>>>
>>>> のようなmod_shibでアクセス制限するパスを用意して，認証成功したらアプリケーション側でセッションを生成する，制限したパスにアクセスするのはアプリケーション側でセッションが切れた時だけ，というアプローチが一番妥当な気がします．
>>>> # ただ，その場合静的コンテンツへのアクセス制御ができないのが辛いところですね．．．
>>>>
>>>> 2011年4月13日12:17 Takuya Matsuhira<xxxxxxx@xxxxxxxxxxxxxxxxxxxxxxxx>:
>>>>> 京都産業大学　秋山先生
>>>>>
>>>>> お世話になっております。
>>>>> 金沢大学総合メディア基盤センター　松平です。
>>>>>
>>>>> コメントありがとうございます。
>>>>> ソースまで確認していただき、ありがとうございます。
>>>>>
>>>>> なるほど、IdPとSPの両方のうち、短いほうを採用するのですね。
>>>>>
>>>>> とすれば、SP側で2時間はセッションを保持したいと思っても、
>>>>> ユーザが利用したIdPが15分でセッションを破棄する設定に
>>>>> なっていたら、15分で切れてしまうということですね。
>>>>>
>>>>> なんとなくですが、一般的に、セッションの維持を決めるのは
>>>>> サービスを提供しているSPのような気もしますが、どうなんでしょう？
>>>>>
>>>>> 認証を任されたIdPが取り仕切るというのもなんとなくわかりますが。。
>>>>>
>>>>> (2011/04/13 10:54), Toyokazu Akiyama wrote:
>>>>>> 京産大の秋山です．
>>>>>>
>>>>>> 横やりですいません．
>>>>>> svn の SP のコードで lifetime を grep 検索すると，
>>>>>>
>>>>>> cpp-sp/trunk/shibsp/handler/impl/SAML2Consumer.cpp
>>>>>>
>>>>>>        // Session expiration for SAML 2.0 is jointly IdP- and SP-driven.
>>>>>>        time_t sessionExp = ssoStatement->getSessionNotOnOrAfter() ?
>>>>>> ssoStatement->getSessionNotOnOrAfterEpoch() : 0;
>>>>>>        pair<bool,unsigned int>     lifetime = sessionProps ?
>>>>>> sessionProps->getUnsignedInt("lifetime") : pair<bool,unsigned
>>>>>> int>(true,28800);
>>>>>>        if (!lifetime.first || lifetime.second == 0)
>>>>>>            lifetime.second = 28800;
>>>>>>        if (sessionExp == 0)
>>>>>>            sessionExp = now + lifetime.second;     // IdP says nothing,
>>>>>> calulate based on SP.
>>>>>>        else
>>>>>>            sessionExp = min(sessionExp, now + lifetime.second);    // Use
>>>>>> the lowest.
>>>>>>
>>>>>> という記述があり，IdP の発行した Assertion の session Expiration と SP のExpiration
>>>>>> の短い方が採用されるように見えます．
>>>>>>
>>>>>> 2011年4月13日8:55 Takuya Matsuhira<xxxxxxx@xxxxxxxxxxxxxxxxxxxxxxxx>:
>>>>>>> 西村先生
>>>>>>>
>>>>>>> お世話になっております。
>>>>>>> 金沢大学総合メディア基盤センター　松平です。
>>>>>>>
>>>>>>> ご多忙のところ、ご返答ありがとうございます。
>>>>>>>
>>>>>>> IPアドレスの変更に伴い、セッションが破棄され、
>>>>>>> 再認証が要求されるということですね。
>>>>>>> ＃Webプロキシを複数台かますとだめな感じですかね。
>>>>>>>
>>>>>>> ただ、我々の環境は固定IPでおこなっており、
>>>>>>> 今回ご提示いただきましたケースとは異なるのかと
>>>>>>> 考えております。
>>>>>>>
>>>>>>> SPのCookieが無効にならない限りは、IdPへの問い合わせは
>>>>>>> 発生しないという前提で質問を投げさせていただいていますが、
>>>>>>> SPから発行されるCookie情報にはIdPのタイムアウト時間を
>>>>>>> 越えないなどといった情報は加味されていたりするのでしょうか？
>>>>>>>
>>>>>>>
>>>>>>> (2011/04/11 14:56), Takeshi NISHIMURA wrote:
>>>>>>>> 西村です。
>>>>>>>>
>>>>>>>> 実際にタイムアウトを計測したことはないのですが、明らかにタイムアウト前に
>>>>>>>> 再認証を求められたことがあります。このケースにあてはまらないかもしれませ
>>>>>>>> んが参考までに書きます。
>>>>>>>>
>>>>>>>> SPはデフォルトでは認証されたクライアントIPアドレスを保存していて、IPアド
>>>>>>>> レスが変わると不正としてセッションを破棄してしまいます。DHCPでころころIP
>>>>>>>> アドレスが変わる場合や、FWを経由していて割り当てられるIPアドレスがころころ
>>>>>>>> 変わる場合には、正当なアクセスが不正なものとみなされる場合があります。
>>>>>>>> # 先日のシンポジウムのデモでこの現象が頻発し、回避策を施すのに苦労しました。
>>>>>>>>
>>>>>>>> 上記のようにcookie盗用による不正利用を防ぐための機能なのですが、
>>>>>>>> この機能を無効にするには、同じくSessionsに書く属性でconsistentAddress="false"
>>>>>>>> のように書けばよいです。
>>>>>>>> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions
>>>>>>>>
>>>>>>>> ちなみに、認証要求時と認証応答時のクライアントIPアドレスが変化していない
>>>>>>>> ことをチェックするのはcheckAddress="true"です。
>>>>>>>>
>>>>>>>> なお、上記のセッション破棄が起きた際はtransaction.logに
>>>>>>>> 2011-03-10 12:54:00 INFO Shibboleth-TRANSACTION [6]: Destroyed session (applicat
>>>>>>>> ionId: default) (ID: _xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)
>>>>>>>> のように記録されるので確認できます。
>>>>>>>>
>>>>>>>> On 2011/04/11, at 13:42, Takuya Matsuhira wrote:
>>>>>>>>
>>>>>>>>> メーリングリスト参加者の皆様
>>>>>>>>>
>>>>>>>>> お世話になっております。
>>>>>>>>> 金沢大学総合メディア基盤センター　松平です。
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Shibboleth SPのタイムアウト設定について
>>>>>>>>> 質問があります。
>>>>>>>>>
>>>>>>>>> 運用を行っていると、SPによっては、タイムアウトを
>>>>>>>>> 15分にしたり、2時間にしたりなど、いろいろなケースが
>>>>>>>>> あるかと思います。
>>>>>>>>>
>>>>>>>>> SPにおける、タイムアウト時間の調整は
>>>>>>>>>
>>>>>>>>> Shibboleth2.xml内
>>>>>>>>> -------
>>>>>>>>> <Sessions lifetime="7200" timeout="7200" checkAddress="false"
>>>>>>>>>                handlerURL="/Shibboleth.sso" handlerSSL="false"
>>>>>>>>> relayState="ss:mem"
>>>>>>>>>
>>>>>>>>> exportLocation="http://localhost/Shibboleth.sso/GetAssertion"
>>>>>>>>> exportACL="127.0.0.1"
>>>>>>>>>                idpHistory="false" idpHistoryDays="7">
>>>>>>>>> -------
>>>>>>>>>
>>>>>>>>> のlifetime、timeoutの値を変えることで、
>>>>>>>>> できると思っていたのですが、どうも指定した
>>>>>>>>> 時間に達する前に再度認証に向かってしまいます。
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> また、一般的には、以下の動作になるかと思います。
>>>>>>>>>
>>>>>>>>> SPにアクセス
>>>>>>>>> ↓
>>>>>>>>> 当該SPの認証済みCookie(_shib_session)がない
>>>>>>>>> ↓
>>>>>>>>> IdPにリダイレクト
>>>>>>>>> ↓
>>>>>>>>> 認証
>>>>>>>>> ↓
>>>>>>>>> Cookieがセットされ、SPのコンテンツを表示
>>>>>>>>> ↓
>>>>>>>>> 当該SPの別コンテンツを選択
>>>>>>>>> ↓
>>>>>>>>> 当該SPのCookie(_shib_session)がある（lifetime、timeout時間内）
>>>>>>>>> ↓
>>>>>>>>> SPのコンテンツを表示
>>>>>>>>> ↓
>>>>>>>>> 当該SPのCookie(_shib_session)があるが、lifetime、timeout時間外
>>>>>>>>> ↓
>>>>>>>>> IdPへ問い合わせ
>>>>>>>>> ↓
>>>>>>>>> idp_sessionが有効かどうかをチェック
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> SPのlifetimeとtimeoutの時間がオーバーしない限り、_shib_session
>>>>>>>>> は有効で、IdPに問い合わせなくても、SP内で解決できると考えて
>>>>>>>>> いるのですが、どうでしょうか？
>>>>>>>>>
>>>>>>>>> ご多忙のところ、大変申し訳ございませんが、
>>>>>>>>> SPに応じてタイムアウト時間を変更する方法をご存知の方、
>>>>>>>>> ご教授いただけましたら幸いです。

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