あなたは旅慣れた旅行者だと想像してみてください。広く認知されている自国のパスポートを持っています。しかし、外国で特定のサービス（レンタカー、美術館への入場、現地の図書館の利用など）を利用しようとするたびに、自分が誰であるかを再び証明するという面倒な手続きを経なければならず、サービスごとに特別な現地のIDカードを取得する必要さえあるかもしれません。これは繰り返しの作業で非効率的ですし、多くの現地IDカードが出回ることになればセキュリティ上の頭痛の種です。
もし、信頼できる自国のパスポートを使って、訪問先の外国のすべてのサービスで使える、一時的で普遍的に受け入れられる「1日パス」を取得できたらどうでしょうか？このパスは、あなたの自国のパスポートを信頼するその外国の特別事務所によって発行されるのです。これこそが、本質的に Workload Identity Federation (WIF) があなたのソフトウェアアプリケーション（「ワークロード」）のために行うことです。
問題点： 新しいアプリケーション（ワークロード）であるAI「エージェント」システムは、SharePoint、Slack、Jira、MCPサーバーなど、多様なデータソースにアクセスする必要があります。これらのデータソースの多くは、異なるクラウド環境やオンプレミスに分散しているため、エージェントが広範なデータにアクセスできる必要があります。
従来、これには各分散システムごとに個別の秘密鍵と認証情報を発行し管理する必要がありました。これは、訪問する国ごとに異なるパスポートとビザを取得し持ち歩くのと同じくらい煩雑であり、セキュリティ上の重大なリスクを伴うものでした。
解決策：Workload Identity Federation (WIF) of Google
WIFは、高度な外交協定であり、万能翻訳機のように機能します。これにより、どこで実行されていてもあなたのアプリケーションは、Azure Active DirectoryやOktaのような外部IDプロバイダー（IdP）、あるいはOIDCやSAML（共通のID言語）を話す独自のシステムから信頼されたIDトークンを提示することで、例えばGoogle Cloudのサービスアカウントに「なりすます」ことができます。
静的で有効期間の長いGoogle Cloudの鍵を管理する代わりに、あなたのアプリケーションは、まるでその「1日パス」のように、短期間で一時的な認証情報を取得します。
実際の動作を見てみましょう：「Agentspace」のエージェント
以下に、WIFが私たちの「万能翻訳機」または「外交パスポート」の例えを使って、これをいかにスムーズかつ安全に行うかを示します。
例え話：外交封印袋と現地パス
あなた（ユーザー）： 「Oktaランド」または「Azure ADランド」の市民。
あなたの自国のパスポート： ログイン時にOktaまたはAzure ADによって発行されるOIDCまたはSAMLトークン。
ログインページ： 「Google Cloud国」の最初の「チェックポイント」または「大使館窓口」。
WIFを備えたGoogle Security Token Service (STS)： 「Oktaランド」や「Azure ADランド」からのパスポートを認識する「Google Cloud国」の「特別入国管理局」。
短期間のGoogle Cloud認証情報： STSによって発行される一時的な「Google Cloudアクセスパス」。
Agentspaceアプリケーション： 「Google Cloud国」におけるあなたの信頼できる「現地ツアーガイド」。
Google Cloudデータソース： 「Google Cloud国」内の「国立公園」や「機密アーカイブ」。
フロー:
1.国境への接近（ログイン）：
- あなたはログインページWidget/WebUIを開きます。ページはあなたのメールドメイン（例：yourcompany.com）が「Azure ADランド」によって管理されていることに気づきます。
- ブラウザは「Azure ADランド大使館」（あなたのAzure ADログイン画面）にリダイレクトされます。
2.パスポートにスタンプをもらう（IdPでの認証）
- あなたはAzure ADの認証情報でログインします。
- Azure ADは「はい、これは有効な市民です！」と言い、OIDCまたはSAMLトークン（あなたの「パスポート」）を（ブラウザ経由で）ログインページWidget/WebUIに返します。
3.パスポートを現地のアクセスパスに交換（WIFでのトークン交換）：
- ログインページWidget/WebUI機能は、この「Azure ADパスポート」（OIDC/SAMLトークン）を、WIFを使用するGoogleの「特別入国管理局」（Security Token Service - STS）に持っていきます。
- WIFの設定には「Azure ADランドからのパスポートを信頼します。もしパスポートにこれらの特定のスタンプや詳細（属性マッピング、グループメンバーシップなど）があれば、一時的なGoogle Cloudアクセスパスを発行します」と書かれています。
- STSはトークンを検証し、短期間のGoogle Cloud認証情報（あなたの「現地アクセスパス」）をログインページWidget/WebUI機能に返します。
4.ガイドにパスを渡す（Agentspaceが認証情報を取得）：
- ログインページWidget/WebUI機能は、Google Cloudの認証情報（あなたの「ローカルアクセスパス」）を確認した後、Agentspaceにリダイレクトします。。
5.VIPラウンジへの入場（Agentspace画面と初期IAM）：
あなたがAgentspace画面自体にアクセスしようとすると、Google CloudのIAM（Identity and Access Management – 門番）が、あなたの「現地アクセスパス」に関連付けられたIDがAgentspaceを使用することを許可されているかどうかを確認します。
6.ガイドがあなたに代わってアトラクションにアクセス（Agentspaceがデータにアクセス）：
- あなたはAgentspaceを操作します。AgentspaceがあなたのためにGoogle Cloudデータソースからデータを取得する必要がある場合、それはあなたの「現地アクセスパス」（短期間のGoogle Cloud認証情報）を使用します。
- Google Cloudデータソースは「現地アクセスパス」を確認します。その後、Google Cloud IAMはそのパス上のIDが特定のデータにアクセスする権限を持っているかどうかを検証します。
7.「アトラクション」も連携されている場合は？（外部データソースへのフェデレーション検索）：
- 場合によっては、Google Cloudのネイティブサービスではないデータソースを検索する必要が生じる場合があります。ただし、そのデータソースは「Azure AD環境」または「Okta環境」にも統合されている必要があります。
- この場合、Agentspaceは（あなたのAzure AD IDから派生した）Google Cloud IDを保持し、外部データソースに「Azure ADランドのユーザーXのためにリクエストしています」と伝えます。
- この外部データソースは、「Azure ADランド」と独自の「外交関係」を持っており、ユーザーXに対する独自の権限を適用します。これは、データソースがGoogle Cloud認証情報を直接確認するというよりも、 AgentspaceがWIFから派生した元のID情報を使用してユーザー固有のコンテキストでクエリを実行することに近いです。
WIF自体は直接「ユーザーXがAgentspaceのデータにアクセスできる」とは言いません。WIFは信頼できるGoogle Cloud IDを提供します。その連携されたIDに基づいて最終的な認可決定を下すのは、Google Cloud IAM（および場合によってはターゲットデータソースのIAM）です。
この「Workload Identity Federation (WIF)」はなぜそんなに重要らしいのか？
1.セキュリティの強化： アプリケーションに静的で有効期間の長いサービスアカウントキーを保存・管理する必要がありません。短期間の認証情報は、侵害された場合のリスクを大幅に削減します。
2.管理の簡素化： 既存のIDプロバイダーを活用します。ユーザーは新しいログインを必要としません。管理者はIDを一箇所で管理します。
3.より高い柔軟性： ワークロードはどこでも（オンプレミス、他のクラウド、CI/CDパイプライン）実行でき、それでもGoogle Cloudリソースに安全にアクセスできます。
4.きめ細かいアクセス制御： 外部IdPトークンからの属性（グループメンバーシップなど）をGoogle Cloud IAMの権限にマッピングし、正確な制御を保証できます。
Please refer following links:
https://cloud.google.com/iam/docs/workload-identity-federation
https://cloud.google.com/agentspace/agentspace-enterprise/docs/connect-third-party-data-source
https://cloud.google.com/iam/docs/workforce-sign-in-microsoft-entra-id
https://learn.microsoft.com/en-us/entra/identity-platform/optional-claims?tabs=appui#configuring-groups-optional-claims