はじめに
こんにちは、ネクストモード株式会社テクニカルサポート担当です。
本シリーズでは、各社の Okta テナントとグループ共通アプリを管理するテナントを連携する Hub & Spoke 構成を取り上げています。Org2Org を使った SSO の構築からユーザーのプロビジョニング、運用上のポリシー調整まで、3回に分けて紹介します。
前回の記事では、OIDC を利用した Org2Org 構成で、複数の Okta テナント間の SSO を実現しました。ただし、ユーザーは両方の Org に事前に作成しており、入社や異動に伴うユーザーの作成・更新はそれぞれの Org で行う必要がありました。
今回は、IdP Org から SP Org へユーザーをプロビジョニングすることで、こうした管理作業の自動化を目指します。接続には OAuth 2.0 と鍵の自動ローテーションを利用し、API トークンの未使用による失効や、手動での鍵管理に配慮した構成を紹介します。
本記事はシリーズの第2回です。各記事の内容は以下のとおりです。
- 【Okta】Org2Org と OIDC で複数テナント間の SSO を実現する
- 【Okta】OAuth 2.0 と鍵の自動ローテーションで構成する Org2Org プロビジョニング設定（本記事）
- 【Okta】Org2Org のサインインと再認証を IdP Org に集約する
OAuth 2.0 を利用する理由
プロビジョニング接続の認証方式には、API トークン方式と OAuth 2.0 方式の2つがあります。今回は OAuth 2.0 方式を利用します。
API トークン方式は、あらかじめ発行したトークンを設定して接続する方法です。ただし、Okta の API トークンは、使用するたびに有効期限が更新されますが、30日間使用されないと失効します。失効した場合は、トークンを再発行して設定し直す必要があります。
OAuth 2.0 方式では、継続的なプロビジョニングに API トークンを使わないため、未使用による失効を気にせず運用できます。また、公開鍵を URL から動的に取得する自動ローテーションにより、手動での鍵管理の負担も軽減できます。
SSO とプロビジョニングの認証方式は、個別に選択できます。例えば、SSO に SAML、プロビジョニングに OAuth 2.0 を利用する構成も可能です。
それでは、実際の設定方法を見ていきましょう。
設定方法
本記事でも、認証を担う Spoke 側のテナントを「IdP Org」、認証を委ねる Hub 側のテナントを「SP Org」と呼びます。
Provisioning 設定
- IdP Org 側の Org2Org アプリ「SP Org」の Provisioning タブから Configure API Integration をクリックします。
- Enable API integration にチェックを入れ、以下の設定とします。
- Authentication Scheme：OAUTH Auto-Rotation（recommended）
- Target Org Client ID：手順11で入力
- Import Groups：チェックを外す
- Client Public Key URL：Copy ボタンからURLをコピーします。この値は、手順6で SP Org 側の API Services アプリ「Org2Org-Provisioning」に設定します。
- SP Org 側で Applications から Create App Integration をクリックします。
- Classic experience タブ内の API Services を選択し、Next をクリックします。
- General Settings で以下のように設定し、Save をクリックします。
- App integration name：Org2Org-Provisioning
- Client definition：Use Okta-generated client ID
- SP Org 側で作成した API Services アプリ「Org2Org-Provisioning」の Public keys を編集し、Use a URL to fetch keys dynamically に手順2でコピーした Client Public Key URL を反映し、Save をクリックします。
- Client Credentials を編集し、Client authentication は Public key / Private key を選択し、Save をクリックします。Client ID をコピーします。
- Admin roles タブに遷移し、管理者権限を割り当てます。今回の検証では Super Administrator 権限を使用しましたが、本番環境では必要なロール・リソース範囲に制限しましょう。
- Okta API Scopes タブに遷移し、以下の権限を付与します。
- okta.users.manage
- okta.groups.manage
- General タブに遷移し、General Settings 内の Proof of possession が以下のように有効になっていることを確認します。無効の場合は Edit をクリックして有効化し、Save をクリックします。
- IdP Org 側の Org2Org アプリ「SP Org」の Provisioning タブに戻り Target Org Client ID に手順7でコピーした値を貼り付けし、Save をクリックします。
- 正常に設定が保存できた場合は Provisioning to App 設定画面が表示されます。
- Provisioning to App の Edit をクリックし、必要なオプション設定を選択し、Save をクリックします。以下は検証時の設定です。
- Create Users：有効
- Update User Attributes：有効
- Deactivate Users：無効（本番運用では有効想定）
- Sync User Password：有効
- Password type：Sync Okta Password
- Attribute Mappings の Initial status を編集します。検証では、すべてのユーザーに一律で同じ値を適用するため、以下のように設定して Save をクリックしました。
- Same value for all users ：active_with_pass
- IdP Org 側の Org2Org アプリ「SP Org」に、SP Org にはまだ存在しないユーザーを割り当てます。SP Org 側の Directory > People を開き、ユーザーが作成されていることを確認します。
Initial status について
Initial status は、IdP Org から作成・リンク・再有効化されたユーザーが、SP Org 側でどのステータスになるかを決める属性です。今回の検証では、対象ユーザーを一律で同じ状態にしたかったため、「すべてのユーザーに同じ値」を選び、active_with_pass を指定しました。active_with_pass を指定すると、ユーザーはアクティブな状態で作成され、あわせて一時パスワードが発行されます。
今回は、手順13で Sync User Password を有効にし、Password type に Sync Okta Password を指定しています。この設定では、一時パスワードはユーザーのサインイン時に同期されたパスワードで上書きされます。本番環境では、想定するサインイン経路とあわせて動作を確認してください。
参考リンク
まとめ
今回は、Org2Org のプロビジョニング接続を OAuth 2.0 方式で構成し、鍵の自動ローテーションを有効にしました。API トークン方式のように、トークンが未使用のまま失効することを気にせず運用できます。
あわせて、Provisioning to App の設定と Initial status を確認し、IdP Org 側で割り当てたユーザーが SP Org 側に作成されることを確認しました。
次は運用編として、認証・登録ポリシーと再認証の調整を扱います。SP Org 側で追加の認証や Authenticator 登録が求められる場合の対処を紹介する予定です。
Okta に関するお問い合わせ
「グループ会社のユーザー管理をどこまで自動化できるか知りたい」「Org2Org の構成や運用を自社の環境に合わせて検討したい」とお考えの方は、ぜひネクストモードへご相談ください。
