こんにちは！たつみんです！
Google Workspace(以下、GWS)はグループウェアとして利用されている組織が多いのではないでしょうか。今日はOktaとGWSの連携について記事にします。
はじめに
Okta導入時にGWSは以下の点でSSO・Provisioning設定を行う最初のSaaSとして最適です。
- 連携対象ユーザーを部分的に指定することができる
- OktaでSaaS連携を行う際の流れや利用できる機能が一通り揃っており勘所を掴むのにちょうどよい
- 利用ユーザーが全社員となることが多くかつ、利用頻度が高いSaaSのためOkta導入をユーザーに印象づけることができる
GWS以外の他の多くのSaaSでは連携対象がテナント全体となることが多いため1番最初にSSO連携するには少し躊躇うことが多いと多います。GWSでは連携対象ユーザーを部分的に指定できるので例えば検証を行う情シス部門だけや今回の記事の例のようにテストユーザーのみを対象とすることができます。
設定方法
GWS側の事前設定
GWSではOktaのSSOを組織部門ごとに適用することができるため最初にテスト用の組織部門を作りましょう。
またこの時にテストユーザーも作成し所属させておきます。
GWSの特権管理者は動作確認時にSSOが有効であってもパスワードでログインできてしまいます。また、SSO動作確認時に作業者のアカウントで確認を行なってしまうとブラウザセッションの影響により正しい結果が得られないことがあるためテストユーザーを作成することは非常に大事です。
SSO設定
- Okta管理画面>Applications>ApplicationsからBrowse App Catalogをクリックします。
- カタログのトップページにGoogle Workspaceがあるのでクリックします。
もしなければGoogle Workspaceで検索します。
- Add Integrationをクリックします。
- Your Google Apps company domainでGWSで設定しているプライマリドメインを入力し、Nextをクリックします。
- Display the following linksはOktaダッシュボード上に表示するアイコンを選択し、Nextをクリックします。
今回はすべてにチェックを入れた状態で進めますが必要に応じて調整しましょう。 - Sign on methodsではSAML2.0を選択し、View Setup Instructionsをクリックします。
以下のように設定手順や設定値が表示されます。
- GWS管理画面からセキュリティ>認証>サードパーティのIdPによるSSOをクリックします。
- 組織向けのサードパーティのSSOプロファイルをクリックし、手順6.で表示したView Setup Instructionsの内容を入力します。
- ログインページのURLにはView Setup InstructionsのSign-in page URLを入力します
- ログアウトページのURLにはView Setup InstructionsのSign-out page URLを入力します
- 証明書ファイルのアップロードにはView Setup InstructionsのVerification certificateのリンクをクリックしダウンロードしたokta.certファイルをアップロードします
- パスワード変更用URLにはView Setup InstructionsのChange password URLを入力します
- ドメイン固有の発行元を使用にのみチェックを入れ、保存をクリックします。
この時点ではサードパーティのIDプロバイダでSSOを設定するに、チェックを入れずに進めます。
- 再びセキュリティ>認証>サードパーティのIdPによるSSOに移動し、SSOプロファイルの割り当ての管理内の管理をクリックします。
- 組織部門に注目すると最上位の組織部門が表示されています。この時SSOプロファイルの割り当てがなしになっていない場合はなしとします。
- テスト用に作成した組織部門を選択します。組織向けのサードパーティのSSOプロファイルを選択し、オーバーライドをクリックします。
- 組織部門Okta SSO Testの隣にオーバーライドしていることを示す目印が表示されたことを確認します。
- 改めて組織向けのサードパーティのSSOプロファイルの設定画面に戻り、サードパーティのIDプロバイダでSSOを設定するにチェックを入れ保存をクリックします。
- 手順10.から手順15.までで組織部門に限定したSSO設定の適用ができました。
- Okta管理画面に戻りSign-On Optionsの画面でDoneをクリックします。
- Assignmentsに移動しAssignボタンからテストユーザーをアサインします。
SSO動作確認
- これまでOkta管理者として操作していたブラウザとは別のブラウザかシークレットモードを起動し、Oktaにテストユーザーアカウントでログインします。
- ダッシュボードに表示されたアプリアイコンのうち任意のアイコンをクリックします。
今回はGoogle Driveを選択しました。
- テストユーザーアカウントを作成後に一度もGWSにログインしていない場合は以下の画面が表示されるため同意して進めます。
- 以下のようにGWSサービス、今回の場合はGoogle Driveが表示されることを確認します。これでOktaダッシュボードを起点とした認証、つまりIdP-Initiatedに問題がないことが確認できました。
- 次に以下のようにGWSサービス側のURLを起点とした認証つまりSP-Initiatedが可能かを確認します。
https://drive.google.com/drive/my-drive - これまでの動作確認で行った認証の影響を受けないようにテストユーザーでログイン済みのGWSおよびOktaからログアウトします。
- ブラウザにURLを入力し、メールアドレスを入力します。
- 以下のようにOktaのサインイン画面が表示されるのでサインインを実行します。
- 無事にGoogle Driveの画面が表示されればSP-Initiatedも問題ないということになります。
Provisioning設定
Provisioning設定ではAPI連携を実施します。この時にGWS側の特権管理者権限が必要となります。可能であれば個人に紐づくものではなく別途システムアカウントを用意し利用するのが理想です。
- Okta管理画面でGoogle Workspaceを開き、Provisioningタブを表示し、Configure API Integrationをクリックします。
- Enable API integrationにチェックを入れ、表示されたオプションからImport Groupsのチェックを外します。
- Disable Import Groupsの警告を確認し、Continueをクリックします。
Import Groupsについては以下のブログもご参照ください。
SPからOktaにインポートされたグループの削除方法について（よくあるお問合せ-Okta編）
- Authenticate with Google Workspaceをクリックします。
- 別ウィンドウで以下のように許可を求める表示がされるので許可をクリックします。
なお、今回は検証目的のため個人に紐づくアカウントで許可を与えています。
Google Workspace was verified successfully!と表示されたらSaveをクリックします。
- 以下のようにProvisioning to Appの画面が表示されます。Editをクリックし、Create UsersとUpdate User Attributesについてチェックを入れます。
Deactivate UsersについてはProvisioning動作確認後にチェックを入れるとよいでしょう。
Provisioning動作確認
ここではUpdate User Attributesが機能することを確認し動作確認とします。
- Assignmentsタブを表示します。以下のようにすでにアサイン済みテストユーザーに対してアラートが表示されています。この赤く表示されている部分をクリックします。
- エラー内容として以下が表示されます。
これはProvisioning設定を行う前にユーザーをアサインしていたため、Provisioning対象とならないということを意味しています。User was assigned this application before Provisioning was enabled and not provisioned in the downstream application. Click Provision User.
- Provision Userをクリックします。
- Provision Userによってどのようなことが行われるのか説明が表示されるため、OKをクリックします。
- Assignments画面をリロードするとエラーが解消されていることが確認できます。編集ボタンをクリックします。
- 以下のようにOktaでアサインしたユーザーがGWS上のユーザーとしてどの様な属性値が渡されているかが確認できます。この時GWSの組織部門を意味するOrganizational unitが
/となっており最上位である組織部門が選択されています。
- 本来はテスト用に作成した組織部門を選択したいので以下のように
/Okta SSO Testを選択し、Saveをクリックします。
この操作は今後ユーザーを個別アサインもしくはグループアサインする際に適切な組織部門となるように選択する必要があります。
- Okta管理画面>Directory>Peopleからテストユーザーを表示し、ProfileタブのEditをクリックします。
- Update User Attributesが機能することを確認するためにテストユーザーのFirst nameを
UserからUser01に変更し、Saveをクリックします。
- GWS管理画面でテストユーザーを確認し、Test User01と更新されていることを確認できればUpdate User Attributesが正しく機能しています。
必要に応じてCreate Usersの確認としてGWSに存在しないテストユーザーをアサインし作成されるかを確認したり、Deactivate Usersにチェックを入れた上でテストユーザーのアサインを外しGWS管理画面でユーザーが無効状態となるかを確認します。
GWSアカウントはあくまで無効になるだけです。そのためGWSアカウントの削除やそれに伴うGmailやGoogle Driveのデータ移行の手続きはOkta連携前と変わらずGWS管理画面で行う必要があります。
Sync Passwordオプションについて
このオプションではOktaのパスワードをGWS側に設定することができます。ユーザーは普段はSAMLによってSSOが可能となるためGWS側のパスワードを直接利用することはありません。しかし、万が一の備えとしてOktaがサービスダウンし一時的にSSO連携を解除する場合にユーザーが直接ログインする際にOktaのパスワードと同一であればオペレーションがスムーズとなるため設定をしておくと良いと思います。
設定するには、Provisioning to Appの画面でSync Passwordにチェックを入れ、さらにオプションでSync Okta Passwordを選択し、Saveします。
Push Groupsについて
Provisioning設定をするとOktaのグループをGWSにプッシュしたり、GWS上の既存のグループとOktaのグループを連携させることができます。これにより連携されたグループのメンバー管理をOkta側で行うことができるようになります。
Push Gropsに利用するグループはAssignmentsで利用するグループとは分ける必要があります。同じグループを利用することはサポート対象外となります。
設定手順は以下のとおりです。
- Push Groupsタブ内のPush GroupsボタンからFind gropus by nameをクリックします。
- グループ名を入力し選択後にSaveをクリックします。
今回選択したグループはGWS上にはないためNo match foundと表示されています。
- 以下のようにPush StatusがActiveとなれば成功しているはずです。
- GWS管理画面を確認し、グループが作成されていることを確認します。
GWSのグループはメーリングリストとして機能するため、OktaからPushする際にグループ名が@マークより前に使用できない文字列の場合はGroup name can not be converted into a valid email.というエラーとなります。
組織部門の更新について
Provisioning設定によりOktaでユーザーやグループをアサインする際にGWS側の組織部門を選択できるようになりましたが、GWS側で組織部門を変更したり追加した場合はOkta側には自動的には反映されません。そのため、以下の操作を行うことでOkta側に反映させることができます。
- GWS管理画面で新しい組織部門を作成します。
- Okta管理画面>Applications>Applications内のMoreからRefresh Application Dataをクリックします。
- 完了すると一瞬以下のような内容が表示されます。列挙されるアプリケーション名は連携しているSaaSによって変化します。
Success! Downloading application information for Okta Access Requests, Google Workspace, Okta Help Center, AWS IAM Identity Center, Microsoft Office 365 and AWS Account Federation instances.
- Google WorkspaceのAssginmentsからアサイン済みのユーザーもしくはグループの編集ボタンをクリックします。
- Organizational unitの項目をクリックすると選択肢に1.で作成された組織部門が選択可能となっています。
全体適用について
これまでは組織部門を限定し、SSOやProvisioningを設定してきましたが全ユーザーに対して適用できる状態となったら以下の作業を実施します。
- GWS管理画面からセキュリティ>認証>サードパーティのIdPによるSSOをクリックします。
- SSOプロファイルの割り当ての管理で最上位の組織部門をクリックします。
- 組織向けのサードパーティのSSOプロファイルを選択し、保存をクリックします。
- オーバーライドしているテスト用に作成した組織部門については組織部門内のユーザーを他の組織部門に所属させてから削除するかオーバーライドではなく上位組織部門から継承するように設定を変更します。
以上でGWS全体に対して例外なくSSOとProvisioningの対象とすることができました。
全体適用後の新入社員対応の変化について
OktaによるSSOやProvisioningを全体適用した以降は新入社員については以下のような対応の変化があります。
- 情シスが新入社員のOktaユーザーを作成する際には一時パスワードを発行しアクティベーションを実施する
- Oktakアクティベーションメールを起点とした操作が行えなくなる
- 入社オリエンテーションでは新入社員にOktaのログインURLとメールアドレスおよび発行した一時パスワードを伝える必要がある
- 新入社員はまずOktaアカウントのセットアップを実施、その後GWS含むOkta連携しているSaaSへアクセスする
多くの組織ではOktaと連携前はGWSの一時パスワードを伝えてまずGmailにアクセスしてもらい各種SaaSの招待メールからセットアップをする流れが多いと思います。このスタートがGWSからOktaに変わるようなイメージです。
入社オリエンテーション担当者とはこのような変化があることを事前に擦り合わせておき、オリエンテーションマニュアルを更新するなど必要な対応をしておきましょう。
まとめ
OktaとGWS連携と関連する内容を記事にしてみました。この内容をマスターできれば他の多くのSaaSの連携においても応用が効くはずです。なによりGWSは連携対象を限定できるためエラーが発生しても影響範囲が最小限で済むために慌てずに済みます。むしろここでエラーを経験して経験値を稼ぐんだと言う気持ちのほうがいいかもしれませんね。
今日お伝えしたいことはそんな感じです。次回はGWSとも関係が深いGoogle Cloud Platformとの連携について記事にします。
