こんにちは、富士榮です。
先日、「外部IdP利用時にRP側"でも"多要素認証を行うべきか」というポストをしました。
結局は”Relying Party”というくらいなのでIdentity Providerに依存する存在にはなるのですが、単に「認証機能を作るのが面倒くさいので外部IdPを使えば運用面・コスト面で楽になるよね」という文脈で語られることも多いのではないかと思います。
前回はacr/amrというツールの観点で少しだけ話をしましたが、本質的にRelying Partyは何をIdentity Providerに”頼って”いるのだろうか・・・ということを考えていく必要があるのではないかと思います。
今日はそんな話です。
Relying Partyとは何なのか？
まず、Relying Partyの定義を見ていきましょう。いつものISO 24760-1:2019のTerminologyを見るとこのように書かれています。
System that relies on other party (identity provider) to provide identity information. Relying party (also known as "service provider") usually relies on identity provider to authenticate the user, and relay the information to the relying party. Relying party has no access to credentials (e.g. passwords), it only knows that the authentication was successful. Identity provider may transfer identity attributes and additional information (such as authorization decisions) to the relying party. Relying party usually has a trust relationship with identity provider.
ID 情報の提供を他者（ID プロバイダ）に依存するシステム。依拠当事者（「サービス・プロバイダ」とも呼ばれる）は通常、ID プロバイダがユー ザを認証し、その情報を依拠当事者に中継することに依存している。依拠当事者はクレデンシャル（パスワードなど）にはアクセスできず、 認証が成功したことだけを知っている。ID プロバイダは、ID 属性と追加情報（認可決定など）を依拠当事者に転送する。依拠当事者は通常、ID プロバイダと信頼関係を持つ。（Deeplで機械翻訳）
これを見ると、
- ユーザ認証の結果
- ID属性
- 追加情報（認可決定など）
依拠当事者は通常、ID プロバイダと信頼関係を持つ。
「信頼関係」が構築されていることが前提ということですね。
信頼関係とは
もちろん単純にクライアント登録、redirect_uriの登録って話ではありません。それは信頼関係が構築された結果であり、それ登録があるから信頼関係がある、という話ではないわけです。（システム構築だけを見ていて、この辺は勘違いされているケースを多々見てきました・・・）
信頼関係を構築する上ではまずはお互いのことを知ることが必要となります。
RPからIdPを見ると、
- どのようなID情報（属性など）を管理・提供しているのか
- ID情報がどのような精度・鮮度で登録されているのか（いわゆるIAL）
- 登録されたID情報は適切に管理されているのか（運用体制など）
- ユーザ認証はどのような強度で実施されているのか
- サービスレベル（可用性など）はどのようなレベルなのか
- どのような技術仕様（プロトコルなど）をサポートしているのか
が気になる点の一例です。
また、同様にIdPからRPを見ても、
- 提供したID情報を適切に扱われるのか（情報漏洩などへの対策など）
- どのようなサービスに利用されるのか（反社会的勢力はもちろん、提供したID情報を用いて不適切だったり、責任を負いきれないほどの超重要なシステムに使われていたりしないか、など）
- どのような技術仕様（プロトコルなど）をサポートしているのか
- ブランディングを毀損しないかどうか
などが気になります。
信頼「関係」というからには単純に片方向だけでは関係は成立しないわけで、相互に信頼をする必要があります。
また、同様に接続をする断面だけでなく、継続的に信頼し続けるためにはどのくらいのインターバルで何を確認するのか？を確認しておく必要があります。
この辺りを定めたのがトラストフレームワークで、通常は接続するための前提事項や規則などに加えて継続的に誰が何を確認するのか、などの運用についても定義されています。
例えば、国立情報学研究所が定めている学認のフェデレーションに参加する機関に求めるルールが学認技術運用基準として定められています。
https://www.gakunin.jp/document/80
この辺りのトラストフレームワークはOpen Identity Exchange（OIX）が出している「Trust Frameworks for Smart Digital ID」が有名です。
https://openidentityexchange.org/a-guide-to-trust-frameworks-for-smart-digital-id
ソーシャルログインではどうなっているのか
FacebookログインやYahoo! ID連携など広範に使われるソーシャルID基盤ではRPと接続をする都度トラストフレームワークの取り決めをしたり運用の取り決めをするのは不可能に近いので、一般的にRPに開発・接続に関する規約を公開し遵守を求めています。
結果、IdPに非常に優位な状態が出来上がります。。（仕方ありませんが）
例えば、facebookの規約を見てみましょう。
https://www.facebook.com/legal/commercial_terms
4. Limits on Liability: In addition to and without limiting the scope of the “Limits on liability” section in our Terms, you agree that we are not responsible for the actions, services, content, or data of third parties and you release us, our directors, officers, employees, and agents from any claims and damages, known or unknown, arising out of or in any way connected with any claim you have against any such third parties.
4. 責任の制限： 利用規約の「責任の制限」セクションの範囲に加え、またその範囲を制限することなく、利用者は、当社が第三者の行為、サービス、コンテンツ、またはデータに対して責任を負わないことに同意し、利用者がかかる第三者に対して有する請求に起因する、またはかかる請求に何らかの形で関連する、既知または未知のいかなる請求および損害からも、当社、当社の取締役、役員、従業員、および代理人を免除するものとします。
結局何の責任も負いませんよ、と言うことですね。
日本企業はどうでしょうか？Yahoo! JAPANのID連携の規約を見てみましょう。
https://developer.yahoo.co.jp/yconnect/v2/guideline_20220401.html
例えば免責事項の３番目にこのような記載があります。IDに関する属性保証や認証結果に関する保証もないよ、と言うことですね。
利用者が予定している目的への適合性、有用性（有益性）、セキュリティ、権原、非侵害性および正確性等について当社が一切保証しないこと
上記を踏まえてRPはどうするべきなのか
ユースケース次第、としか言えないのですがそれだと思考停止するので、ID保証（IAL）、認証強度（AAL）を含めRP側でもちゃんと考えて対策を打つ必要があるのではないでしょうか？
つまり、何をIdPに頼って、何を頼らないのか、を考えることにもつながるわけですが、上記の通りソーシャルログインについてはほぼ何も保証はされないという前提で考えると、ユーザがRPの提供するサービスへ登録する際のハードルを下げる「離脱防止」という観点での依存を基本ラインとして、IDの保証が必要なサービスであれば追加の属性確認（KYCなど）をRP側でも実装することは考えないといけません。また認証強度が必要なのであれば先日のAuth0の例ではありませんが、RP側でも多要素認証などを個別で実装するなどしないと安全には使えない状態となるはずです。
この辺りは最悪のケース（IdP側のインシデントなど）が発生したとしても、RPが独立性を保った上でサービス提供を継続できるかという観点でサービス設計をしていくことが大切だと思います。
投稿
0 件のコメント:
コメントを投稿