simpliSSO徹底解説：12モジュールの認証基盤導入で実際に何が手に入るのか——Azure AD連携から最後のレガシーERPまで

社内システムが数十に及ぶ企業がなぜ統合された認証基盤を必要とするのか。私たちはこの理由について、すでに2本の記事を書いてきました。1本目はエンジニアリング組織に静かに積み上がる「アイデンティティ負債」について、2本目は社員が24個のパスワードを持つ会社には24個の攻撃経路があるという話です。そして8月には3本目として、パスキーの時代には「登録」こそが新しい攻撃面になること、そして対策のほぼすべてがIdP側にあることを論じました。

本稿は、これらの議論の土台にある製品そのものの話です。simpliSSOは、Simplicoが構築して引き渡す統合認証ポータルです。中核はAuthentikによるIdPで、貴社のMicrosoft 365 / Azure ADテナントとフェデレーションし、すべての社内アプリケーションの前段に立ちます。以下では、実際に何が含まれているのか、12のモジュールがどう組み合わさるのか、追加で書かれるコードが何をしているのか、そして同じくらい重要な点として、何が個別案件ごとのスコープで、何が明確に対象外なのかを整理します。

1. simpliSSOが前提としている現場の姿

製品ページに掲載されている参照構成は、机上の例ではなく実在の形です。24サービス、3プロトコル、12機能モジュール、本番稼働まで10週間。 しかもこの24サービスは、すべてが新しいWebアプリというわけではありません。タイやASEANに拠点を持つ中堅の製造業・流通業であれば見覚えのある組み合わせです。

• 新しい社内Webツール群(売掛金年齢表、倉庫レポート、文書管理、ITサービス、承認ワークフロー、プロジェクト報告)
• SAML2には対応しているものの、属性名が標準的でないレガシーERP——Infor M3
• WhatsApp BusinessやIP電話の3CXといった、そもそも「SSO」という概念を持たないコミュニケーションツール
• 京セラ製プリンター、ラベルプリンター、倉庫ロボットシステムなど、LDAPでしか認証できない、あるいはまったく認証できないハードウェア

最初のグループしか扱えない製品では、全体の半分程度しかカバーできず、最もリスクの高い残り半分が手つかずのまま残ります。simpliSSOは最初から、この混在環境全体を前提に設計されています。

2. 3つのプロトコル、3つの階層、1つのIdP

アーキテクチャはハブ型です。社員が誰であるかの「正」は引き続きAzure ADが持ちます。誰が何にアクセスできるかを判断し、トークンを発行するのはAuthentikただ1か所です。そして各アプリケーションは、自分が実際に話せるプロトコルでAuthentikに接続します。

flowchart TD
    STAFF["社員"] --> PORTAL["アプリポータル タイル表示"]
    PORTAL --> AK["Authentik IdP"]
    AK --> AAD["Microsoft 365 と Azure AD"]
    AAD --> AK
    AK --> POL["ポリシーとステップアップMFA"]
    AK --> OIDC["OIDCプロバイダー"]
    AK --> SAML["SAML2プロバイダー"]
    AK --> LDAP["LDAPアウトポスト"]
    OIDC --> MAP["プロパティマッピングでERPロールを付与"]
    MAP --> T1["第1階層 Webアプリ"]
    SAML --> T1
    LDAP --> T3["第3階層 プリンターとレガシー機器"]
    PORTAL --> T2["第2階層 WhatsAppと3CX アカウント紐付け"]

第1階層——OIDCとSAML2によるWebアプリ。 新しいアプリはOpenID Connectで署名付きJWTを受け取ります。レガシーERPはSAML2を使います。Authentikは両方のプロバイダーを並行して動かすため、新しい売掛金管理ツールも15年選手のERPも、同じ玄関からログインします。

第2階層——アカウント紐付けによるコミュニケーションツール。 WhatsAppや3CXはOIDCトークンを扱えません。そこで、初回ログイン時にカスタムのステージが各社員のWhatsApp番号と3CX内線番号をAzure ADのIDに紐付けます。ポータルのタイルからは、該当するトークや認証済みの電話クライアントへ直接遷移します。

第3階層——LDAPによるハードウェア。 OIDCにもSAML2にも対応しないプリンターやラベル機器は、Authentikが配置するLDAPアウトポストで認証します。それすらできないロボットシステムには、ポータルからのディープリンクでのみアクセスします。

