프로덕트 노트
비밀번호를 맡기지 않는 연동
비밀번호는 이미 사내 Active Directory에 있습니다. 비밀번호 해시를 복제하거나 외부에서 들어오는 접속점을 새로 공개하지 않고 현대적인 로그인을 추가할 수 있을까요? Authrim Relay는 이를 위한 연결 방식입니다.
바꿀 수 없는 전제에서 시작합니다
직원 계정은 Active Directory에 있습니다. 비밀번호 정책과 만료, 퇴사 시 비활성화도 수년 동안 그곳에서 관리해 왔습니다.
패스키를 도입하고 다중 인증을 정리하며 SaaS SSO를 늘리려 합니다. 첫 단계에서 같은 질문을 만납니다. 비밀번호를 어디에서 검증할 것인가?
비밀번호 해시를 클라우드로 동기화하는 구성도, 내부 디렉터리에 검증을 요청하는 구성도 있습니다. 자격 증명을 어디에 두고, 어느 쪽에서 연결하며, 누가 경로를 운영할지 확인해야 합니다.
WordWarden은 검증을 LDAP/AD에 맡긴 채 경로를 선택하게 합니다. 새 수신 엔드포인트를 공개하고 싶지 않은 조직에는 Authrim Relay의 외부로 나가는 연결을 제공합니다.
WordWarden이 하는 일
Authrim WordWarden은 디렉터리 커넥터입니다. LDAP/AD 가까이에 두는 작은 서비스로, 사용자 이름과 비밀번호를 받아 디렉터리에 확인하고 결과를 반환합니다.
로그인 UI, 세션, 패스키, 이메일 코드, 외부 서비스에 제공하는 인증, 감사 연계, 신원 매핑은 Authrim이 담당합니다. WordWarden은 디렉터리 옆에서 검증만 수행합니다.
연결 방향에 따라 네트워크 설정과 운영할 구성요소가 달라집니다.
누가 어느 쪽으로 연결하는가
WordWarden은 세 가지 연결 방식을 제공합니다. 차이는 조직 네트워크에 수신 지점을 공개해야 하는가입니다.
우리 환경에는 어떤 방식이 맞을까
새 배포에서 수신 접근을 늘리고 싶지 않다면 Relay부터 검토할 수 있습니다. 기존 공개 인프라나 터널을 활용하는 이점도 있습니다. 다음은 구성 선택의 예이며 실제 고객 도입 사례는 아닙니다.
Authrim Relay: 내부 AD를 유지하고 외부 수신은 늘리지 않기
새 공개 서버마다 별도 심사가 필요한 기업이나, 학내 LDAP 네트워크에 외부 연결을 허용하지 않는 대학을 생각해 볼 수 있습니다. WordWarden이 Authrim에 연결하므로 내부에 새 수신 포트를 공개하지 않습니다.
새 공개 엔드포인트나 별도 터널 프로세스가 필요 없습니다. 외부로 나가는 WebSocket 연결을 허용해야 하고 WordWarden과 연결 상태는 감시해야 합니다. 외부 통신 자체를 금지한 네트워크에서는 사용할 수 없습니다.
Cloudflare Tunnel: 기존 터널 운영 활용하기
이미 내부 도구를 Cloudflare Tunnel로 공개하고 cloudflared 업데이트와 경로를 담당하는 팀이 있다면, 수신 포트를 추가하지 않고 기존 절차에 WordWarden을 포함할 수 있습니다.
Authrim 요청이 커넥터에 도달할 호스트 이름과 경로를 설정하고 터널을 관리합니다. 내부 호스트에 직접 수신할 필요는 없지만 요청은 Cloudflare 경로를 통해 전달됩니다.
Direct HTTPS: 기존 API 공개 기반 활용하기
기업·대학·연구기관의 인프라 팀이 DMZ와 리버스 프록시로 외부 연계를 관리하고 있다면, Authrim이 접근할 HTTPS 지점을 기존 인증서·접근 로그·감시 절차로 운영할 수 있습니다.
별도 터널이나 Relay 연결을 유지하지 않아도 됩니다. 대신 수신 경로 허용과 공개 지점 보호·유지보수를 담당합니다. 공개하는 것은 커넥터의 HTTPS 인터페이스이며 LDAP/AD 포트를 인터넷에 직접 여는 구성이 아닙니다.
모든 방식에서 WordWarden은 LDAP/AD에 접근할 수 있어야 합니다. 학술기관이라는 이유로 방식이 결정되는 것이 아니라 인프라와 네트워크 정책으로 선택합니다.
Authrim Relay: 내부에서 시작하는 연결
Relay 모드에서 WordWarden은 내부에서 WebSocket으로 Authrim에 연결합니다. WebSocket은 연결을 유지하여 양쪽 모두 메시지를 보낼 수 있게 하는 방식입니다.
WordWarden은 연결을 유지하며 기다립니다. 로그인이 발생하면 Authrim이 같은 경로로 “이 사용자를 확인해 주세요”라고 요청하고, WordWarden은 내부 디렉터리에서 확인한 결과를 반환합니다.
조직 안에서 전화를 걸어 통화를 유지하면 상대방도 말할 수 있는 것과 비슷합니다. 요청마다 외부에서 내부로 새로 연결할 필요가 없습니다.
따라서 디렉터리 쪽은 이 연결을 위한 URL을 공개하지 않습니다. 새 공개 호스트명·인증서·WAF 관리 부담을 줄입니다. 외부로 나가는 통신 허용, WordWarden 유지보수와 연결 상태 모니터링는 여전히 필요합니다.
기술 보충: WebSocket과 수신 포트 공개의 차이
차이는 누가 먼저 연결하는가입니다. Direct HTTPS는 조직이 Authrim에서 접근 가능한 지점을 제공합니다. Relay는 내부 WordWarden이 Authrim으로 암호화된 WebSocket(wss)을 연결합니다.
일반적인 상태 기반 방화벽과 NAT는 내부에서 시작한 연결을 추적해 그 연결의 응답 통신을 허용합니다. 따라서 외부의 새 연결을 받는 포트 공개나 포트 포워딩 없이 검증 요청을 받을 수 있습니다.
포트를 전혀 사용하지 않는다는 뜻은 아닙니다. 일반적인 wss는 목적지 TCP 443 포트를 사용합니다. 방화벽이나 프록시에서 Relay로의 외부로 나가는 통신과 지속적인 WebSocket 연결을 허용해야 합니다. 연결이 끊기면 요청을 받을 수 없으므로 상태 감시도 필요합니다.
새 외부 연결을 받을 지점을 줄여도 기존 연결로 검증 요청이 들어옵니다. 상대 인증과 요청 검증은 계속 필요합니다.
외부로 나가는 연결도 상대 인증이 필요합니다. Relay는 커넥터 인증과 목적지 설정 확인을 함께 수행합니다.
기술 보충: HMAC으로 연결 상대 확인하기
WordWarden은 짧은 유효기간의 챌린지에 HMAC으로 응답합니다. 챌린지 ID와 nonce를 포함한 문자열에 서명하고, 목적지 URL의 테넌트·커넥터 ID가 자신의 설정과 일치하는지도 확인합니다.
세 방식 모두 HMAC이 필수입니다. Relay는 수신 노출을 줄이는 것이며 커넥터 인증이나 비밀 정보 관리를 생략하는 수단이 아닙니다.
실제로 경계를 넘는 정보
정확히 구분해야 합니다. 비밀번호가 조직 밖으로 전혀 나가지 않는 것은 아닙니다.
로그인 화면에 입력한 비밀번호는 Authrim을 통과합니다. 정확한 설명은 Authrim과 WordWarden이 저장하지 않는다는 것입니다.
반환하는 정보도 제한합니다
성공 시 결과와 요청 속성 중 커넥터의 로컬 허용 목록에 포함된 항목만 반환합니다. 요청자가 가져갈 범위를 정하는 대신 디렉터리 쪽에서 전달 범위를 결정합니다.
따라서 Authrim 설정만 바꿔 내부 네트워크에서 가져올 속성을 늘릴 수 없습니다.
비밀번호는 전환을 위한 다리입니다
이 연결은 이행 기간을 위한 것입니다.
LDAP/AD를 비밀번호 원본으로 유지하고 기존 계정으로 로그인하게 하면서 패스키를 점진적으로 등록합니다. 이메일 코드는 복구 경로로 둡니다. 로그인 흐름을 유지하며 인증 방식을 바꿀 수 있습니다.
문서는 LDAP/AD의 비밀번호 해시를 Authrim으로 내보내지 말 것도 명시합니다. 그렇게 하면 전환을 돕는 대신 자격 증명 복제본을 만들게 됩니다.
공개 베타 준비 중. 첫 목표는 v0.1.0-beta.1입니다.
파일럿 용도로, LDAP/AD 주변에 서비스를 운영하고 디렉터리·네트워크·TLS·비밀 관리 경계를 이해하는 조직을 대상으로 합니다. 관리형 디렉터리 서비스는 아닙니다.
Directory Authentication과 Relay를 활성화한 Authrim 0.3.2 이상이 필요합니다. 현재 베타는 설정 변경 시 프로세스 재시작이 필요합니다.
자격 증명 복제나 수신 경로 개방이
유일한 선택은 아닙니다.
디렉터리 가까이에서 검증하고 내부에서 외부로 나가는 연결을 시작하면, 비밀번호 해시 복제나 내부 수신 지점 공개 없이 현대적인 로그인을 제공할 수 있습니다.
그다음 목표는 패스키로의 전환입니다. 디렉터리 연결은 사용자의 로그인을 중단하지 않고 전환을 진행할 기반입니다.