NIST SP 800-63-4のドラフトの主要な変更事項を読み解く全4回の連載、最終回となる第4回目はSP 800-63C「システム間での認証連携（フェデレーション）とその保証レベル」を取り上げます。NIST SP 800-63の概要については第1回全体編をご覧ください。
本連載の関連記事はこちら
【解説】デジタルアイデンティティガイドライン「NIST SP 800-63」第4版ドラフトはどう変わる？＜全体編＞
【解説】デジタルアイデンティティガイドライン「NIST SP 800-63」第4版ドラフトはどう変わる？＜身元確認編＞
【解説】デジタルアイデンティティガイドライン「NIST SP 800-63」第4版ドラフトはどう変わる？＜当人認証編＞
▶「大規模ユーザを管理する顧客ID統合プロジェクト成功の秘訣」をダウンロードする
NIST SP 800-63C 「システム間での認証連携（フェデレーション）とその保証レベル」とは
NIST SP 800-63Cは4つの文書で構成されているNIST SP 800-63のうち、システム間での認証連携について記載されている文書です。認証連携とは、あるシステム（IdP）で認証されたという情報を別のシステム（RP）へ連携する処理を指します。認証連携を利用することでシングルサインオンが実現可能になります。
本文書ではシステム間で認証連携を行うための実装にあたり、IdPとRP間で連携されるアサーション、属性情報の連携の確からしさを保証するための要件が定められています。
フェデレーションにおけるアサーションとはIdPからRPに対して連携される情報であり、認証対象の加入者がIdPでどのような認証処理を行ったかを示す値や、加入者アカウントの持つ属性等の値を含みます。
NIST SP 800-63C-4のドラフトでの章立ての変更点
現行の第3版（NIST SP 800-63C-3）の章立てを踏まえて、第4版ドラフト（NIST SP 800-63C-4 Draft）の章立てを下の表にまとめています。それぞれの版で、類似した内容 は同列に配置しています。また、項目自体が無くなったり追加されたり、項目名が変更されたりした箇所については表に色を付けています。
章レベルでは4章、5章の構成が大きく変わっており、中でも第4版ドラフトはFAL（Federation Assurance Levels）がレベルごとに記載が分割されていることがわかります。
また、項目名の変化や構成の入れ替えも多少ありますが、5章は「5.1. Trust Agreements」および「5.3. 認証と属性の開示」、「5.4. RPの加入者アカウント」、「5.7. Shared Signaling」と多くの項目が新設されています。
そしてベース、A、Bと同様に本文書でも第11章 公平性に関する考慮事項が新設されています。
NIST SP 800-63C-4の第3版と第4版の章立ての比較
NIST SP 800-63C-4のドラフトの項目の変更点
ここからは各項目の中身を見ていきます。全ての項目の変化事項を載せきれないため、ここでは重要な変更箇所を取り上げていきます。
第4章（連携保証レベル ”FAL”）より
4.（連携保証レベル ”FAL”）は、FALの各保証レベルに対する要求事項が定義されています。第3版ではアサーションの連携と検証に着目したレベル分けとなっていましたが、第4版ドラフトではインジェクション対策、Trust Agreement、クライアント登録方法、アサーションの提示方法の4項目を保証レベルの要件とする変更が加えられています。
一方、第3版ではFAL2/FAL3においてはアサーションへの暗号化要件が含まれていましたが、第4版ドラフトでは各保証レベルに対する要求事項から削除されています。
第3版ではアサーションに氏名、メールアドレス、住所等の個人を特定できる情報（PII）を含む属性値が含まれることが前提とされた考え方でしたが、第4版ドラフトでは6.3. アイデンティティのAPIの節が新設され、アサーション外での属性連携が規定されたためと推察されます。
暗号化要件は各保証レベルに対する要求事項からは削除されましたが、暗号化の有無はアサーションにPIIを含むか否かで判断するべきであるという考えに基づき、FALの各保証レベルにかかわらずブラウザ等のIdP/RP以外の第三者を経由するアサーションにPIIを含む場合は暗号化が必須になります。
第3版と第4版ドラフトを比較したFAL要件は以下の通りです。第3版と第4版ドラフトの差分項目を赤字で記載しています。
|
|
NIST SP 800-63C-3 |
NIST SP 800-63C-4 ドラフト |
|
FAL1 |
・アサーションの署名 ・ベアラアサーション |
・インジェクション対策の推奨 ・Trust Agreementの静的/動的合意 ・アサーションの署名 ・ベアラアサーション |
|
FAL2 |
・アサーションの署名 ・アサーションの暗号化 ・ベアラアサーション |
・インジェクション対策 ・Trust Agreementの静的合意 ・アサーションの署名 ・ベアラアサーション |
|
FAL3 |
・アサーションの署名 ・アサーションの暗号化 ・Holder-of-keyアサーション |
・インジェクション対策 ・Trust Agreementの静的合意 ・静的なクライアント登録 ・アサーションの署名 ・アサーションおよび紐づく認証器の提示 |
4.1.（FAL1）
4.1.（FAL1）ではOpenID ConnectのインプリシットフローまたはハイブリットフローおよびSAML Web SSOプロファイルがFAL1相当であると例示されています。第3版ではフロントチャネルを経由するフェデレーション方式は暗号化要件からFAL2以上の対策が必須でしたが、前述の通り暗号化に対する考え方が変更となったことからFAL1にて利用可能になりました。
また、静的・動的は問わないもののTrust Agreementが必須となっています。Trust Agreementについては後述する第5章についてで説明します。
4.2.（FAL2）
4.2.（FAL2）ではOpenID Connectの認可コードフローのようにバックチャネルでのアサーション連携を行う等のインジェクション攻撃対策が必須となっています。Trust Agreementについては事前の静的な確立が必須要件となっています。
4.3.（FAL3）
4.3.（FAL3）では第3版から引き続きアサーションの窃取対策が必須となっています。第3版では窃取対策としてHolder-of-keyアサーションの利用が必須でした。しかし、Token Binding と呼ばれるTLSレイヤを拡張してHolder-of-keyアサーションを実現する仕様が普及しなかったことで、FAL3の要件を満たすことが困難となっていました。
第4版ドラフトではBound Authenticatorの利用へと変更することでFAL3を実現するために利用可能範囲を広げたものと推察されます。また、FAL3ではTrust Agreementのみでなくクライアント登録も静的に行う必要があることが明記されています。
4.4.（xALの要求と取り扱い）
4.4.（xALの要求と取り扱い）ではIdPがRPに対して当該フェデレーション処理におけるIAL、AAL、FALを伝達する必要があることが追加されました。これによりRPはIdPから伝達されるxALに応じてアクセスの受け入れ判断を行ったり、提供機能を変更したりすることが可能になります。
本記述の追加はxALを伝達することで、実際にユーザーの登録・認証処理を行わないRPにおいてもxALの基準を満たしたシステム運用を実現することを目的としていると推察されます。
第5章（フェデレーション）より
第3版の5.1.（フェデレーションのモデル）として記載されていた内容は第4版ドラフトでは5.1.（Trust Agreements）、5.2.（登録）へそれぞれ分割して記載されています。これは事前合意、クライアント登録、フェデレーション処理というフェデレーションのステップを意識した記載へと変更したものと推察されます。
5.1.（Trust Agreements）
5.1.（Trust Agreements）は第4版ドラフトで新設されています。Trust Agreementとは、フェデレーション処理を行うにあたりIdPとRP間で信頼関係を築くための取り決めのことであり、以下のパラメータについて合意することが必須化されています。
- IdPがRPに対して開示できる属性値のリスト
- IdPがアサーションを生成できる加入者アカウントの母集団
- RPがリクエストする属性値のリスト
- RPがリクエストする各属性値についてその利用目的
- 加入者アカウントの開示にかかる意思決定の責務を負う組織・個人または主体
- 加入者がRPに開示される属性値について知る手段
- IdPが提供しうるxAL
- RPが必要とするxAL
Trust Agreementには静的な合意と動的な合意が存在します。静的な合意とはフェデレーション処理の事前に合意を行うことを指し、合意が契約等に紐づくこともあります。合意したパラメータは加入者を含むすべての関係者に開示されます。
動的な合意とは、RPとIdPが加入者をログインさせる目的で暗黙的に確立するものであり、フェデレーション処理中にIdPおよびRPから加入者に開示される必要があります。また、動的な合意におけるフェデレーション処理では加入者が連携時に同意を行うことが必須になります。
なお、Trust AgreementはIdPとRPが同一のセキュリティドメイン・法的所有権のもとにある場合もすべてのフェデレーション処理において必要であると記載されています。
5.3.（認証と属性の開示）
5.3.（認証と属性の開示）は第3版の4.2.（ランタイムの決定）に記載されていた内容を拡充した内容となっています。第3版に記載されていたIdP側が保持するRPの許可リスト/ブロックリストに加えて、第4版ドラフトではRP側が保持するIdPの許可リスト/ブロックリストおよびRPのランタイム決定に関する内容が追加されています。
5.4.（RPの加入者のアカウント）
5.4.（RPの加入者のアカウント）にはRP側で保持する加入者アカウント情報とライフサイクルに関する記載が新設されました。IdPとRPのアカウントライフサイクルは独立しており、本来はRP側も個人情報の保持期間を超過した場合には削除するといった対応が必要となるところ、RPのアカウント管理が適切になされないケースが存在することから本項目は追加されたものと推察されます。
RPの加入者アカウントをプロビジョニングする方法の説明と共に、時間の経過に伴いIdPとRPがそれぞれ保持する属性情報に乖離が発生する可能性があるため、IdP側の属性更新・アカウント削除・RPへのアクセス無効化時において、IdPはRPに対してプロビジョニングAPIやシグナル共有等の手段によって連携が必要であることが追加されています。
また、長期間利用のない休眠状態のRPの加入者アカウントを保持することはRP側のリスクとなるため、休眠アカウントの削除についても記載されています。
5.5.（プライバシー要件）
5.5.（プライバシー要件）では後述するシグナル共有を用いて加入者アカウントの削除通知を行うべきである点とプロビジョニングAPIに対するアクセス制御が追加されています。
5.6.（フェデレーション環境での再認証とセッションの要件）
5.6.（フェデレーション環境での再認証とセッションの要件）ではRPがIdPへフェデレーション要求を行う際に、IdPでの認証有効期間を指定する必要がある旨が記載されました。これにより、OpenID Connectのmax_ageパラメータのように加入者がIdP上で有効なセッションを保持していた場合においても、RPが指定する有効期間を過ぎていた場合には再認証が必要ですとなります。
5.7.（シグナル共有）
5.7.（シグナル共有）では加入者アカウントに変更や削除等のイベントが発生した場合のIdPとRP間における通知について記載されています。OpenID FoundationでもShared Signals and Eventsとして本項に記載されるシグナル共有に関する仕様の策定が進んでいます。
第6章（アサーション）より
第3版まではアサーションにIAL/AALを含めることが望ましいとの記述がありましたが、第4版ドラフトではアサーションにIAL/AALを含めることが必須化され、またFALも同様にアサーション内に含む必要があることが追加されました。
6.1.（アサーションの紐付け）
6.1.（アサーションの紐付け）は第3版ではHolder-of-keyアサーションとすることがアサーションの紐づけに必須でしたが、第4版ドラフトでは Bound Authenticatorとの記述に一般化され、Holder-of-keyはIdPが管理する Bound Authenticatorの一つであるという位置づけとなりました。
この変更からIdP管理の認証器だけでなく、RP管理の認証器の利用も含め、より広く加入者を認証できる認証器が許容されるようになっています。また、RPが管理する Bound Authenticatorを利用する場合における初回登録処理についても定義されています。この変更は第3版でのHolder-of-keyアサーションのみでは実装・運用を行う上で十分な実用性がないと判断されたためと推察されます。
6.2.（アサーションの保護）
アサーションの暗号化要件として、第3版ではフロントチャネルを経由するアサーションは暗号化必須でしたが、第4版ドラフトではフロントチャネルを経由する、かつ個人を特定できる値（PII）が含まれる場合に暗号化が必須へと変更されました。
この変更はアサーションの暗号化はあくまでプライバシー保護を目的としたものであり、改ざん・なりすまし等の攻撃対策を目的とするものではないという考え方であると推察されます。
また、複数のRP間で加入者アカウントの名寄せが行われることを防ぐために、RP毎に異なる識別子を生成するPairwise Pseudonymous Identifier（PPI）を用いて同一の加入者アカウントにおいてもRP毎に異なるアカウント識別子を連携することがありましたが、Trust Agreementでの合意等を条件にPPIの発行について特定のRP群に対しては同一のPPIを共有してもよいとの記載が追加されました。これにより、同一の事業者が提供するRP等においてRP間で加入者を特定することができるようになるため、サービス横断でのコンテンツ提供が容易になります。
6.3.（アイデンティティのAPI）
6.3.（アイデンティティのAPI）はアイデンティティAPIまたは属性APIと呼ばれる加入者に関する属性を提供するAPIに関する記述となっています。これはOpenID ConnectのUserInfoエンドポイントのようなAPIを指すものです。
アイデンティティAPIを利用することでアサーションに含める属性値は必要最低限とすることでアサーションのサイズを小さくし、RPで扱いやすくするとともにセンシティブな情報を含める必要がなくなることがメリットとして挙げられます。
第11章（公平性に関する考慮事項）より
本文書においてもベース、A、Bと同様に公平性に関する考慮事項が追加されました。
フェデレーションプロセスにおいて起こる公平性の問題例として不安定ネットワークしか利用できない環境でフェデレーション処理がタイムアウトしてしまう場合や認知障害等でフェデレーション処理時の同意判断が困難な場合等が挙げられていますが、全ての問題を想定することは困難であるため、加入者が不公平な認証要件について報告し、代替手段のアドバイスを行うためのメカニズムを提供する必要があると記載されています。
また、RPは加入者が特定のIdPへアクセスし続けられるとは限らないことを認識し、複数のIdPを一つのアカウントに紐づけることを可能にすることで、加入者が特定のIdPへのアクセスを失った際のリスクを低減することができます。また、このような課題を解決する方法として、SSI（Self-Sovereign Identity）と呼ばれる考えや、SSIの思想に基づいて作られるデジタルアイデンティティウォレットも昨今注目されています。
複数のIdPアカウント紐づけが難しい場合は独自でアカウントリカバリの仕組みを整備する必要があります。
NIST SP 800-63C-4のドラフトの変更点を踏まえて
第3版では各FAL要件の定義は詳細な記載がされておらず、大部分は代表的実装パターンとパターンごとの要件をまとめたものでした。
第4版ドラフトではアサーションの連携部分のみでなく、連携前のTrust Agreementsや連携後のRPアカウントのライフサイクルに関する言及が追加されるなど、実際のフェデレーション処理の安全性のみではなく実運用を踏まえた記載へと変更されています。これは世間一般に広くフェデレーションが普及してきたことで、実運用の中から生まれた課題・リスクに対応するための記載と考えられます。
フェデレーションプロトコル自体もアップデートされていく中でフェデレーション処理のみに着目するのではなく、前後の運用まで踏まえた考慮が必要です。
全4回のNIST SP 800-63-4（ドラフト）解説は以上で終了です。繰り返しですが、本記事執筆時点ではNIST SP 800-63-4はベース、A、Ｂ，Ｃいずれもドラフト段階です。
当社では本ドラフトに対してパブリックコメントを送付しており、本ドラフトがより良い文書となるように活動を行っています。今後もパブリックコメントの反映を経た正式版の公開を注視してまいります。
また、NIST SP 800-63-4（ドラフト）で強調されたような多角的な観点も踏まえたコンサルティングによるご支援に加えて、フェデレーションやAPI認可を実現するためのOAuth / OpenID Connect特化型 診断/設計レビューやコンシューマ向け認証基盤としてIdP機能を保持するパッケージ製品「Uni-ID Libra」のご提供もしておりますので、お気軽にご相談ください。
- BtoCサービスに特化した顧客ID統合・管理ソリューション「Uni-ID Libra」
- APIセキュリティ診断／APIセキュリティ設計レビュー
- オンライン常駐で企業のセキュリティチームを支援 SEC Team Services
