朝霧の静かな水面を渡り、対岸へと続く木の橋。

プロダクトノート

パスワードを預けない連携

社内のActive Directoryにパスワードがある。この前提は動かせません。ではモダンなログインをどう載せるか。パスワードハッシュを複製せず、社内への新しい受け口も公開せずにつなぐ。そのための接続がAuthrim Relayです。

動かせない前提から始まる

従業員のアカウントは Active Directory にあります。パスワードポリシーも、失効も、 退職時の停止も、そこで運用されています。何年も回ってきた仕組みです。

そこにパスキーを入れたい。多要素を整理したい。SaaSへのSSOを増やしたい。 やりたいことは明確なのに、最初の一歩で必ず同じ問いにぶつかります。 「パスワードの検証を、どこでやるのか」

パスワードハッシュをクラウドに同期する構成も、社内のディレクトリへ検証を頼む構成もあります。選ぶときに確認したいのは、認証情報をどこに置くか、どちらから接続するか、誰がその経路を運用するかです。

WordWardenでは、LDAP/ADに検証を任せたまま、接続経路を選べます。特に社内への新しい受け口を公開したくない組織のために、外向き接続で使うAuthrim Relayを用意しています。

WordWarden の考え方

Authrim WordWarden は、Authrim 用のディレクトリコネクタです。 社内のLDAP/ADのすぐ隣に置く小さなサービスで、やることは一つに絞られています。 渡されたユーザー名とパスワードをディレクトリに問い合わせ、結果だけを返します。

ログイン画面、セッション、パスキー、メールコード、フェデレーション出力、監査の相関、 アイデンティティのマッピングは Authrim 側が持ちます。 WordWarden は検証だけを、ディレクトリの隣で行います

接続の向きによって、必要なネットワーク設定と運用するものが変わります。

誰が、どちらに接続するか

WordWarden は三つの接続方式を持っています。違いは「社内に受け口を公開する必要があるか」です。

社内ネットワーク Authrim(クラウド) 境界 Direct HTTPS WordWarden 公開エンドポイントが必要 Authrim Authrim から接続 ── 境界に受け口をひとつ開ける Cloudflare Tunnel WordWarden + cloudflared ホストは非公開のまま Authrim cloudflared が外向きに接続 ── 受け口は不要だが、経路に第三者のトンネルが入る Authrim Relay WordWarden 外向きの接続だけを開く Authrim Relay(Durable Object) WordWarden から接続 ── 内向きの受け口はゼロ
矢印は接続を開く向きです。Direct HTTPSはAuthrimから公開エンドポイントへ接続します。TunnelとRelayはどちらも社内から外向きに接続します。Tunnelは別プロセスのcloudflared、Relayは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の継続接続が許可されている必要があります。接続が切れている間はその経路で要求を受け取れないため、接続状態の監視も必要です。

外部から新しく接続できる受け口を減らしても、確立した接続には検証要求が届きます。相手の認証や、受け取った要求の検証は引き続き必要です。

参考:WebSocketプロトコル(RFC 6455)

接続を外向きにしても、接続相手の認証は必要です。Relayでは、接続先とコネクタの確認を組み合わせます。

技術補足:HMACで接続相手を確かめる

WordWardenは、短命なチャレンジに対するHMAC応答で認証します。チャレンジIDとノンスを含む文字列に署名し、接続先URLのテナントIDとコネクタIDが自分の設定に一致するかも確認します。

HMACは三つの接続方式すべてで必須です。Relayが減らすのは内向きの露出であり、コネクタ認証やシークレット管理を省くものではありません。

境界を越えるものを、正確に書きます

ここは曖昧にすると危険なので、はっきりさせておきます。 「パスワードが社外に出ない」わけではありません。

ログイン画面にパスワードを入力する以上、それは Authrim を通過します。 正確な主張は「AuthrimとWordWardenには保存しない」であって「社外に出ない」ではありません。

社内ネットワーク Authrim(クラウド) パスワードは左へ通過する(保存はされない) LDAP / AD パスワードの正本 WordWarden Authrim ユーザー 戻るのは判定結果と、許可リストで絞られた属性だけ 保存する パスワードの正本 保存しない(WordWarden / Authrim) パスワード・パスワードハッシュ (既存システムから移行してきたハッシュも含む) Authrim が持つのはセッション・プロフィール・パスキーの状態
WordWarden のドキュメントは踏み込んだ書き方をしています。 Authrim はパスワード認証情報を取り込まない、ハッシュ化しない、再ハッシュしない、保持しない。 既存システムから持ってきたハッシュも同様。

戻ってくるものも絞られています

検証が成功したとき Authrim に返るのは、判定結果と、要求した属性のうち コネクタ側の許可リストに載っているものだけです。 要求した側が取れる範囲を決めるのではなく、ディレクトリ側が渡す範囲を決めます

この向きは重要です。Authrim 側の設定変更だけで、社内から引き出せる属性を増やすことはできません。

パスワードは目的地ではなく、橋です

この連携は、移行期間のための橋です。

LDAP/AD をパスワードの正本のまま据え置き、そのアカウントでログインできる状態を保ちながら、 裏でパスキーの登録を進めていく。メールコードは復旧経路として残す。 ユーザーから見れば「今までどおり入れる」まま、認証方式だけが入れ替わっていきます。

ドキュメントは移行時の禁止事項も明示しています。 LDAP/AD のパスワードハッシュを Authrim に書き出さないこと。 これをやると、橋を架けるつもりが認証情報の複製になります。

公開ベータ準備中。最初の公開ベータ目標は v0.1.0-beta.1 です。

想定用途はパイロット。LDAPの隣に小さなサービスを運用でき、 ディレクトリ・ネットワーク・TLS・シークレット管理の境界を理解している組織向けです。 マネージドなディレクトリサービスではありません。

Authrim 0.3.2 以降(Directory Authentication と Relay を有効化)が必要です。 現ベータでは設定変更にプロセス再起動が必要です。

「認証情報を出すか、境界を開けるか」は
二択ではありません。

検証をディレクトリの隣で行い、接続を外向きだけにする。 この二つを同時に満たすと、パスワードハッシュを複製することも、 社内に受け口を公開することもなく、モダンなログインを載せられます。

そして載せた先にあるのは、パスワードの継続利用ではなくパスキーへの移行です。 ディレクトリ連携は、その移行をユーザーを止めずに進めるための足場として置かれています。