Oktaとは

Oktaとは、クラウド型IDaaSサービスです。

様々なサービスやクラウドに連携できるため、複数のクラウドサービスを利用していたとしても、OktaのID1つでそれぞれのサービスにSSOをできるように設定ができます。

今回はOktaのIDを使ってGoogle Cloudを利用できるようにします。

Workforce Identityとは

他のIDaaSと連携することで、GoogleアカウントがなくてもGoogle Cloudを利用できるようにするためのサービスです。

似た様な名前でWorkload Identityというものがありますが、こちらは他のサービスから証明書情報等なしでサービスアカウントの権限を利用するためのものです。 （GKEのPodからSAの権限を利用するときや、Github ActionsなどでSAの権限を利用してGoogle Cloudのリソースを利用する場合など）

---

IdP-initiatedとSP-initiated

SAML認証における処理のフローにはIdP-initiatedとSP-initiatedの2つがあります。GoogleCloudでは双方の認証方法をサポートしています。このブログで詳細は割愛しますが、この2つのフローの大きな違いは、認証の開始点です。

IdP-initiated

IdP-initiatedのフローでは名前の通り、IdP(Identityプロバイダ)を出発点として、SP(サービスプロバイダ)にサインインをします。
つまりOktaへのサインインを行った状態でGoogle Cloudへサインインを行います。
Oktaではユーザーホームから該当のアプリケーションを選択することでこのフローをたどります。
以下IdP-initiatedについてのOktaの公式ドキュメントへのリンクです。
https://help.okta.com/oag/en-us/content/topics/access-gateway/ref-arch/flow-idi.htm

SP-initiated

一方SP-initiatedではサービスプロバイダを出発点として、IdPを経由してSPにサインインをします。
よってOktaへのサインインが済んでいなくても、Google Cloudへのサインインを行うタイミングで強制的にOktaを経由し、認証後、再度Google Cloudへのアクセスを行います。
Workforce Identityのプロバイダを作成後、表示されるURLにアクセスすることでこのフローをたどります。
以下SP-initiatedについてのOktaの公式ドキュメントへのリンクです。
https://help.okta.com/oag/en-us/content/topics/access-gateway/ref-arch/flow-spi.htm

---

設定方法

Okta

今回はOktaのフリートライアルを利用しました。

まずはアカウントを作成します。

↓から登録しましょう。

登録後メールが来るので、アクティベートするとトライアル用のテナントの作成が完了します。
作成されたテナントの初期画面は以下です。

この初期画面はOktaのユーザ画面のようなので、ユーザやグループを作成できる管理画面が表示されるようにします。
画面右上にある「管理者」ボタンをクリックします。
管理者ボタンをクリックすると、管理者画面の初期設定画面？みたいなのが出るので、
今回の初期設定では基本的に「Other」を選択し、値が必要な場合は「test-koba」を入力しました。
以下参考画像です

上記まで設定すると以下の様な管理者画面が表示されます。
今回はWorkforce Identity用のユーザーとグループおよびアプリケーションの設定が必要です。

ユーザー作成

左のメニューから「ディレクトリ＞ユーザ」を選択します。

以下の画面が出てくるので、「ユーザを追加」ボタンをクリックします。 「ユーザを追加」をクリックすると、以下のモーダルが表示されるので、適宜入力して「保存」ボタンをクリックします。

これで作成されたユーザの人にメールが飛ぶので、アクティベートして完了です。

グループ作成

左のメニューから「ディレクトリ＞グループ」を選択します。
以下の画面が出てくるので、「グループを追加」ボタンをクリックします。 「グループを追加」をクリックすると、以下のモーダルが表示されるので、適宜入力して「保存」ボタンをクリックします。 今回はグループにユーザーを割り当てて使うので、作成したグループ名をクリックしてユーザを追加します。
以下のグループ名をクリックします。 以下の画面で「ユーザーを割り当て」をクリックします。

