現在、ある案件でOktaからHENNGEへの認証基盤のリプレースを検討している。
背景や現在までのリサーチ情報をブログにまとめておこうと思う。

▼背景

今回リプレースを検討している一番の理由はコストカットだ。

現在この企業（以下A社と呼ぶ）では約130人でOktaを利用しており、簡単にコスト比較をすると
– Okta 年間契約 3,599,960円
　（SSO, Universal Directory, Advanced Lifecycle Management, Adaptive MFAの4項目）
– HENNGE 年間契約 720,000円
　（HENNGE IdPプランの契約）
となり、約288万円の削減になる。

もちろん何事も安ければいいという話ではなく、
SCIM連携/プロビジョニングできるサービスがOktaよりもかなり制限される点や、
Okta Workflowsのような自動化機能がHENNGEにはないことは留意すべきだ。

ただ、A社では上記を殆ど活用できておらず、仮に構築しても運用/メンテナンスのリソースがなかったため
今回のリプレースに踏み切った、というのが大きな背景だ。

▼HENNGEについて

HENNGEではAccess Controlという呼び名で認証基盤を構築することができる。

A社では基本的にシステムを利用するユーザー情報はすべてグループウェアであるGoogle Workspaceに集約されており、且つ従来Oktaの認証はID/PW+Okta Verifyのプッシュ通知で行っていた。

そしてHENNGEでは↓のように連携＆認証設定を組むことができ、つなぎ込めるサービスもA社の利用してるものは網羅されているため「概ねOktaと同じことはできそう」という機能感である。
（ちなみにHENNGEが連携可能なサービス一覧はこちらにリストアップされている。）


実際にHENNGE上で上記を構築するとき、イメージとしては↓の通りになる。
まずは必要なポリシーを用意する。このポリシーに”利用サービス”と”認証方法”を設定する。
A社の場合は認証方法はID/PWとアプリ通知を全ポリシー共通で設定し、部門ごとにポリシーを用意した。そしてユーザーに対してポリシーを割り当てていく形だ。

Oktaからのリプレースにおける留意点としては
1. Oktaの認証ポリシーのようにIf/Thenで（OS対象や認証の順番に）優先順位をつけられない点
2. 1ユーザーに1ポリシー、という形式が若干わかりづらい点
3. デバイス証明書の配布が複雑な点（A社では実装を断念した）
あたりだと考えている。

▼所感（導入の難易度など）

上記踏まえ、簡単な所感としては
– Oktaを認証基盤として構築しきれていない状況であればHENNGEでも良さそう。
– SCIMや自動プロビジョニング等をゴリゴリ活用して業務効率化を図るなら絶対的にOktaが良い
というのが今回思ったところだ。

今回A社では幸いにもOktaが認証基盤として深く根付いていなかった（中途半端に浅い運用だった）ため
HENNGEを導入したほうが機能要件を一定満たしつつコストカットにつながるという結論に至った。

が、むしろこの事例は珍しい方だと思うので
個人的には中小企業で人数規模も増えてきて認証基盤を構築し始めたいくらいのフェーズで
まずHENNGEを検討してみるのが現実的なラインだと思う。