승인된 사용자가 Keycloak 로그인을 통해 Jitsi 룸을 생성할 수 있도록 허용

Jitsi Meet 회의실 생성 권한을 특정 사용자로 제한하려면 인증된 호스트만 참여할 수 있도록 하고 승인된 계정에만 자격 증명을 발급하세요. 새로운 자체 호스팅 설치의 경우 Jitsi는 토큰 기반 인증을 권장합니다. 이 가이드에서는 Keycloak을 ID 공급자로 사용하고, 승인된 호스트가 회의실을 시작한 후에만 초대된 게스트가 참여할 수 있도록 합니다.

1. 배포 상태를 확인하고 호스트 계정을 선택하세요.

이 지침은 Debian 또는 Ubuntu 패키지를 사용하여 자체 호스팅 Jitsi Meet을 설치하고, Prosody, Nginx 및 Jitsi 웹 구성에 관리자 권한이 있는 경우를 대상으로 합니다. Keycloak이 이미 설치되어 있거나 안전하게 배포할 수 있다고 가정합니다. Prosody는 XMPP 메시징 서버이며, JSON Web Token(JWT)은 사용자가 인증되었음을 증명하는 데 사용되는 서명된 자격 증명입니다. Keycloak은 사용자 로그인을 처리하는 ID 공급자입니다.

Jitsi 핸드북에서는 기존의 사용자 이름과 비밀번호를 사용하는 보안 도메인 인증 방식을 더 이상 사용하지 않도록 권장하고 있으며, 새로운 설치 시에는 토큰 인증을 사용하도록 안내하고 있습니다. 현재 인증 지침은 2026년 10월 5일에 업데이트되었습니다. 이미 Docker를 사용 중인 경우 아래 패키지 경로를 복사하지 마십시오. 공식 Docker 구성 가이드에서는ENABLE_AUTH ` ENABLE_GUESTS/config /`, `/config/`, `/config/` 와 같은 환경 변수를 사용합니다 AUTH_TYPE.

편집하기 전에 공개 회의 호스트 이름을 기록해 두고, HTTPS가 제대로 작동하는지 확인하고, 변경할 구성 파일을 백업하고, 회의를 호스팅할 계정을 결정하세요. 이 예시에서 회의 주소는 입니다 jitsi.example.com. 모든 곳에서 실제 호스트 이름으로 바꿔주세요.

2. Keycloak에서 승인된 호스트에게만 액세스 권한을 부여합니다.

전용 영역을 만드세요

Keycloak 관리 콘솔에서 이라는 이름의 영역을 생성하고 선택합니다 jitsi-realm. 영역은 격리된 사용자 및 애플리케이션 설정 모음입니다. 공개 사용자 등록을 비활성화하고 제한 없는 회사 디렉터리를 자동으로 가져오지 않도록 설정합니다. 이 구성에서는 승인된 영역에 인증할 수 있는 모든 계정이 회의 생성자가 될 수 있습니다.

Jitsi 웹 클라이언트를 등록하세요

`OpenID Connect` 라는 이름의 OpenID Connect 클라이언트를 생성합니다 jitsi. OpenID Connect(OIDC)는 Keycloak이 Jitsi에 신원 정보를 반환하는 데 사용하는 로그인 프로토콜입니다. 공식 Jitsi 예제를 따라 호스트 이름만 조정하여 다음 콜백 값을 정확히 입력합니다.

• 유효한 리디렉션 URI:https://jitsi.example.com/static/sso.html
• 유효한 로그아웃 후 리디렉션 URI:https://jitsi.example.com/static/logout.html
• 웹 출처:https://jitsi.example.com

허용된 사람들을 추가하세요

사용자 탭에서 승인된 호스트별로 계정을 생성한 다음, 자격 증명 탭에서 해당 사용자의 암호를 설정하십시오. 관리자 로그인 정보를 공유하는 대신 별도의 계정을 사용하는 것이 좋습니다. 더 이상 회의를 생성하지 않으려는 계정은 비활성화하거나 해당 영역에 대한 인증을 거부해야 합니다. 공유 영역 내에서 특정 그룹에만 제한을 적용해야 하는 경우, 별도로 검증된 권한 부여 정책을 추가하십시오. 여기에 설명된 단계는 Keycloak 그룹 멤버십을 자동으로 적용하지 않습니다.

3. Keycloak을 Jitsi 서버에 연결합니다.

HTTPS를 통해 Keycloak 영역 엔드포인트를 프록시합니다.

Keycloak을 올바른 공개 호스트 이름과 신뢰할 수 있는 역방향 프록시 헤더로 구성한 다음 /realms/Jitsi 호스트 이름에서 Keycloak 개인 리스너로 요청을 라우팅합니다. `//keycloak/hostname`에 사용 가능한 Keycloak 인스턴스의 경우 127.0.0.1:18080, 기존 Jitsi Nginx HTTPS 서버 블록 내에 일반 Jitsi 라우팅 블록 앞에 다음 위치 블록을 추가합니다.