上流はAzure ADが既定ですが、必須ではありません。AuthentikはGoogle Workspace、Okta、汎用のOIDC・SAML2プロバイダーとフェデレーションでき、閉域網やオンプレミス限定の拠点にとって重要な点として、既存のオンプレミスActive DirectoryやOpenLDAPにクラウドを経由せず直接接続できます。社員はMicrosoft 365、協力会社はLDAP、というように複数のソースを1つのフローに重ねることも可能です。

3. 12のモジュール

各モジュールは独立して見積もり・提供されます。3つは必須で、残りは契約前であれば段階導入や削除が可能で、価格は比例して調整されます。

モジュール	提供内容	標準的な案件での位置づけ
F-01 MS365 / Azure AD連携	Azureを上流IdPとし、MFAと条件付きアクセスをそのまま通す	必須
F-02 Authentikの導入と堅牢化	PostgreSQL、Redis、Nginx TLS、バックアップ、管理画面、ブランディングを含む本番用Docker Compose構成	必須
F-03 アプリケーション登録	全サービスをOIDCまたはSAML2アプリとして登録、グループ単位のアクセスポリシー、Blueprint YAMLによる設定のコード化	必須
F-05 ERPロール用JWTクレーム	会社コード、事業部、ERPロールをトークンに埋め込む	段階導入可
F-06 ステップアップMFA	指定した機微なシステムへのアクセス時にMFAを再要求	段階導入可
F-07 アプリポータル	利用者が権限を持つアプリだけをタイ語・英語ラベル付きで表示するFastAPIエンドポイント	段階導入可
F-08 WhatsAppアカウント紐付け	社員のWhatsApp番号をディレクトリのアカウントに紐付け	段階導入可
F-09 3CX内線紐付け	内線番号をアカウントに対応付け、認証済みのWebクライアントを起動	段階導入可
F-10 Infor M3 SAML2対応	AuthentikのSAML2出力をM3独自の属性名とNameID要件に変換	段階導入可
F-11 タイ語UI	ログイン、MFA、エラー、パスワードリセット画面のタイ語化とブランディング	段階導入可
F-12 テスト・QA・UAT	トークン失効、MFA失敗、SAML不一致などを含む全サービスのエンドツーエンドテスト	含む
F-13 ドキュメントと引き継ぎ	構成図、管理者向けランブック、入退社手順書(タイ語・英語)、ライブ引き継ぎセッション	含む

この表で注目すべき点は2つあります。第一に、必須の範囲は本当に小さいということです。Azure AD連携、堅牢化されたインストール、そしてアプリ登録だけです。「Webアプリのログインを1つにまとめたいだけ」という企業はそこで止めて構いません。第二に、段階導入可能なモジュールの多くは、実際の環境には必ず「言うことを聞かない」システムが少なくとも1つあるから存在しています。属性名が独特なERP、SSOの概念を持たない電話システム、現地語のログイン画面を必要とする現場スタッフ、といったものです。

4. カスタムPythonレイヤー——そしてそれが貴社の資産になる理由

simpliSSOのうち既製のAuthentikではない部分は、Authentikの内部でエクスプレッションポリシー、プロパティマッピング、Djangoステージとして動く薄いPythonレイヤーです。別途運用する外部サービスはなく、このPythonコードはすべて最終支払いをもって顧客の知的財産になります。

クレームの整形(F-05)。 プロパティマッピングが、M3の会社・事業部・ロールや売掛金システムのアクセスレベルといったERPの文脈をトークンに直接書き込みます。アプリケーションは自前の権限テーブルを持つ代わりに、トークンからロールを読みます。これが「ログインのためのSSO」と「認可のためのSSO」の違いです。社員がAzure AD上で異動すれば、次回ログインからERP上のロールもすべての場所で変わります。誰かが別システムの更新を思い出すのを待つ必要はありません。

ステップアップMFA(F-06)。 約20行のエクスプレッションポリシーが、アクセス先が機微なシステムの一覧に含まれるか、そして直近のMFA検証から30分以上経っているかを確認します。両方に該当すれば、権限を引き上げたトークンを発行する前にAuthentikが再度MFAを求めます。日常のアクセスのほとんどはこれに遭遇しませんが、財務系とIT管理系のシステムでは必ず遭遇します。