以下の画面で表示されたユーザの右側にある「＋」をクリックし、「完了」ボタンをクリックすることでユーザの割り当てができます。

アプリケーション作成

Oktaの管理画面のサイドメニューから「アプリケーション」を選択します。 「アプリ統合を作成」を選択します。 今回はSAML2.0を選択します。 ①一般設定、②SAMLを構成、③フィードバックといった流れで設定をしていきます。
①「一般設定」ではアプリ名・アプリのロゴ等を設定します。 ②「SAMLを構成」ではSAMLに関するSAML ACS・オーディエンス等を設定します。
設定するURLについては以下で確認できます。
https://cloud.google.com/iam/docs/workforce-sign-in-okta?hl=ja#create-saml-provider

デフォルトのRelay Stateには、IdP-initiatedフローでのアクセス先を設定します。
このRelay Stateを設定しないとIdP-initiatedフローは利用できません。
以下のGoogleドキュメントにもあるように、Google Cloudコンソールのトップページ( https://console.cloud.google/ )を設定します。
https://cloud.google.com/iam/docs/workforce-sign-in-okta?hl=ja#sign_in

SAML Subject・グループの属性マッピング等もここで設定できますが、後ほどまとめてご紹介いたします。

今回は下の「ソフトウェアベンダーです。自社アプリをOktaと統合したいと考えています。」を選択し、ほかの項目については未記入としています。 アプリケーションの一覧画面に反映されれば完了です。

[事前作業]XMLメタデータファイルのダウンロード

Google CloudのWorkforce Identityの設定に、IdPで生成されたXMLファイルを登録する手順があります。
サイドメニューからアプリケーション＞作成したアプリケーション＞サインオンタブ＞「SAMLの設定手順を表示」を選択します。 オプションのメタデータをコピーし、任意の名前でダウンロードしておきます。

Workforce Identity

Poolの作成

Google CloudコンソールでWorkforce Identityの連携検索し、選択します。 「プールを作成」から新しいプールの名前を設定します。 この名前はのちにIAMで権限設定をする際に、プリンシパルとして使用する文字列になります。

Providerの作成

Poolの中にプロバイダを追加します。 プロバイダの選択として、今回はSAMLを選択します。 プロバイダの名前・事前作業でOktaからダウンロードしたXMLファイルをアップロードします。

属性マッピング

Oktaユーザーの情報やグループの情報をプリンシパル等で使うためには、属性情報をマッピングしておく必要があります。
Oktaの管理画面とWorkforce Identityプロバイダの画面双方で設定が必要なため、属性ごとに分けて説明します。
Oktaの管理画面の「SAMLの設定」＞「属性ステートメント」で、Workforce Identityに渡す属性の設定が可能です。
この属性ステートメントに追加した属性は、SAMLアサーションのプレビュー画面からXMLファイルで確認できます。

NameID

Oktaの管理画面

SAMLアサーション内のSubjectステートメントで指定するNameIDの設定です。
Oktaのユーザー名として、Oktaユーザー名（Oktaの仕様でメールアドレスを使用）、Oktaユーザー名のプレフィックス（メールアドレスの@より前の部分）、カスタムIDなどを設定できます。

Workforce Identity プロバイダの設定

Google.subjectは必須のキーです。以下がマッピングの例です。

Google	SAML
google.subject	assertion.subject

グループ属性ステートメント

Oktaの管理画面

Oktaで作成したグループ属性を渡すための設定です。
事前にグループを作成し、そのグループ名を値として設定することで、SAMLアサーションに反映されます。
以下はOkta側のグループ属性の設定です。今回はOktaグループとして作成したgceditorsグループをステートメントとして登録しました。

名前	名前のフォーマット(オプション)	フィルター	(値)
groups	指定なし	等しい	gceditors

Workforce Identity プロバイダの設定

グループ属性に対応するキーとしてGoogle.groupsが用意されています。以下がマッピングの例です。

Google	SAML
google.groups	assertion.attributes.groups

カスタム属性ステートメント

Oktaの管理画面

任意の属性ステートメントを追加できます。
ユーザーのプロファイルから部署名などをWorkforce Identityに渡したい場合などに使用します。
以下はユーザーのプロファイル内のdepartmentを属性として渡す例です。

名前(例)	名前のフォーマット(オプション)	(値)
department	指定なし	user.department

Workforce Identity プロバイダの設定

SAMLアサーションでは以下の記述があるように、属性がリストとみなされるため、リストの番号を指定する必要があります。

SAML アサーションでは、Attribute に複数の AttributeValue タグを設定できます。
したがって、すべての SAML 属性はリストと見なされるため、assertion.attributes.userRole はリストとなります
https://cloud.google.com/iam/docs/troubleshooting-workforce-identity-federation?hl=ja#mapped-attribute-string

よってdepartmentを明示的に指定するのではなく、attributeの配列番号で渡す必要があります。

Google	SAML
attribute.department	assertion.attributes.[0]

IAMロールの付与

OktaとWorkforce Identityを連携するだけだと、コンソールを表示する権限を持つだけになるため、各種リソースは表示できません。
表示するためにはIAMにて、連携したユーザー・グループに権限付与する必要があります。
Googleアカウントを用いたユーザーへの権限付与と同様に、IAMでプリンシパルに対してIAMロールを付与可能です。

IAMロールを付与するプリンシパルについて

以下がプリンシパルに関するドキュメントです。
https://cloud.google.com/iam/docs/workforce-sign-in-okta?hl=ja#manage-access

ユーザ単位

WORKFORCE_POOL_IDにはプール作成時に設定したプールIDと、SUBJECT_VALUEにはユーザーIDを設定したプリンシパルを使用して、ユーザーへの権限付与が可能です。
単一のユーザーのプリンシパルの例は以下の通りです。

principal://iam.googleapis.com/locations/global/workforcePools/[WORKFORCE_POOL_ID]/subject/[SUBJECT_VALUE]

グループ単位

以下がグループのプリンシパル例です。

principalSet://iam.googleapis.com/locations/global/workforcePools/[WORKFORCE_POOL_ID]/group/[GROUP_ID]

ユーザの属性単位

事前にOktaのユーザーのプロファイルに設定した部署名をマッピングした場合、プリンシパルセットの例は以下のようになります。

principalSet://iam.googleapis.com/locations/global/workforcePools/[WORKFORCE_POOL_ID]/attribute.department/[DEPARTMENT_VALUE]

---

Workforceユーザーへの制限事項

付与可能なIAMロールの制限

Workforce Identityプールのユーザーにはオーナーロールを付与できませんが、編集者などのロールは付与できます。 https://cloud.google.com/iam/docs/configuring-workforce-identity-federation?hl=ja#representing-workforce-users

利用可能なサービスの制限

以下のページでは、Workforce Identity連携またはWorkload Identity連携を使用できるGoogle Cloudプロダクトの制限事項とサポートレベルが記載されています。 使用するGoogle Cloudプロダクトが、ID連携でサインインしたユーザーでも利用できるかどうかを確認してください。 https://cloud.google.com/iam/docs/federated-identity-supported-services?hl=ja

まとめ

この記事では、OktaとWorkforce Identityの連携により、Googleアカウントを持たないユーザーでもOktaの認証情報を使ってGoogle Cloudに安全にアクセスする方法を解説しました。
Oktaでのユーザー・グループ・アプリケーションの設定から、Workforce Identityでのプールとプロバイダの作成、属性マッピング、IAMロールの付与まで、具体的な手順をスクリーンショット付きで説明しました。
ぜひこの記事を参考に、OktaとWorkforce Identityの連携を検討してみてください。

参考

・Workforce Identityについて
https://zenn.dev/google_cloud_jp/articles/3f06bac31aa013

・SAMLの仕組みについて
https://www.hitachi-solutions.co.jp/iam/saml.html
https://qiita.com/Shinya-Yamaguchi/items/434fab8c39e806e69a88