Como habilitar a autenticação e a proteção por senha no Jitsi Meet

O Jitsi Meet possui dois controles de proteção distintos: a autenticação do servidor define quem pode criar uma reunião, enquanto a senha da sala impede que pessoas desconhecidas entrem na sala. Eles resolvem problemas diferentes. Em um servidor próprio, a antiga configuração de "domínio seguro" do Prosody pode exigir nome de usuário e senha para criar salas, permitindo ainda a entrada de convidados. O manual atual do Jitsi indica que esse método está obsoleto para novas instalações e recomenda a autenticação baseada em token. Administradores existentes podem usar o procedimento abaixo como um guia de compatibilidade, mas devem planejar novas implementações com base em uma configuração de token ou provedor de identidade compatível.

As senhas de sala são um recurso separado, utilizado durante a reunião, e continuam sendo úteis juntamente com a autenticação do servidor. Defina uma senha após a sala ser iniciada, compartilhe-a por meio de um canal privado e teste o processo de entrada em um segundo navegador antes de convidar os participantes.

Que tipo de proteção você precisa?

Para uma reunião pequena, um nome de sala exclusivo e uma senha podem ser suficientes. Para uma organização que precisa de criação de salas baseada em contas, configure também a autenticação do servidor. Para novas implantações auto-hospedadas, revise o guia de autenticação atual do Jitsi e a configuração de autenticação por token relevante antes de escolher uma implementação.

Como proteger uma sala do Jitsi com senha?

Inicie a reunião, abra o menu de segurança ou opções da reunião na barra de ferramentas, escolha a opção de senha e insira uma senha forte para a sala. O nome e o ícone do menu podem variar conforme a versão do cliente. Se a reunião já estiver em andamento, definir uma senha afetará as entradas futuras; as pessoas que já entraram não serão removidas automaticamente. Envie a senha separadamente do link da reunião quando a confidencialidade for importante.

As perguntas frequentes do Jitsi explicam que a senha da sala é removida ao término da reunião, portanto, não se deve presumir que ela seja mantida em reuniões recorrentes. Defina-a novamente para cada nova reunião e verifique o comportamento em sua própria implementação. Qualquer pessoa que receber a senha ou que a tenha encaminhada poderá entrar, portanto, uma senha não é o mesmo que uma lista de acesso de usuários nomeados. Consulte as perguntas frequentes oficiais do Jitsi sobre proteção de reuniões .

O que a autenticação do servidor altera?

No design clássico de "domínio seguro", o Prosody autentica os criadores de salas com base em contas locais. O Jitsi, então, permite que participantes não autenticados se conectem por meio de um domínio de convidado. Isso é útil quando apenas a equipe deve iniciar salas, mas os participantes não precisam de contas. Dessa forma, todos os participantes não precisam fazer login. Se todos os usuários precisarem se autenticar, o acesso de convidados precisa ser desativado ou substituído pela política de identidade e acesso usada pelo seu design de autenticação atual.

A documentação do Jitsi indica que este método antigo de domínio seguro está obsoleto para novas instalações. Continue somente se você compreender essa limitação e estiver mantendo um servidor existente compatível. Antes de editar, identifique como o Jitsi foi instalado, anote o nome do host do seu Jitsi Meet, faça backup dos arquivos de configuração do Prosody, Jicofo e da web, e mantenha uma sessão de administrador ou console ativo disponível caso um erro de sintaxe interrompa o serviço.

Como habilitar a configuração legada de domínio seguro em uma instalação de pacote Debian ou Ubuntu?

1. Alterar os hosts virtuais do Prosody

Abra o arquivo Prosody para o seu hostname Jitsi, normalmente /etc/prosody/conf.avail/jitsi.example.com.cfg.lua. Substitua o hostname de exemplo abaixo pelo domínio real. No host virtual principal, altere o modo de autenticação para senhas internas criptografadas. Adicione o host virtual convidado em seguida:

VirtualHost "jitsi.example.com"
    authentication = "internal_hashed"

VirtualHost "guest.jitsi.example.com"
    authentication = "jitsi-anonymous"
    c2s_require_encryption = false

Mantenha as demais opções e módulos existentes. Não crie registros DNS nem um certificado público para guest.jitsi.example.com; nesta configuração, trata-se de um domínio interno do Jitsi.

2. Informe ao cliente web sobre o domínio convidado.

Abra /etc/jitsi/meet/jitsi.example.com-config.jse adicione o conteúdo anonymousdomaindentro do objeto existente hosts. Mantenha as domainentradas existentes e as demais, e verifique as vírgulas com atenção:

hosts: {
    domain: 'jitsi.example.com',
    anonymousdomain: 'guest.jitsi.example.com'
},

3. Habilite a autenticação no Jicofo

Edite /etc/jitsi/jicofo/jicofo.conf. Adicione as configurações de autenticação dentro do jicofobloco existente; não crie um bloco duplicado de nível superior:

jicofo {
  authentication {
    enabled = true
    type = XMPP
    login-url = "jitsi.example.com"
  }
}

