はじめに
midPoint by OpenStandia Advent Calendar 2019 の23日目は、midPoint（+ Keycloak）を実際に NRI 社内のとあるシステムに導入して活用している話を紹介します（Keycloak についてはこちらの記事などを参照していただければと思います）。
プロジェクト概要
はじめにどういうシステムに導入したのか簡単に紹介しておきます。開発管理統合サービス aslead の NRI 向け環境の IAM （Identity & Access Management）に、 midPoint と Keycloak を適用するというプロジェクトでした。
aslead とは 
aslead とは、チャットツール、タスクの管理、ナレッジの共有など、業務に必要な機能をオールインワンで提供する NRI のパッケージサービスで、米国の Mattermost 社のチャットツールである Mattermost のほか、オーストラリアの Atlassian 社が提供するタスク管理の Jira と、ドキュメントやナレッジを共有する Confluence の3つをベースにしています（詳細はこちら： https://aslead.nri.co.jp/ )。社外だけではなく、NRI 社内にも数年前から導入されています（紹介記事）。NRI 社内のシステム案件やコンサル案件のプロジェクト管理やコミュニケーション基盤として活用されています。
As-Is / To-Be
aslead そのものは以前から NRI 社内でも展開されていましたが、以下のような状態でした。
- テナント単位に各サービスを構築
- 認証は各プロダクト毎にローカル認証（SSO なし）
- ID管理は Excel による申請書ベース
- NRI オフィス内のネットワークからのみアクセス可（AWS 上で稼働はしていますが、Direct Connect でオンプレ環境からのみ接続可能）
- 利用ユーザーは社員・派遣社員・ビジネスパートナー
これを今回のプロジェクトでは、以下のように大幅にパワーアップ
するというものでした。
- テナント横断サービス（Mattermost、認証用 LDAP など）を共通サービス化
- SSO によるセキュリティ・利便性向上
- ID 管理を自動化・ガバナンス強化
- 社内ネットワークだけではなく、インターネットからのアクセスにも対応してスマートフォンやテレワークでの利用も可能に
- 利用ユーザーは社員・派遣社員・ビジネスパートナーだけでなく、社外のビジネスパートナーや顧客なども対象に
課題
NRI 社内には既に ID 管理システムがあるものの、aslead が対象とする全 ID が管理されているわけではありませんでした。SSO についても同様に、既に AD/ADFS や Azure AD が導入されており実現されていましたが、aslead が対象とする全ユーザーが使えるわけではありませんでした。選択肢として、既存の ID 管理システム側を改修して aslead が対象とする ID を管理し、AD・Azure AD でも管理対象とするという方式も考えられますが、改修コストや運用コスト面の問題もありなかなか厳しいという感じでした。通常の社内システムと異なり、aslead の場合は社員以外の利用者数の方が多いという特性があり、特に AD・Azure AD ですべて実現しようとすると結構な費用がかかる計算のようです... 
aslead ID の誕生
自分が所属する NRI OpenStandia チームでは、SSO を実現する Keycloak を既に扱っており、また midPoint もある程度評価が済んでいて実際に使ってみようという状態でした。丁度タイミング良く aslead チームと同じ部署だったこともあり、aslead チームとタッグを組み、これらの OSS を活用して aslead ユーザーを対象とした統合認証基盤（aslead IDと名付けました）をやっていこう
という話になりました。
前述のとおり、既に社内に ID 管理システムはありますのでそこと連携した構成となります。既存 IDM を源泉とし、そこで管理されている ID 情報や組織情報を取り込みつつ、足りない情報を aslead ID で管理するというものです。SSO についても同様に、既に AD・Azure AD で管理されているユーザーに関しては認証をそちらに委譲できるように ID フェデレーションも行います。
システム構成
検討の結果、以下のようなシステム構成となりました。自分が担当したのは「構築範囲」と記した箇所です。認証基盤を共通サービスとして構築し、aslead の全テナントの IAM を実現します。
- 既存の ID 管理・AD から必要なデータ（ユーザー・組織）を源泉データとしてインポート
- aslead 全テナント用の LDAP を構築し、そこに ID プロビジョニング
- aslead の全テナントと接続して SSO を提供
- AD・Azure AD で管理されているユーザーには、ID フェデレーションを提供
何気に AWS・Azure・自社データセンターを使ったマルチクラウド構成になっています
スケジュール
ざっくり以下のような感じでした。スモールスタートということで、IAM 部分は自分ひとりチームでスタートし midPoint と Keycloak を含む認証基盤周辺の設計・構築を行っていきました。IDM 案件としては比較的タイトな方ではないでしょうか？
- 2018/09～2018/10： 要件整理・プロトタイプ実装
- 2018/11～2019/01： 開発・構築・テスト・部内でお試し利用
- 2019/02～2019/03： 先行ユーザーに開放・フィードバックを得て改善
- 2019/04～2019/07： 順次社内展開（既存環境のテナントを移行）
利用状況
（システム構成には書いていませんが）Prometheus や Grafana も導入しており色々可視化しています。その中で登録 ID 数の推移もリアルタイムに見れるようにしています。aslead が全社的に使われつつあることもあり、2019/12 時点で 20000 近くまでと拡大中です 
登録プロジェクト数（midPoint内でプロジェクト組織として登録しています）の方も400以上と順調に増加しています
実際に midPoint を使ってみた感想
過去に IDM 案件を経験したことがありますが、それらと比べてカスタム開発量が圧倒的に少ないと感じました。これは、midPoint が以下のような特徴を備えているからだと思います。
- 標準で豊富なデータモデルがある
- ユーザ、組織、ロールとそれらのサブタイプ
- 組織階層を表現可能
- ロールベースプロビジョニングを基本としている
- aslead の要件（プロジェクトに対して、ユーザーが利用申請を出して承認を得て参加することで、関連するコラボレーションスペースに参加可能となる）とマッチ
- 利用ユーザー向けの UI を備えている
- ユーザー登録
- パスワード管理
- リクエストロール（ワークフロー申請）
- ワークフロー承認
- etc.
スクラッチ開発や ForgeRock IDM（旧OpenIDM）利用の場合は結構な量の作りこみが必須であり、自分達の経験上、要件定義後の開発・構築に半年～1年はかかることが多い印象です。
ただし、メリットを享受するには midPoint の思想に合わせて設計することがポイントかなぁと感じました。midPoint が最初からデータモデルや UI を提供しているので、そちらに基本的に合わせることで効率化ができます。
また、midPoint をより使いこなすにはロール設計が肝だなぁ... という印象を持ちました。メタロールを活用した設計を行うことで設定をうまく集約化し、メンテナンスしやすくすることができます。
ここら辺のロール設計の話は、midPoint by OpenStandia Advent Calendar 2019 の下記記事あたりを参考にしていただければと思います。
おわりに
今回は、midPoint と Keycloak を実際に社内システムに導入した話をご紹介しました。midPoint、Keycloak は OSS で提供されており、カスタマイズにも柔軟に対応できます。商用の IAM 製品や Azure AD などの IDaaS だけだと要件・コスト的に実現が難しいところを埋めるのにピッタリかなと思います。
明日の記事では、2019年10月にベルギーのブリュッセルにて開催された EU-FOSSA Hackathon について紹介したいと思います。midPoint の今後の方向性、ワールドワイドでの活用事例の話を聞くことができましたので共有したいと思います。お楽しみに