著者:Salah Machani、RSA、Dell Technologies Business;FIDOエンタープライズ・アダプション・グループの共同議長
FIDOアライアンスは、使いやすく導入しやすい強力な多要素認証(MFA)のフレームワークを開発しました。 多くの企業は、オンプレミスまたはクラウド アプリケーション間でシングル サインオン (SSO) を有効にするためにフェデレーションを展開しています。 企業が認証を強化するためにFIDOの導入と活用を検討する際、FIDOが既存のフェデレーションプロトコルを置き換えることを意図しているのか、それともFIDOを既存のプロトコルと統合するために完全なオーバーホールが必要なのか疑問に思っています。 答えはノーです:FIDOとフェデレーションプロトコルは補完的であるだけでなく、最適に連携して機能します。
FIDOアライアンスは、FIDOがフェデレーションプロトコルをどのように補完するかを詳述し、FIDOベースのMFAのサポートを追加し、フェデレーション環境で従来の認証方法を置き換える、または補完するために2つを統合する方法に関するガイドラインを提供するホワイトペーパーを公開しました。
FIDOの主な目的は、複数のパスワードを覚えたり、個別のアプリケーション用にさまざまな2要素認証フォームファクタを用意したりする負担を軽減することです。 ユーザーがFIDO対応デバイス(セキュリティキーやモバイルデバイスなど)をアプリケーションプロバイダーに登録すると、一意の資格情報が生成され、その特定のアプリケーションプロバイダーのユーザーのアカウントにバインドされます。 ユーザーは、同じFIDO対応デバイスを使用し、このプロセスを繰り返して、追加のデバイスを持ち歩くことなく、他のアプリケーションプロバイダーでユーザー用の追加の一意の資格情報を生成できます。 ユーザーのデバイス上の資格情報は、通常、同じローカルPINまたは生体認証でロックされているため、ユーザーは1つの簡単なジェスチャーを使用して複数のアプリケーション間で認証できます。
Security Assertion Markup Language (SAML) や OpenID Connect (OIDC) などのフェデレーション プロトコルは、ユーザー ID をアプリケーションやサービス プロバイダーから離れた、信頼できるサードパーティの認証機関に移動するように設計されています。 ユーザーが信頼できる認証機関に対して認証を行うと (通常はパスワードを使用して)、そのユーザーが 1 つ以上のアプリケーション プロバイダーに提示するための期限付きアサーションまたはトークンが発行されます。 ユーザーは、認証局やすべてのアプリケーション・プロバイダーに対して再認証を行う必要はありません (これは SSO の定義です)。
FIDO認証器は、企業がアプリケーションへの「サインイン」要求を開始するときにユーザーを認証したり、ユーザーセッションの認証を「ステップアップ」したりするために利用されます。 フェデレーテッド環境では、FIDOを導入して次の2つのシナリオをサポートできます
最初のサインイン シナリオでは、アプリケーション プロバイダーはユーザーをアプリケーション機関 (この
図1:FIDOベースの認証による最初の「サインイン」
ステップアップのシナリオでは、認証局が特定の認証メカニズムを使用して初期ユーザー認証を実行し、その事実に対するアサーションでアプリケーション・プロバイダにリダイレクトされた後です。 その後、そのアサーションは、特定のリソース要求に対して不十分な信頼性を生成するためにアプリケーション・プロバイダーによって決定されます。 その結果、アプリケーションプロバイダは、FIDOベースのメカニズムを使用して追加の認証を実行するか、以前の非FIDOベースの認証を補完するためにFIDOベースの認証でユーザーを再認証するよう要求して、ユーザーを認証局にリダイレクトするか、以前の低保証のFIDOベースの認証を補完するために、より高い保証のFIDOベースの認証が望まれます。 図2は、フェデレーテッド環境でFIDOを使用したステップアップ認証の一般的なワークフローを示しています。
図2:FIDOベースの認証による「ステップアップ」
2つのシナリオの統合がもたらす価値は、既存のアプリケーションが認証局にFIDOベースの認証を要求するか、特定のFIDO認証器を使用できることを前提としています。 FIDOベースの認証の要求は、FIDO認証器を必要とするポリシー名または保証レベルを指定することで、明示的または暗黙的に行うことができます。 また、認証局は、すべてのユーザー、ユーザーのグループ、またはアプリケーションプロバイダーによって事前に定義された特定の条件下で、デフォルトでFIDOベースの認証を強制することができます。
ユーザーが信頼できる認証局にFIDO認証器を登録し、各アプリケーションに直接登録することなく、そのFIDO認証器をアプリケーション間で利用できるようにすることで、フェデレーションはユーザーエクスペリエンスを向上させ、セキュリティを向上させ、FIDOの展開を「増幅」します。
FIDOとフェデレーションプロトコルの信頼モデルは異なることに注意することが重要です。
- FIDOでは、ユーザーとアプリケーションプロバイダーの間に直接的な信頼関係があります。 アプリケーションプロバイダーは、FIDOサーバーをインフラストラクチャにデプロイして、ユーザーの公開資格情報を保存し、ユーザーを直接認証します。 アプリケーションプロバイダーは、FIDOリライイングパーティ(RP)と呼ばれます。
- フェデレーション プロトコルでは、ユーザーとアプリケーション プロバイダー間の信頼関係は間接的です。 信頼は、ユーザーと認証局の間、および認証局とアプリケーション・プロバイダーの間に確立されます。 ユーザーは認証局に対して認証を行い、認証局はユーザーの ID に関するアサーションをアプリケーション・プロバイダーに発行します。
FIDOとフェデレーションを組み合わせた環境では、認証局はFIDO RPとして機能します。
FIDOは、急速に変化するエンタープライズ環境の新たなニーズに応えるだけでなく、フェデレーションプロトコルなどのレガシープロトコルを拡張して構築し、既存の機能やワークフローを維持します。 このようにして、企業はFIDOのセキュリティとユーザビリティの利点を最も費用対効果の高い方法で活用できます。 詳細については、ホワイトペーパーをダウンロードしてお読みください。
このホワイトペーパーでは、FIDOを主要なフェデレーションプロトコルであるSAML、OIDC、OAuthと統合する方法について、次のように詳しく説明しています。
- SAMLサービスプロバイダー(SP)は、SAMLアイデンティティプロバイダー(IDP)にユーザー認証をFIDOベースにすることを要求します。
- SAML IDPは、ユーザー認証がFIDOを使用して実行されたことを示すSAMLアサーションをSPに返します。
- OIDC RPは、認証がFIDOベースであることをOIDCプロバイダーに要求します。
- OIDC プロバイダーは、ユーザー認証が FIDO を使用して実行されたことと、その方法を示すトークンを RP に返します。
- FIDOは、OAuth2環境で、保護されたリソースにアクセスするためのユーザーの同意と承認の前に、ユーザー認証に活用できます。
FIDOテクニカルノートでは、実務者が理解すべき重要なFIDO仕様の側面に焦点を当てています。 テクニカルノートでは、アーキテクチャの選択肢に光を当て、ベスト プラクティスを説明し、テクノロジのデプロイ担当者にガイダンスを提供します。 テクニカルノートは、FIDOアライアンスのテクノロジーと進化を特集する現在進行中のFIDOシリーズの一部です。