M3への対応(F-10)。 Infor M3は、標準に沿ったSAML2アサーションとは一致しない属性名とNameID形式を要求します。ERP側に手を入れるのではなく、IdP側のカスタムマッピングで変換します。誰かがすでに1週間を失ったからこそ存在する種類のモジュールです。

タイルランチャー(F-07)。 FastAPIのエンドポイントがポータルを描画します。サインイン中の利用者に権限のあるアプリだけを、アイコン、タイ語・英語のラベル、ディープリンク付きで表示します。社員が最初に目にする画面であり、アクセス制御と同じグループポリシーから生成されるため、ポリシーが拒否するアプリをポータルが表示することはありません。

5. アプリを1つ追加するのに実際に必要なもの

新しいアプリケーションに求められるのは、4つの環境変数だけです。

OIDC_CLIENT_ID     = "your-app-client-id"
OIDC_CLIENT_SECRET = "your-app-client-secret"
SESSION_SECRET     = "random-256-bit-string"
OIDC_ISSUER_URL    = "https://sso.example.com/application/o/<app-slug>/"

AuthentikのOIDCプロバイダーはそれぞれ.well-known/openid-configurationにディスカバリー文書を公開するため、アプリはエンドポイント、署名鍵、対応スコープ(独自のERPクレームを含む)を1つのURLから取得できます。製品ページにはFastAPI、Django、Express、PHPの動作するサンプルが掲載されており、いずれもAuthentikへリダイレクトし、コールバックを処理し、トークンからグループとロールを読むだけです。自前の認証コードは不要で、退職処理の際に閉じ忘れるアプリ単位のパスワードテーブルも存在しません。

6. 10週間の導入、支払いは動作確認済みのマイルストーンに連動

土台が動くことを確認してからカスタム作業に入るよう、段階的に進めます。

flowchart TD
    W1["第1から2週 基盤 F01 F02"] --> W3["第3から4週 コアSSO F03"]
    W3 --> W5["第5週 ERPクレーム ステップアップMFA M3対応"]
    W5 --> W6["第6週 タイ語UIとブランディング"]
    W6 --> W7["第7から8週 ポータル WhatsAppと3CX連携"]
    W7 --> W9["第9から10週 テスト UAT 引き継ぎ"]

支払いは日付ではなく検収済みの成果物に連動します。契約時30%、Microsoft 365連携が稼働し最初の5アプリが接続された時点で40%、全サービスが稼働しUATの承認を得た時点で残り30%です。本番稼働後は、翌営業日・4営業時間・2営業時間の3段階の応答水準を持つ月額サポートを任意で付けられ、30日前の書面通知で解約できます。

7. 日本企業としての視点：個人情報保護法、J-SOX、そして能動的サイバー防御

個人情報保護法の安全管理措置。 個人情報保護委員会のガイドラインが示す技術的安全管理措置には、アクセス制御、アクセス者の識別と認証、外部からの不正アクセスの防止が含まれます。24のシステムがそれぞれ独自のアカウントとログを持つ状態では、「誰が、いつ、どの個人データにアクセスできたか」を示すだけで数週間かかります。Authentikに集約すれば、グループ単位の権限付与、SCIMによる退職時の即時失効、変更履歴の残るBlueprint YAMLが、そのまま説明可能な証跡になります。

J-SOXとIT全般統制。 アクセス管理はIT全般統制の評価対象であり、監査では「誰がアクセスできたか」だけでなく「その権限がどう付与され、どう剥奪されたか」が問われます。ERPのロールをAzure ADのグループからトークンで配る構成(F-05)は、権限の付与経路を1本にまとめることそのものです。タイ子会社のシステムが親会社の連結監査の範囲に入っている場合、現地の各システムに散らばった権限設定を一覧化する作業がなくなる効果は小さくありません。

能動的サイバー防御。 2026年10月1日に運用が始まった能動的サイバー防御の枠組みでは、基幹インフラ事業者にインシデントの速報と詳報が求められます。侵害されたアカウントがどのアプリにいつアクセスしたかを1か所で追えることは、報告の正確さに直結します。認証基盤の集約は、報告体制の前提条件の1つです。

8. 提供済みの機能、案件ごとの設定、そして対象外

アイデンティティは、誇張が実害につながる分野です。だからこそ線をはっきり引いておきます。

