プロダクトノート
パスワードを預けない連携
社内のActive Directoryにパスワードがある。この前提は動かせません。ではモダンなログインをどう載せるか。パスワードハッシュを複製せず、社内への新しい受け口も公開せずにつなぐ。そのための接続がAuthrim Relayです。
動かせない前提から始まる
従業員のアカウントはActive Directoryにあります。パスワードポリシーも、失効も、 退職時の停止も、そこで運用してきました。何年も使ってきた仕組みです。
そこにパスキーを入れたい。多要素認証を整理したい。SaaSへのSSOを増やしたい。 やりたいことは決まっているのに、最初の一歩で同じ問いにぶつかります。 「パスワードの検証を、どこでやるのか」
パスワードハッシュをクラウドへ同期する方法も、社内のディレクトリに検証を任せる方法もあります。選ぶ前に見ておきたいのは、認証情報をどこに置き、どちらから接続し、誰がその経路を運用するかです。
WordWardenなら、LDAP/ADに検証を任せたまま接続経路を選べます。社内に新しい受け口を公開したくない組織には、外向きに接続するAuthrim Relayがあります。
WordWardenの考え方
Authrim WordWardenは、Authrim用のディレクトリコネクタです。 社内のLDAP/ADのすぐ隣に置く小さなサービスで、仕事は一つだけです。 渡されたユーザー名とパスワードをディレクトリに問い合わせ、結果だけを返します。
ログイン画面、セッション、パスキー、メールコード、フェデレーション出力、監査の相関、 アイデンティティのマッピングはAuthrimが受け持ちます。 WordWardenはディレクトリの隣で、検証だけを行います。
どちらから接続するかで、必要なネットワーク設定と運用するものが変わります。
誰が、どちらに接続するか
WordWardenには三つの接続方式があります。社内に受け口を公開する必要があるかどうかが、大きな違いです。
自分たちの環境なら、どれを選ぶか
これから導入し、社内への受信を増やしたくないなら、まずRelayを検討します。すでに公開基盤やトンネルを使っているなら、それを生かす利点もあります。以下は導入実績ではなく、選び方を考えるための例です。
Authrim Relay：社内ADを使い、外からの接続は増やしたくない
本社の中でADを運用し、外部公開サーバーを増やすには別部門の審査が要る企業。学内LDAPへの外部接続を認めていない大学。そうした環境なら、WordWardenからAuthrimへ接続します。社内・学内向けの受信ポートを新たに公開せずに始められます。
公開エンドポイントや別のトンネル用プロセスを増やさずに済むのが利点です。ただし、外向きのWebSocket通信を許可できなければ使えません。WordWardenの稼働と接続状態も監視します。外部通信そのものが禁止されたネットワークでは使えません。
Cloudflare Tunnel：すでにトンネルを運用している
社内ツールをCloudflare Tunnelで公開し、cloudflaredの更新や経路設定を担当するチームがある組織なら、その運用に載せられます。新しい受信ポートを開けず、いつものトンネル運用の手順を使えます。
Authrimからコネクタへ要求を届けるホスト名と経路を設定し、トンネルの稼働も管理します。社内ホストで直接受信する必要はありませんが、要求はCloudflare上の経路を通って届きます。
Direct HTTPS：公開APIを管理する基盤がある
企業や大学・研究機関の情報基盤部門がDMZとリバースプロキシを運用し、外部連携をそこに集めている場合です。Authrimから届くHTTPSの受け口を用意し、既存の証明書管理、アクセスログ、監視の手順で扱えます。
別のトンネルやRelayの接続を保つ必要はありません。その代わり、受信経路を許可し、公開エンドポイントを守り続ける必要があります。公開するのはコネクタのHTTPS経路です。LDAP/ADのポートを直接インターネットに開くわけではありません。
どの方式でも、LDAP/ADに届く場所でWordWardenを運用します。学術機関だからこの方式、と決まるものではありません。公開基盤の有無とネットワークの方針で選びます。
Authrim Relayは外向きの接続だけを使う
Relayモードでは、社内のWordWardenからAuthrimへWebSocketで接続します。 WebSocketは、一度つないだ経路を保ち、双方がメッセージを送れる仕組みです。
WordWardenは接続を保って待ちます。ログイン時には、Authrimが同じ経路で 「このユーザーを確認してください」と依頼します。WordWardenは社内のディレクトリで確認し、結果を返します。
社内からかけた電話をつないだまま、相手からの話も聞くようなものです。 依頼のたびに、外から社内へ接続し直す必要はありません。
この構成なら、ディレクトリ側のネットワークでURLを公開しません。 新しい公開エンドポイントのホスト名・証明書・WAFを管理する負担が減ります。 ただし、外向き接続の許可、WordWardenの保守、接続の監視は引き続き必要です。
技術補足 WebSocketは、受信ポートの公開と何が違うのか
違いは、最初の接続をどちらから始めるかです。Direct HTTPSでは、Authrimから接続できる受け口を組織側に用意します。Relayでは、組織内のWordWardenがAuthrimのRelayへ暗号化されたWebSocket接続（wss）を張ります。
一般的なステートフルファイアウォールやNATは、内側から始めた通信を追跡し、その返答を通します。このため、社内のWordWardenに外部から新しく接続できるポートを公開したり、ポート転送を設けたりせずに、検証要求を受け取れます。
ポートを使わない、という意味ではありません。通常のwssは接続先のTCP 443番ポートを使います。組織のファイアウォールやプロキシで、Relayへの外向き通信とWebSocketの継続接続を許可する必要があります。接続が切れた間はその経路で要求を受け取れないので、接続状態も監視します。
外部から新しく接続できる受け口を減らしても、確立した接続には検証要求が届きます。相手の認証や、受け取った要求の検証は引き続き必要です。
接続を外向きにしても、接続相手の認証は必要です。Relayでは、接続先とコネクタの確認を組み合わせます。
技術補足 HMACで接続相手を確かめる
WordWardenは、短命なチャレンジに対するHMAC応答で認証します。チャレンジIDとノンスを含む文字列に署名し、接続先URLのテナントIDとコネクタIDが自分の設定に一致するかも確認します。
HMACは三つの接続方式すべてで必須です。Relayを使うと社内への受信経路は減りますが、コネクタの認証とシークレット管理は省けません。
境界を越えるものを、正確に書きます
ここを曖昧にすると危険です。 「パスワードが社外に出ない」とは言えません。
ログイン画面に入力したパスワードはAuthrimを通ります。 けれど、AuthrimとWordWardenには保存しません。通ることと保存することは、別の話です。
戻ってくるものも絞られています
検証に成功すると、Authrimに返るのは判定結果と、要求した属性のうち コネクタ側の許可リストに載っているものだけです。 どの属性を渡すかは、要求する側ではなくディレクトリ側が決めます。
ここは大切な境界です。Authrim側の設定だけで、社内から取れる属性が増えることはありません。
パスワードは目的地ではなく、橋です
この連携は、移行期間のための橋です。
LDAP/ADをパスワードの正本としたまま、そのアカウントでのログインを続けられるようにします。 その間にパスキーの登録を進め、メールコードは復旧経路として残します。 ユーザーから見れば「今までどおり入れる」まま、認証方式だけが入れ替わっていきます。
移行中も、LDAP/ADのパスワードハッシュをAuthrimに書き出してはいけません。 それでは、橋を架けるつもりが認証情報を複製することになります。
公開ベータ準備中。最初の公開ベータ目標は v0.1.0-beta.1 です。
想定用途はパイロット。LDAPの隣に小さなサービスを運用でき、 ディレクトリ・ネットワーク・TLS・シークレット管理の境界を理解している組織向けです。 マネージドなディレクトリサービスではありません。
Authrim 0.3.2 以降（Directory Authentication と Relay を有効化）が必要です。 現ベータでは設定変更にプロセス再起動が必要です。
「認証情報を出すか、境界を開けるか」は
二択ではありません。
ディレクトリの隣で検証し、接続は外向きだけにする。 そうすればパスワードハッシュを複製せず、社内に受け口も公開せずに、モダンなログインを載せられます。
目指すのはパスワードを使い続けることではなく、パスキーへの移行です。 ディレクトリ連携は、ユーザーを止めずに移行を進めるための足場になります。