フェデレーテッド・アイデンティティ・マネジメントとは？

PeachShutterStock | shutterstock.com

企業セキュリティの中核では、ユーザーの利便性とセキュリティ要件のバランスが問題になっています。これは定期的に認証レベルで行われるバランス行為であり、オンボーディングとログインエクスペリエンスに直接影響を与えます。この対立を解決する際には、フェデレーテッド・アイデンティティが最前線に立っています。セキュリティレベルを損なわないようにしながら、良いユーザー体験を提供することができます。

フェデレーテッド・アイデンティティ・マネジメント – 定義

Identity & Access Management (IAM)は、デジタル・アイデンティティとアクセス管理に関する総括的な領域です。フェデレーテッド・アイデンティティ・マネジメント（または統合アイデンティティ管理）はIAMのカテゴリで、複数の相互作用またはアイデンティティ情報の交換をカバーするために、単一の認証イベントを安全に有効にすることに焦点を当てています。言い換えれば、フェデレーテッド・アイデンティティ・マネジメント（FIM）は、多くのサービスが単一のデジタル・アイデンティティを共有することを可能にします。FIMの実践的な使用例は、Googleアカウントを使用してTwitterにログインする場合です。

統合アイデンティティ管理は、ユーザー体験、全般的なセキュリティ、および耐障害性に有益な場合があります。このためには、以下の妥協案を受け入れる必要があります。

• アーキテクチャの複雑さの増加、

• 特定のベンダーへの依存、および

• 潜在的なサービスコスト。

フェデレーテッド・アイデンティティ・マネジメントは、シングルサインオン（SSO）と混同されることがあります。厳密に言えば、SSOはFIMの機能であり、以下で詳しく見ていく主要なユースケースの1つです。事前に注意：Self-Sovereign Identity（または分散型アイデンティティ）のトピックは別の話です。

ユースケース（フェデレーテッド）シングルサインオン

シングルサインオンには2つのタイプがあります。一つは単一の組織内のアプリケーションに適用されるもので、もう一つは組織を超えて適用されるものです。前者は通常、単にシングルサインオンと呼ばれ、「エンタープライズ・シングルサインオン」と呼ばれることもあります。後者はフェデレーテッド・シングルサインオン（FSSO）の下に分類されます。

両方のSSO形式をカバーするハイレベル・アーキテクチャは以下の通りです。

写真: Foundry / Matthew Tyson

いずれの場合も、フェデレーテッド・アイデンティティ・マネジメントには、異なるサービス間で共有ログイン認証情報を仲介する中央機関が必要です。これは以下のようなアイデンティティ・マネージャーである可能性があります。

• 組織自体によって作成されたもの（例えばActive Directoryを使用して）。

• アイデンティティ・プロバイダーを通じてさまざまな程度に提供されるもの。

エンタープライズ・シングルサインオンは、従業員がHRポータルやITチケットシステムなど、内部システムに複数回ログインする必要がある状況をカバーすることが多いです。このコンセプトは明らかなUXの問題を伴うだけでなく、アイデンティティ情報が異種システムに分散しているため、システム的な問題も含みます。この状況は、セキュリティを損ない、ポリシーの実施を困難にします。例えば、従業員のオンボーディング時とオフボーディング時には、2つの異なるデータストアを変更する必要があります。

フェデレーテッド・シングルサインオンにより、企業の境界を越えてログイン認証情報を共有できます。そのため、Google、Microsoft、Amazonなどの広範な信頼を持つ大規模で確立された実体に依存するのが一般的です。小さなアプリケーションでも「Googleでサインイン」オプションを比較的簡単に追加でき、機密情報が大規模な組織の手に留まる簡単なサインイン方法をユーザーに提供できます。

フェデレーテッドSSOの実装

フェデレーテッドSSO・ソリューションの構築は、特定の要件に応じて異なります。ただし、一般的な手順は同じです。

• アイデンティティ・プロバイダーをセットアップします。集約化されたアイデンティティ・インフラストラクチャを提供するか、フェデレーテッド・アイデンティティ・プロバイダー（Google、Microsoft、Okta）のアカウントをセットアップしてください。また、ハイブリッド形式を作成することも可能です。

• アプリケーション情報でプロバイダーを設定します。アイデンティティ・プロバイダーを設定し、アプリケーションがプロバイダーと接続できる基盤を作ります。

• プロバイダー認証情報を追加します。これらは、次のステップでアプリケーションに認証方法を指示するために使用します。

• アプリケーションをセットアップします。アプリケーション・コードに、認証とアイデンティティ・プロバイダー・サービスの相互作用のための依存関係を追加します。

• 新しい認証を統合します。設定されたSSOサービスにより、ユーザーは認証するための方法を持っています。これは「透過的」に機能します。アプリケーションは、別のサービスで有効なセッションを持つユーザーを自動的に認識して認証します。

シンプルなソリューションであるため、ほとんどの企業は現在、SaaSオファリングの一部としてクラウド・アイデンティティ・プロバイダーを選択しています。これはエンタープライズSSO、フェデレーテッドSSO両方に当てはまります。

SSOプロトコルの実装

SSO相互作用では、本質的に3つのプロトコルが使用されます。SAML、OIDC、およびOAuth 2.0です。使用しているアイデンティティ・プロバイダーがサポートするプロトコルに応じて、アプリケーション間で安全なトークン情報を送信するために、これらのいずれかを使用します。各プロトコルは、特定のユースケースに対応したオープン標準です。

• SAMLはXMLベースのプロトコルで、企業がエンタープライズSSOをサポートするため、または異なるビジネス・サービス・プロバイダー間を行き来するために使用されることが多いです。アイデンティティ・プロバイダーがサポートしている場合、フェデレーテッドSSO（アイデンティティ・プロバイダーがサポートしている場合）を含む、アイデンティティの一般的な共有にも使用できます。

• OAuth 2.0は、ユーザーの同意に基づいてプロバイダー間でリソース・データを共有できる認証プロトコルです。Oauthは、ログイン認証情報を提供することなく、サービス間で認証を共有することに焦点を当てています。

• OIDC（OpenID Connect）は、OAuth 2.0に基づくレイヤーで、通常、ソーシャルログイン（例：「GitHubでサインイン」）に使用されます。OIDCには、OAuthに対する拡張機能が含まれています。これには、Identity Assertions、Userinfo API、および標準Discovery（アイデンティティ情報の安全な提供と使用のための標準化メカニズム）が含まれます。

これらのプロトコルは個別に、または他の技術と組み合わせて使用されます。例えば、JSON Web Tokenを使用して、OAuth 2.0認証情報トークン情報をより安全な形式でカプセル化することができます。

幸いなことに、これらのプロトコルを実装するプロセスは詳細に文書化されており、さまざまなテクノロジー・スタックでサポートされています。ほとんどの作業は、多くの言語とフレームワークの高度な抽象化によってカプセル化されています。例えば、Spring SecurityはSSOサポートを提供し、NodeJS/ExpressエコシステムのPassportも同様です。(fm)