モジュールとして提供: MFAパススルー付きのAzure AD連携、堅牢化されたセルフホストのAuthentik、OIDC・SAML2のアプリ登録、ハードウェア向けLDAPアウトポスト、Azure ADからのSCIMによるプロビジョニングとデプロビジョニング(セッション無効化を含む)、グループ単位のアクセスポリシー、ERPクレーム、ステップアップMFA、アプリポータル、WhatsAppと3CXの紐付け、M3向けSAML2変換、タイ語UI、テスト、そして2言語のドキュメント。

案件ごとに設定(独立したモジュールではない): パスキーとWebAuthnの登録ポリシーです。Authentikは独自のステージとポリシーを持つ専用の登録フローを構成でき、パスキー登録の記事で述べた堅牢化——登録前のステップアップ必須化、復旧経路の制限、特権ロールの認証情報変更時のアラート——は、希望する顧客に対してポリシー作業の一部として適用します。価格表に独立した行がある既製機能ではありません。simpliSOCのようなSIEMへの認証イベントの連携も同様で、ログは存在しますが、アラートへの接続は個別にスコープを決める作業です。

対象外: ハードウェア本体です。プリンター、ラベルシステム、ロボットは顧客側で用意されるもので、simpliSSOは技術的に可能な範囲でポータルからのディープリンクを提供しますが、機器のファームウェアを交換・再設定することはありません。

9. どのような企業に向いているか

simpliSSOが向いているのは、すでにMicrosoft 365(または標準準拠の別ディレクトリ)を使っており、社内システムが10から数十程度あり、純粋なSaaS型SSOでは取り残されるレガシーシステムを少なくとも1つ抱えている組織です。特に、引き渡し後に運用チームが自社インフラ上でスタックを保有・運用したい場合に適しています。4 vCPU / 8 GBのホスト上のDocker Composeで動き、設定は誰かの記憶ではなくバージョン管理されたBlueprint YAMLとして残ります。

逆に、SaaSツールが5つだけでオンプレミスのシステムが1つもないのであれば、ホスト型のIDサービスのほうが簡単です。

よくある質問

simpliSSOはAzure ADを置き換えるものですか。

いいえ。Azure ADは引き続き正のディレクトリであり、パスワード、MFA、条件付きアクセスを担います。Authentikは社員のパスワードを保存せず、上流のAzure ADとフェデレーションし、下流の各アプリにトークンを発行します。

Microsoft 365がなくても使えますか。

使えます。AuthentikはGoogle Workspace、Okta、汎用のOIDC・SAML2プロバイダー、あるいはクラウドディレクトリに依存できない拠点向けにオンプレミスのActive Directory / OpenLDAPと直接フェデレーションできます。

退職者のアクセスはどうなりますか。

IT部門がAzure AD上でアカウントを1回停止すると、SCIMがその変更をAuthentikへ送り、有効なセッションが無効化され、接続されたすべてのアプリケーションがそのIDを受け付けなくなります。パスキーなどのオーセンティケーターを使っている場合は、退職処理の中で登録済み認証情報を削除することもポリシー設定に含めるべきです。オーセンティケーターが紐付いたまま停止されたアカウントは、再有効化のリスクを抱えています。

パスキーは含まれていますか。

パスキー登録の堅牢化は、独立したモジュールではなく、ポリシー作業の一部として案件ごとに設定します。詳しくは第8節をご覧ください。

追加したコードの所有権は誰にありますか。

ポリシー、マッピング、ステージを含むすべてのカスタムPythonコードは、最終支払いをもって顧客の知的財産になります。

価格はどのように決まりますか。

導入ごとに、スコープ確認の打ち合わせ後に固定価格で見積もります。必須モジュールはF-01、F-02、F-03で、それ以外は契約前に追加・段階導入・削除が可能です。

---

自社環境のログイン数を数えてみて落ち着かない気分になったなら、アプリの数、使っているプロトコル、上流のディレクトリを教えてください。1回の打ち合わせで固定価格の提案をまとめます。お問い合わせはhello@simplico.net、電話(+66) 97 496 6397、WhatsApp (+66) 83 001 0222、LINE ID: iiitum1984まで。アーキテクチャ全体と連携サンプルはsimpliSSO製品ページでご覧いただけます。

---

出典:

• simpliSSO — Simplico
• パスキーの「登録」が新しい攻撃面になる — Simplico
• 社員が24個のパスワードを持つ会社には、24個の攻撃経路がある — Simplico
• エンジニアリング組織に潜む静かなセキュリティリスク — Simplico
• 10月1日、能動的サイバー防御が動き出す — Simplico