location ~ ^/realms/(.*) {
    proxy_pass http://127.0.0.1:18080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

이는 Keycloak이 해당 포트에서 로컬로 접근 가능하다고 가정합니다. 배포 환경에 맞게 상위 포트를 변경하십시오. Keycloak의 관리 콘솔이나 백엔드 포트를 불필요하게 노출하지 마십시오. 프로덕션 환경의 프록시 및 호스트 이름 제어에 대한 자세한 내용은 Keycloak의 리버스 프록시 문서를 참조하십시오 .

Prosody에서 토큰을 요구합니다.

편집 /etc/prosody/conf.avail/jitsi.example.com.cfg.lua. 발급자 및 대상 설정을 추가한 다음 기존 기본 설정을 VirtualHost토큰 인증을 사용하도록 업데이트합니다. 이 줄들을 다른 설정과 병합하세요. 해당 호스트 블록의 복사본을 두 개 만들지 마세요.

asap_accepted_issuers = { "https://jitsi.example.com/realms/jitsi-realm" }
asap_accepted_audiences = { "account" }
asap_require_room_claim = false

VirtualHost "jitsi.example.com"
    authentication = "token"
    app_id = "jitsi"
    allow_empty_token = false
    cache_keys_url = "https://jitsi.example.com/realms/jitsi-realm/protocol/openid-connect/certs"

게스트 액세스를 위해 Jitsi 지침에 따라 , , 및 모듈을 포함하는 별도의 guest.jitsi.example.com가상 호스트를 추가하십시오. 이는 내부 XMPP 도메인이므로 공용 DNS 또는 별도의 인증서를 생성하지 마십시오. 기존 메인 호스트의 모듈 목록에 를 추가하고, 기존 MUC 구성 요소 모듈 목록에 를 추가하십시오 . MUC는 회의실을 관리하는 다중 사용자 채팅 구성 요소입니다. 이미 나열된 모듈은 그대로 유지하십시오.authentication = "jitsi-anonymous"c2s_require_encryption = falsesmackspersistent_lobbyconference.jitsi.example.commuc_wait_for_host

브라우저 로그인 흐름을 구성하세요

에서 기존 객체에 /etc/jitsi/meet/jitsi.example.com-config.js추가합니다 . Jitsi에서 문서화한 OIDC 설정을 추가합니다.anonymousdomain: 'guest.jitsi.example.com'hosts

config.tokenAuthUrl='https://'+ config.hosts.domain + '/realms/jitsi-realm/protocol/openid-connect/auth?client_id=jitsi&response_type=code&scope=openid&state={state}&redirect_uri=https://'+ config.hosts.domain + '/static/sso.html&code_challenge={code_challenge}&code_challenge_method=S256';
config.tokenLogoutUrl='https://'+ config.hosts.domain + '/realms/jitsi-realm/protocol/openid-connect/logout?post_logout_redirect_uri=https://'+ config.hosts.domain + '/static/logout.html';
config.tokenAuthInline=true;
config.sso={ ssoService: config.hosts.domain, tokenService: config.hosts.domain + '/realms/jitsi-realm/protocol/openid-connect', clientId: "jitsi" };

이 값들은 PKCE(Proof Key for Code Exchange)를 사용한 인증 코드 로그인 흐름을 구현하며, 이는 브라우저 기반 인증을 보호하는 기능입니다. Jitsi 설명서에는 jicofo.conf토큰 모드에서는 인증을 비활성화 상태로 유지하라고 명시되어 있으며, 더 이상 사용되지 않는 XMPP 보안 도메인 인증 블록을 복사하지 말라고 되어 있습니다.

서비스를 검증하고 다시 로드합니다.

Nginx 구문을 확인한 다음 현재 토큰 인증 지침에 나열된 서비스만 다시 시작하십시오. Jitsi 서버가 이미 사용 중인 경우 유지 관리 기간에 이러한 변경 작업을 수행하십시오.

sudo nginx -t
sudo systemctl restart prosody
sudo systemctl restart nginx

4. 이러한 권한 및 로그인 오류를 피하세요

• 누구나 채팅방을 시작할 수 있습니다. 메인 Prosody 호스트가 토큰 인증을 사용하고, 빈 토큰은 허용되지 않으며, 게스트 호스트가 별도로 설정되어 있는지 확인하십시오. 유효한 로그인 정보가 남아 있는 세션이 아닌, 깨끗한 브라우저 세션에서 테스트하십시오.
• 승인된 사용자가 로그인할 수 없는 경우 Keycloak 영역 발급자, 공개 HTTPS 호스트 이름, 클라이언트 ID, 리디렉션 URI 및 Prosody를 비교하십시오 cache_keys_url. 브라우저 리디렉션 실패는 사용자 권한이 올바르다는 증거가 아닙니다.
• 게스트가 객실에 입장하지 않는 경우 , Prosody와 Jitsi 모두에서 익명 도메인 config.js과 호스트 대기 모듈을 확인하십시오. 로비 또는 게스트 대기 상태는 인증 실패와는 다릅니다.

5. 새 회의를 생성할 수 있는 사용자를 확인합니다.

로그인하지 않은 개인 정보 보호 모드 창에서 이전에 사용하지 않은 회의실 URL을 엽니다. 게스트는 첫 번째 호스트로 회의를 시작할 수 없어야 합니다. 다음으로, 승인된 Keycloak 사용자로 로그인하여 해당 회의실을 생성합니다. 게스트 도메인이 활성화된 경우 초대된 게스트가 회의에 참여할 수 있어야 합니다. 마지막으로, 비활성화되었거나 승인되지 않은 계정을 사용하여 인증 및 새 회의실 생성이 불가능한지 확인합니다.

테스트가 실패할 경우, sudo journalctl -u prosody -u nginx --since "10 minutes ago"Keycloak 인증 이벤트와 함께 문제를 검사하되, 로그에서 토큰이나 비밀번호를 공개하지 마십시오. 승인된 계정으로 새 방을 만들 수 있고 인증되지 않은 사용자는 만들 수 없을 때만 수정이 완료된 것으로 간주합니다.