Se o arquivo já contiver uma jicofoseção, mescle essas propriedades nela. A sintaxe de configuração e os arquivos gerados podem variar de acordo com a versão do pacote; portanto, compare o resultado com a página do manual da sua instalação antes de reiniciar os serviços.

4. Reinicie os serviços e crie uma conta.

Após verificar as alterações, reinicie os serviços como administrador:

sudo systemctl restart prosody
sudo systemctl restart jicofo
sudo systemctl restart jitsi-videobridge2

Crie uma conta de criador de salas no Prosody. Substitua os espaços reservados; nunca use o domínio de exemplo ou uma senha fraca em um servidor de produção.

sudo prosodyctl register <username> jitsi.example.com <strong-password>

Cada conta está associada ao nome de host do Jitsi. Crie contas individuais em vez de compartilhar uma única credencial de administrador caso precise revogar o acesso posteriormente. A documentação do domínio seguro do Jitsi lista os caminhos de configuração específicos do pacote e o comando de registro. Ela também afirma explicitamente que o método está obsoleto.

Como a configuração difere no Docker?

Não edite arquivos dentro de contêineres em execução nem copie os caminhos dos pacotes Debian para uma implantação do Docker. Na configuração oficial do Docker Compose, a autenticação é configurada por meio do arquivo de ambiente da implantação. O manual documenta os seguintes valores relevantes para autenticação de contas internas:

ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=internal

Mantenha o acesso de convidados ativado se os participantes precisarem entrar sem suas próprias contas. Com o acesso de convidados ativado, usuários não autenticados podem entrar de acordo com o comportamento configurado para convidados; eles não se tornam criadores de sala autenticados. Aplique as alterações de ambiente usando o fluxo de trabalho Compose para sua implantação e verifique os logs se os serviços não iniciarem corretamente.

Crie um usuário interno através do serviço Prosody em vez de alterar a configuração gerada do contêiner. O manual oficial mostra como abrir um shell no contêiner Prosody e registrar um usuário com `--user` prosodyctl. O caminho de configuração e o domínio XMPP dependem da versão do Compose; na imagem Docker documentada, a configuração do Prosody está em `/etc/prosody/config.yml` /config/prosody.cfg.lua, e o domínio XMPP de exemplo é `/etc/ meet.jitsiprosody/config.yml`. Use o comando e os valores exatos documentados para a sua versão. Consulte o guia oficial de auto-hospedagem do Docker para obter informações sobre variáveis ​​de ambiente, criação de contas e comportamento da configuração gerada.

Como posso confirmar que a proteção funciona?

• Abra uma janela anônima do navegador e tente criar uma nova sala. A configuração clássica deverá solicitar as credenciais da conta.
• Inicie sessão com a nova conta e crie uma sala. Confirme se a reunião carregou e se o anfitrião tem os controlos de moderador esperados.
• A partir de outro navegador, entre como convidado. Se a opção de convidados estiver habilitada, a entrada deverá funcionar sem uma conta de criador; adicione a senha da sala ou o lobby quando precisar de uma verificação de acesso adicional.
• Defina uma senha para a sala e, em seguida, tente entrar a partir de uma nova janela privada sem senha e com senha. Confirme se um participante já presente na sala permanece conectado quando a senha é definida.
• Após encerrar a reunião de teste, inicie uma nova sala e verifique se é necessário definir a senha novamente, conforme descrito nas perguntas frequentes do Jitsi.

Se a solicitação de login nunca aparecer, verifique os nomes de host do Prosody, o bloco Jicofo, anonymousdomaino valor do cliente e os logs de serviço. Um erro de configuração comum é usar um domínio de convidado que não corresponde entre o Prosody e o servidor principal config.js, ou adicionar um segundo bloco Jicofo em vez de estender o existente. Se os convidados não conseguirem entrar, verifique se o acesso de convidados foi habilitado intencionalmente e se o domínio de convidado configurado corresponde ao nome de host principal.

O que você deve escolher para uma nova instalação?

Não inicie uma nova implementação com a receita de domínio seguro obsoleta, a menos que tenha um motivo específico de compatibilidade. O material atual de auto-hospedagem do Jitsi recomenda a autenticação por token para novas instalações, enquanto seu guia de autenticação mais abrangente documenta a integração mais recente com provedores de identidade. Essas abordagens exigem configuração adicional de emissor, assinatura ou provedor de identidade; elas não são intercambiáveis ​​com uma senha de sala do Prosody. Escolha o modelo que atenda às suas necessidades e, em seguida, use senhas de sala ou um lobby como controles separados no nível da reunião, quando apropriado.

Resumindo: use autenticação por conta ou token para controlar quem pode criar salas e defina uma senha para restringir entradas futuras apenas a pessoas que conhecem o segredo. Teste ambos os métodos independentemente, pois habilitar um não habilita automaticamente o outro.

Referências oficiais

• Jitsi Meet: Autenticação
• Jitsi Meet: Configuração de domínio seguro (obsoleto)
• Jitsi Meet: Autenticação por Token
• Jitsi Meet: Guia de auto-hospedagem do Docker
• Jitsi Meet: Perguntas frequentes e proteção de reuniões