開発基盤部会 Blog

開発基盤部会 Blog >> 記事詳細

2019/06/07

汎用認証サイトにSAML2を大方実装しました(2)

Tweet ThisSend to Facebook | by:nishino
 前回に続く第2回ですが、今回は、OAuth2 / OIDC系とSAML2系の違いについて言及したいと思います(前回言及した、XML vs JSON部分の比較は除く)。

 OAuth2 / OIDC系とSAML2系を比べると、SAML2系は、

  • 仕様の組合せが自由な(≒ プロファイルの縛りが弱い)気がします。
  • 従って、プロダクト間の連携は、個別対応になっていると思われます。
  • XMLライブラリにも互換性の問題が恐らくあるものと思われますが、
    プロダクト間連携が個別対応されているため、連携自体はできている。

 みたいな現状だと思います。

 それで、古くて著名なオープンなSSOプロトコルであるにもかかわらず、SP側へのライブラリ提供が進んでおらず、対応に苦労する。って話なんだと思います。まぁ、雑なSP側に勝手に連携コードを実装されないので、そういう意味でセキュアだ。みたいなことは言えそうですが、

 「クロスドメイン認証が一般化してきて、
そういう時代でもなくなって来たよね。

 みたいな話はあるのかもしれません(現時点では、SP側は、ゲートウェイ等に集約しているし、IdP側は特定プロダクトにロックインされていると思います)。

 あと、SAMLはバージョン2.0のリリース時期が、2005年3月と古くなってきていることもあり、OAuth2 / OIDC系と比べると、フレームワークなどの最新の技術慣行との不一致も出てきている気がします(若しくは、元々、考慮されていない)。私は、以下の点が気になりました。


 ...フレームワークの既定の動作では、ReturnUrlにはPOST転送が出来ないんですよね。なので、Request時のPOST-Bindingは、あまり実装したくないですね。また、今後、Same-Site Cookieとの関連も出て来るかも知れないらしいです(これについては、"response_mode = form_post"も影響があります)。

  • https://twitter.com/ritou/status/1135894689050112000
     あぁ、コレ?(response_mode = form_post +SameSite = Lax)Requestじゃなくて、Responseでもダメなんだな。→ リクエストならIdP側のセッション、レスポンスならRP側のセッションに影響しますね。

 ...色々と、大変そうですが、SAML2系は全体的にプロファイルでの縛りが弱い感じなので、近日、Metadataを実装して、SAML 2.0 Test Service Provider(SP)と、汎用認証サイト(IdP)との連携テストを予定しています。



<参考>


09:00 | 投票する | 投票数(0) | コメント(0) | ご報告