開発基盤部会 Blog

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

2019/07/19

話題になったIdP/Stsの実装パターン、ASP.NET Identityが結構、参考になる。

Tweet ThisSend to Facebook | by nishino
 先日から話題の某Pay、「誰でもパスワードがリセットできる状態だった」、「二段階認証がなかった」、「認証連携に脆弱性があった」、「WebAPIで顧客データベースにフリーでアクセスできる状況に近かった」...等々、色々な憶測が飛び交っていますが、いずれにせよ、指摘されている問題を見ると、IdP/Stsの基礎的な実装パターンから逸脱していたのではないか?と言う感想です。
  • IdP : Identity Provider
  • StS : Security Token Service

 ...なんて事を書いていたら、信憑性は不明ですが、若干、結論っポイ情報が飛び込んできました。


 コレを真に受けると、... { "id" : "xxxxx", extIdSiteCd"" : "0n" } をRedirectエンドポイント的な何かにインジェクションすれば「通ってしまう」的な話のようですが、これ、OAuth2 / OIDCの仕様ではないですよね。

 ... 話を元に戻して、何れにせよ、このIdP/Sts実装パターンを学ぶのに、ASP.NET Identityが結構、参考になると思います(実際、私が、ソコから認証界隈に入門したので)。

<参考>


 ...で、実際にASP.NET Identityを評価したかったら、Visual Studioで[新規作成] -> [プロジェクト]して、そこから、更に、拡張のテンプレートをインストールするだけで、かなり簡単に動かすことが出来ます。

<参考>


 こう言うのをリリースしているマイクロソフト、私、マイクロソフト信者じゃないですが、すごくイイと思います。

 因みに、話題の二要素認証(2FA)ですが、ASP.NET Identityにも、既定で、この「2FA」が実装されています。.NET Framework版では、メールとSMSを使用した2FAのみですが、.NET Core版では、これに、ワンタイム・パスワード(TOTP)を使用した2FAが追加されています。

 識者の中には、「周回遅れで2FAに、メール、SMS、OTP?」と言う方もいて、恐らくWebAuthnなどの導入を想定されているのだと思いますが、WebAuthnを採用した場合、デバイスをロストした場合のリカバリ等も色々検討が必要で、現場が、このレベルの事が出来ていないのに、先に行き過ぎな感じもします。

 と言うのも、GoogleアカウントやMicrosoftアカウントでもSMS の 2FAは、まだ残っていますし、know や are (≒ tpm) をロストするからリカバリに have のメール、SMSを使う ... となるとメアドとTEL番号以外になんかイイのあるっけ?なんて思ったり。

 ...で、Sts(OAuth2、OIDC、FAPI)ですが、ASP.NET Identityの拡張である「OAuth Authorization Server Middleware」にはOAuth2の基本4フローの範囲の実装しかされていません。また、.NET Core版はOIDCまでサポートがあるようですが、OIDCの仕様の大きさを考えると、フルスペックのサポートではないと思われます。

 そう言う事で、OAuth2拡張、OIDC、FAPI対応させようとした場合、Middlewearである事もあり、拡張実装が難しいため、某弊「汎用認証サイト」では、以前書いたように、脱「OAuth Authorization Server Middleware」してスクラッチ実装に切り替えています。

 ...が、OAuth2の基本を学ぶのには、これらのMiddlewearから入門して良かったと思います。そして、そこからスクラッチ実装に切り替え、最新の拡張仕様の理解 / 設計 / 実装を行う事で、現在、更なる認証界隈の難しさを味わっている最中です。

 「日本は床の間に生け花を飾る。欧米ではショーウィンドーに花を飾る。」みたいな話をもあるので、日式はこういうの(ASP.NET Identityのようなモノ)を見習った方がイイのかもしれません。確かに、日本は過当競争下という環境要因もある気がしますが、OSSのコントリビューション(貢献)も少ないですよね。と言う事で、何気にプロモーションなんですが、私がOSSとして作成しているIdP/STSである「汎用認証サイト」のリンクも以下に貼っておきます

<参考>




余談:
 なんでこんな(設計 / 実装 / テスト @ QA的な意味で)漏れ方するの?と言う点が興味深くもあるのですが、色々、情報収集をしていると、平たく言って、「プロフィットを追い求め過ぎて、必要なベネフィットを提供出来ない問題。」と言うのが根底にあるようにも思います。

  • 日式的、産業的ソフトウェア開発により世間には、「項目移送おじさん」エンジニアしかおらんので、「全然わからない 俺たちは雰囲気で認証をやっている」的な感じになっているとか、
  • ボーイング737MAX墜落の欠陥ソフトウエアは、
    大学を出たばかりの臨時社員が開発を行っていたとか、
  • イギリス史上最悪の360億円宝石盗難事件のビル警備員曰く
    「それ以上詳しく調べる程の給料は貰っていない。」とか、

 確かに、バイトと同じレベルだと責任感は持ち難いし、法的にも、職務上の義務違反とか、そう言う事にもならないですよね。そして、バイト先を変える事は転職にもならんし。

 なので、簡単に言うと、給料によって作業範囲記述書(SOW)、契約(責任と義務)が変わるので、品質レベルも変わり、コストだと言って削り過ぎてしまうと、ソコに人を配置した。ぐらいの品質しか期待できなくなるのでしょうね。

<参考>


 ...そう言えば、以前、「日式エッスアイはスペシャリスト育成にホント失敗しているのでは?」なんて言う、関連の有りそうな投稿を行っていたことに気が付きました。昨今の「働き方改革」などのドレンドも考慮すると、原価に対して、経営がパワープレイをしちゃうと、ゴーイング・コンサーンしないってことじゃないですかね?
09:00 | 投票する | 投票数(0) | コメント(0) | ご報告