はじめに こんにちは、 ネクストモード株式会社 のSaaSおじさん久住です...
当エントリは『ネクストモード フルリモート業務を実現するSaaS活用＆カルチャー Advent Calendar 2024』22日目のエントリです。
こんにちは、ネクストモードの杉山です。
今回の記事では、Advent Calenderのサブタイトルにも含まれる「SaaS活用」の一例として、Okta WIC（以降、Okta）のAnything-as-a-SourceによるHRシステムからのユーザプロビジョニングの実際をご紹介いたします。
一般的に、企業において、もっとも信頼するべきで、矛盾のないIDの源泉は人事データとしてHRシステムに保管されていることと思いますが、そのデータを起点にOktaやADなどのIdentityを自動で構成できたら嬉しいですよね。きっと嬉しいと思います。
これまでも、OktaではActive DirectoryやLDAP、CSVなどの各種ディレクトリ、またはOkta Integration Network（OIN）に含まれる一部限定されたHRシステムとのいわゆるOut of the Box連携機能が提供されてきましたが、残念ながら、現状それらの連携機能が提供されていないシステムとの間では、以下のいずれかの方式により、利用者が独自に連携機能を実装する必要がありました。
- ミドルウェアによる連携 - HRシステムとOktaとの間に設置するミドルウェアを購入し、両者をAPIなどにより仲介する。
- カスタムコードやスクリプトによる連携 - Core Okta APIなどを操作するカスタムコードを作成し、前述のミドルウェアと同様の働きをするクライアントプログラムを準備する。
これらの方式では、連携の内部処理（データ正規化やマッピング、差分データ同期のハンドリングなどなど）に関する一切をクライアントサイドで担保する必要があり、実装までには、時間とコストがかかるものでした。
このような課題を解決すべく、Anything-as-a-Source（XaaS）がOktaから提供されました。
XaaSを利用することで、前述の連携機能に関する利用者の負担が以下の観点で軽減されることが期待できます。
- カスタムコードによるCore Okta APIの操作に代えて、新しく用意されたXaaS APIをImport pipelineと組み合わせて使うことにより、連携の内部処理をクライアントサイドから解放することができます。
- Okta Workflowsのカード向けに新しく解放されたXaaS APIを利用することで、短時間、ローコストであらゆるHRシステムとのHR-Drivenな連携処理を実現することができます。
Import pipelineとは：HRシステムから渡されるユーザ情報をOktaへプロビジョニングするためには、データの正規化やマッピング、フィルタリングなど様々な準備工程が必要となりますが、それらをOktaが適切に処理してくれる機構です。
少し前置きが長くなってしまいましたが、HRシステムとしてSmartHRを使って、Okta XaaS HR-Drivenな世界を検証してみたいと思います。
参考: XaaSを含む、HRシステムとOkta間での一般的な連携方式の一覧については、こちらのOkta公式ブログに情報がまとめられています。
テーブルオブコンテンツ
- 検証構成
- 前提条件
- 準備
- Custom Identity Sourceアプリケーションの追加と設定
- Okta Workflowsサンプルフローの作成
- SmartHRサンプルデータの作成
- サンプルフローの実行
- 最後に
検証構成
本記事では、以下のような構成で検証を行います。
- HRシステム - SmartHR
- システム連携 - Okta Workflows
- API
- SmartHR - SmartHR API（Webhookではなく、APIを使います。）
- Okta - Okta XaaS API（Oauth 2.0のスコープはokta.identitySources.manageとokta.identitySources.readになります。）
HRシステムのWebhookを使った、同期的なプロビジョニングも可能ですが、本記事ではスケジュールされたインポートタスクを定期的に実行する非同期的なプロビジョニングを試すことにします。
前提条件
本記事での検証はOktaおよびSmartHRのテナントをすでにお持ちであることを前提としています。
Oktaに関しては、30日間試用することができるトライアル用テナントをこちらのリンクから即時払い出すことが可能です。
また、OktaやSmartHRに関する基本的な操作方法については、本記事では説明をしていません。
準備
検証を進めるにあたっては、以下の各事項について、それぞれ事前の準備が必要となります。
- XaaS機能フラグの有効化 - 本ブログ執筆時点でXaaSはLimited Early Accessという扱いになっています。そのため、Okta Support Caseから、明示的にその機能を有効化してもらう必要があります。Okta Support Caseの起票方法については、こちらのOktaナレッジが参考になります。
- SmartHR API用のアクセストークン - SmartHRのAPIを操作するためには、アクセストークンが必要となります。アクセストークンの作成はこちらのSmartHR公式ヘルプが参考になります。
- Okta Workflows Okta Connector - Okta Workflowsで利用するOkta Connectorを準備してください。作成手順については、こちらのOktaドキュメントが参考になります。
- Okta Workflows API Connector - Okta Workflowsで利用するSmartHR APIを操作するためのAPI Connectorを準備してください。作成手順については、こちらのOktaドキュメントが参考になります。
Custom Identity Sourceアプリケーションの追加と設定
Okta WorkflowsのXaaS APIで操作対象となるCustom Identity Sourceを作成します。
アプリケーションの追加
Okta管理コンソールからアプリケーション > アプリケーション へ移動しアプリカタログを参照をクリックします。
Custom Identity Sourceを検索し、統合を追加をクリックします。
アプリケーションの設定
追加したアプリケーションに可読性の良い名称を付けます。（例：SmartHR Identity Source）
プロビジョニングタブを選択し、設定 > 統合と移動し、編集をクリックします。
API統合を有効化にチェックを入れ、グループをインポートのチェックを外します。（今回の検証ではグループのインポートは行いません。）
保存をクリックします。
同じくプロビジョニングタブ配下の設定 > Oktaへと移動し、ユーザの作成・照合の編集をクリックします。
完全一致を自動確認、新しいユーザーを確認、新しいユーザーを自動的にアクティブ化のチェックを入れます。
保存をクリックします。
同じセクションのプロファイルおよびライフサイクルのソーシングの編集をクリックします。
Custom Identity SourceがOktaユーザーを提供するのを許可にチェックを入れます。
一時停止しているOktaユーザーを再アクティブ化、非アクティブ化されているOktaユーザーを再アクティブ化にチェックを入れます。
保存をクリックします。
プロファイルの設定
Custom Identity Sourceアプリケーションのプロファイルにはデフォルトで、以下の属性が定義されています。
- Username
- First Name
- Last Name
- Second Email
- Mobile Phone
今回の検証では、デフォルトに加えて以下の属性を追加します。
| 表示名 | 変数名 | データのタイプ | 属性のタイプ |
| 部署 | department | string | カスタム |
| 役職 | title | string | カスタム |
| 表示名 | displayName | string | カスタム |
Okta管理コンソールからディレクトリ > Profile Editorと移動し、作成したCustom Identity Sourceのプロファイルを選択します。
上記、表のとおり属性を追加します。
属性の追加が完了したら、マッピング > ユーザーマッピングの設定をクリックします。
Custom Identity SourceからOktaに対するマッピングの設定について、上記で追加した属性を以下のようにマッピングします。
- appuser.department → department
- appuser.title → title
- appuser.displayName→displayName
マッピングの設定が完了したら、マッピングを保存をクリックします。
Okta Workflowsサンプルフローの作成
SmartHRのAPIとOkta XaaS APIを繋ぐ、Okta Workflowsフローを作成します。
OAuth 2.0スコープの追加
Okta管理コンソールからアプリケーション > アプリケーション へ移動し、Okta Workflows OAuthアプリケーションを検索します。
Okta Workflows OAuthアプリケーションのOkta APIのスコープタブを選択し、以下のスコープについてそれぞれ、付与をクリックします。
- okta.identitySource.manage
- okta.identitySource.read
付与をクリックすると、付与されたと表示され、付与は取り消すに遷移します。
サンプルフローのインポート
こちらのGitHubレポジトリから、xaasBlog.folderファイルを端末へダウンロードします。
Workflowsコンソールから、フローインポート用の任意のフォルダを作成します。
作成したフォルダ名の右側にある3つのドットをクリックし、Importをクリックします。
ダウンロードしたファイルを選択し、フローのインポートを行います。
インポートの結果、フォルダ内には以下の計6フローが作成されるはずです。
- [main] Scheduled Import Active Users - SmartHRからOktaに対してアクティブステータスのユーザをインポートするフロー
- [main] Scheduled Import Deactive Users - SmartHRからOktaに対して非アクティブステータスのユーザをインポートするフロー
- [util] Delete Target Import Session - 古いインポートセッションを削除するフロー（Helperフロー）
- [util] Filter Active Users - アクティブステータスのユーザをフィルタするフロー（Helperフロー）
- [util] Filter Deactive Users - 非アクティブステータスのユーザをフィルタするフロー（Helperフロー）
- [util] Profile Map to Okta Format - SmartHRから受け取ったユーザデータをOktaのプロファイル形式に整形するフロー（Helperフロー）
Okta Connectorの設定
前項でインポートしたフローのうち、以下3つのフローにはOkta Connectorカードが配置されていますので、お使いのOktaテナントで準備したOkta Connectorを指定してカードを更新してください。
- [main] Scheduled Import Active Users（List Import Sessions、Create an Import Session、Bulk User Import、Trigger Import Sessionの計4つのカードでOkta Connectorを使用しています。）
- [main] Scheduled Import Deactive Users（List Import Sessions、Create an Import Session、Bulk User Import、Trigger Import Sessionの計4つのカードでOkta Connectorを使用しています。）
- [util] Delete Target Import Session
Okta Connectorをアップデート後、アップデートしたカードのOptionをクリックします。
Applicationから作成したCustom Identity Sourceアプリケーションを選択し、Saveをクリックします。
→
Custom Identity Source URLの修正
前項でインポートしたフローのうち、以下3つのフローにはSmartHRのAPI Endpointが記載されたAPI Connectorカードが配置されていますので、お使いのOktaテナントで準備したSmartHR向けのAPI Connectorを指定してカードを更新してください。
SmartHRのAPIではAuthorizationヘッダーにBearerトークンを指定することで認証が可能です。Okta WorkflowsのAPI ConnectorではAuth TypeにCustom、Header NameにAuthorizationを指定することで、BearerトークンをAPIへ渡すことが可能です。
また、URLの[change me]部分をお使いのSmartHRテナントに合わせて修正してください。
SmartHR サンプルデータの作成
SmartHRでユーザのサンプルデータを作成します。
作成する際には、Oktaへのプロビジョニングの際に必須となる以下の属性に必ず値を設定してください。
- 氏
- 名
- メールアドレス
- 在籍状況（在職中を選択してください。）
また、以下の属性にはそれぞれ任意の値を入れると、Oktaのユーザプロファイルへのプロビジョニングを確認することができます。
- 部署1
- 役職1
サンプルフローの実行
Okta Workflowsを操作し、SmartHRの人事データがどのようにOktaへ伝搬するか検証していきます。
サンプルフローの実行
Okta Workflowsのサンプルフローを実行します。
Okta Workflowsコンソールから、以下の4つのフローに対してON/OFFトグルを操作し、有効にします。
- [main] Scheduled Import Active Users
- [util] Delete Target Import Session
- [util] Filter Active Users
- [util] Profile Map to Okta Format
[main]Scheduled Import Active Usersフローを開き、画面右上のRunをクリックします。
フローが正常終了すると、画面右側のExecution HistoryにSuccessと表示されます。
Oktaへのプロビジョニング確認
前項で実行したサンプルフローによって、どのようにOktaへ人事データが伝搬したかを確認していきます。
Okta管理コンソールからアプリケーション > アプリケーション へ移動し、Custom Identity Sourceアプリケーションを検索します。
アプリケーションの割り当てタブを選択し、SmartHRで作成したユーザが割り当てられていることを確認します。
同じくOkta管理コンソールからレポート > モニタリングのインポートへ移動します。
インポートモニタリング画面の左上部にフィルタがあるので、Custom Identity Sourceアプリケーションを選択します。
インポートの記録としてスキャンユーザ数、更新のあり、なし などを確認することが可能です。
同じくOkta管理コンソールからディレクトリ > ユーザーへ移動し、サンプルフローによってプロビジョニングされたユーザーを開きます。
プロファイルタブを選択し、SmartHRで指定した属性値がOktaのユーザプロファイルにもプロビジョニングされていることを確認します。
表示名（displayName）は属性 名（firstName）と姓(lastName)の値からフローが自動生成しています。
Oktaへのデプロビジョニング確認
プロビジョニングに合わせて、デプロビジョニングも確認してみます。
SmartHRでサンプルユーザの在籍情報を退職済みに更新します。
本検証におけるWorkflowsサンプルフローでは、SmartHR側の属性 在籍情報の値を元にOktaへのプロビジョニング、デプロビジョニングを制御しています。
Okta Workflowsコンソールから以下2つのフローを有効にします。
- [main] Scheduled Import Deactive Users
- [util] Filter Deactive Users
[main]Scheduled Import Deactive Usersフローを開き、画面右上のRunをクリックします。
フローが正常終了したことを確認し、Okta管理コンソールから当該サンプルユーザを開きます。
ステータスが無効化と表示されていることを確認します。
最後に
今回の記事は以上で終了です。お楽しみいただけましでしょうか。
検証を通じて、ノーコードによる自動化されたプロビジョニングとデプロビジョニングの実現性を体感いただけたのではないかと思います。
こういった機能を利用することで、組織内のユーザオンボーディングやオフボーディングをより容易に、かつ確実で組織内で一貫したものとすることができます。
さらに、例えばActive DirectoryへのユーザプロビジョニングもOktaではOut of boxで可能なため、HRシステム→Okta→Active Directoryといったプロビジョニング構成も比較的、簡単に構築することが可能です。
OktaとActive Directoryの連携に関する情報はこちらのNextmode Blogが参考になります。
今回の記事は以上です。
明日23日目は町野さんによるエントリとなります。お楽しみに！
