情報 |
---|
本問題を発生させているSameSiteは、eTLD+1(例えばnii.ac.jp)が異なるサイト間で遷移した場合に制約を加えるものです。例えばniijp)が異なるサイト間で遷移した場合に送受信されるcookieに制約を加えるものです。例えばnii.ac.jp内の2サイトでどのような遷移を行ってもcookieの挙動は従来通りです。これに鑑み「クロスサイト」の文言を「クロスドメイン」に改めました。 |
2020年2月4日にリリース予定のGoogle Chrome 80から、cookieの取り扱いに関する挙動が変更になり、この影響で特定の設定のIdP80にて2月17日の週から一部のChromeを皮切りに順次展開されていく予定ですが、cookieの取り扱いに関する挙動が変更になり、この影響で特定の設定のIdP/SPにおいて期待するSSOの挙動を示さない、などの調査結果が示されました。
# 上記の通りですので脆弱性・セキュリティに類する問題ではありません
# また、対処を誤ると古いSafariでここに書いてある以上の問題になることが示されており
# ますので、対策として何か行う場合はご留意ください
...
また、Shibboleth SPの1点目(RelayState)の問題が存在するかどうかについては、shibboleth2.xmlにrelayState="cookie"(文字列の末尾に":数字"が追加されている場合もあります)が含まれるかを確認するほか、SP→IdPもしくは逆の遷移時のRelayStateパラメーターに"cookie"の文字列が含まれるかどうかで確認することも可能です。
テストフェデレーションのIdPをテストする場合、test-sp1で試せるようにAuthnRequestをPOSTするハンドラを追加しました。以下のように(<IDPENTITYID>を自分のIdPのentityIDに変更して)お使いください。
https://test-sp1.gakunin.nii.ac.jp/Shibboleth.sso/SAMESITETEST?target=/secure/&entityID=<IDPENTITYID>
テスト時の注意点:
Chromeの場合はテスト時に限りませんがcookie設定後2分間はPOSTについて従来の挙動を示す(クロスドメインのPOSTでもcookieが送信される, Lax + POST mitigation)との情報があります。テストの際には操作ごとの間隔を空けて実施するようにしてください。Firefoxにはそのような制約はありません。
このChromeの挙動は暫定的なもので、時期は未定ながら無くなるものですので、この挙動に依存した実装は避けてください。
Chromeの上記2分間の特殊性をなくすには、--enable-features=SameSiteDefaultChecksMethodRigorously
オプションを付けて起動してください。Chromeの場合はテスト時に限りませんがcookie設定後2分間は従来の挙動を示す(クロスドメインのPOSTでもcookieが送信される)との情報があります。テストの際には操作ごとの間隔を空けて実施するようにしてください。Firefoxにはそのような制約はありません。
問題があると指摘されているSP:
ML等でIdPからのSSOに支障があったと指摘のあったSPを以下にリストアップします。これらと接続している場合は特にご注意ください。指摘当時問題があっただけで現在は解消されている可能性もあります。
...
以下は「ログインできない」とされているのでサービス自体に問題があると考えられます。IdP側で対処のしようがないと思われます。
ServiceNow(2/5解消したとの情報あり)- Instructure Canvas (2/5一部解消したとの情報あり)
- ChromeのみにSameSiteを付与しているという情報もありますので、テストの際にはご注意ください。
- Rimeto
- University Tickets
- eShipGlobal
- Off Campus Partners
- Cornerstone (2/26追加)
- SameSite=Noneを付与したため古いSafariで動作しなくなったという情報があります
- (LMSのLTI連携関係はダメになりそう)