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

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

西村です。

秋山先生からのメールが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