4.-Autenticacion por token

Plugin de PROSODY para autenticacion de token JWT .

Este complemento implementa el proveedor de autenticación Prosody que verifica la conexión del cliente basada en el token JWT descrito en RFC7519. Permite utilizar cualquier forma externa de autenticación con lib-jitsi-meet. Una vez que su usuario se autentica, debe generar el token JWT como se describe en el RFC y pasarlo a su aplicación cliente. Una vez que se conecta con un token válido, el sistema jitsi-meet lo considera autenticado.
This plugin implements Prosody authentication provider that verifies client connection based on JWT token described in RFC7519. It allows to use any external form of authentication with lib-jitsi-meet. Once your user authenticates you need to generate the JWT token as described in the RFC and pass it to your client app. Once it connects with valid token is considered authenticated by jitsi-meet system.

Durante la configuración, deberá proporcionar el ID de la aplicación que identifica al cliente y un secreto compartido por el servidor y el generador de tokens JWT. Como se describe en el RFC, el secreto se usa para calcular el valor hash de HMAC que permite autenticar el token generado. Hay muchas bibliotecas existentes que se pueden usar para implementar el generador de tokens. Encuentra más información aquí: http://jwt.io/#libraries-io
During configuration you will need to provide the application ID that identifies the client and a secret shared by both server and JWT token generator. Like described in the RFC, secret is used to compute HMAC hash value which allows to authenticate generated token. There are many existing libraries which can be used to implement token generator. More info can be found here: http://jwt.io/#libraries-io

La autenticación de token JWT actualmente solo funciona con conexiones BOSH.
JWT token authentication currently works only with BOSH connections.

Estructura del Token

Las siguientes notificaciones JWT se utilizan en el token de autenticación:
The following JWT claims are used in authentication token:

  • ‘iss’ especifica el ID de la aplicación que identifica la aplicación cliente que se conecta al servidor. Debe negociarse con el proveedor de servicios antes de generar el token.
    ‘iss’ specifies application ID which identifies the client app connecting to the server. It should be negotiated with the service provider before generating the token.
  • ‘room’ contiene el nombre de la sala para la cual se ha asignado el token. Esta NO es la dirección completa de la sala de MUC. Ejemplo suponiendo que tenemos MUC completo ‘conference1@muc.server.net’ y luego ‘conference1’ debe usarse aquí. Alternativamente, se puede proporcionar un ‘*’, que permite el acceso a todas las salas dentro del dominio.
    ‘room’ contains the name of the room for which the token has been allocated. This is NOT full MUC room address. Example assuming that we have full MUC ‘conference1@muc.server.net‘ then ‘conference1’ should be used here. Alternately, a ‘*’ may be provided, allowing access to all rooms within the domain.
  • ‘exp’ Marca de tiempo de expiración del token como se define en el RFC
    ‘exp’ token expiration timestamp as defined in the RFC
  • ‘sub’ contiene el nombre del dominio utilizado al autenticar con este token. Por defecto, suponiendo que tengamos MUC completo ‘conference1@muc.server.net’, entonces ‘server.net’ debería usarse aquí.
    ‘sub’ contains the name of the domain used when authenticating with this token. By default assuming that we have full MUC ‘conference1@muc.server.net‘ then ‘server.net’ should be used here.
  • ‘aud’.Identificador de la aplicación Este valor indica qué servicio está consumiendo el token. Debe negociarse con el proveedor de servicios antes de generar el token..
    ‘aud’ application identifier. This value indicates what service is consuming the token. It should be negotiated with the service provider before generating the token.

El secreto se usa para calcular el valor hash de HMAC y verificar el token para los tokens HS256.
Secret is used to compute HMAC hash value and verify the token for HS256 tokens.

Alternativamente, el token puede firmarse con una clave privada y autorizarse a través del servidor de claves públicas utilizando tokens RS256. En este modo, el encabezado ‘kid’ del JWT debe establecerse con el nombre de la clave pública. El servidor de fondo debe estar configurado para recuperar y confirmar claves de un servidor de claves público preconfigurado.
Alternately the token may be signed by a private key and authorized via public keyserver using RS256 tokens. In this mode, the ‘kid’ header of the JWT must be set to the name of the public key. The backend server must be configured to fetch and confirm keys from a pre-configured public keyserver.

Identificadores de Token

Además de las afirmaciones básicas utilizadas en la autenticación, el token también puede proporcionar información de visualización del usuario en el campo ‘contexto’ dentro de la carga útil de JWT:
In addition to the basic claims used in authentication, the token can also provide user display information in the ‘context’ field within the JWT payload:

  • ‘group’ es una cadena que especifica el grupo al que pertenece el usuario. Diseñado para su uso en informes / análisis
    ‘group’ is a string which specifies the group the user belongs to. Intended for use in reporting/analytics
  • ‘user’ es un objeto que contiene información de visualización para el usuario actual
    ‘user’ is an object which contains display information for the current user
    • ‘id’ es una cadena de identificación de usuario. Diseñado para su uso en informes / análisis
      ‘id’ is a user identifier string. Intended for use in reporting/analytics
    • ‘name’ es el nombre del usuario que se va a mostrar
      ‘name’ is the display name of the user
    • ‘avatar’ es la URL del avatar del usuario.
      ‘avatar’ is the URL of the avatar for the user
  • ‘Callee’ es un objeto opcional que contiene información de visualización cuando se inicia una videollamada 1-1 con solo otro participante. Solía ​​mostrar una superposición al primer usuario, antes de que el segundo usuario se una.
    ‘callee’ is an optional object containing display information when launching a 1-1 video call with a single other participant. It used to display an overlay to the first user, before the second user joins.
    • ‘id’ es una cadena de identificación de usuario. Diseñado para su uso en informes / análisis
      ‘id’ is a user identifier string. Intended for use in reporting/analytics
    • ‘name’ es el nombre del usuario de callee que se va a mostrar
      ‘name’ is the display name of the ‘callee’ user
    • avatar’ es la URL del avatar del usuario de callee
      ‘avatar’ is the URL of the avatar of the ‘callee’

Identificadores / contexto de token de acceso

Para acceder a los datos en lib-jitsi-meet, debe habilitar el módulo prosody mod_presence_identity en su configuración.
To access the data in lib-jitsi-meet you have to enable the prosody module mod_presence_identity in your config.

VirtualHost "jitmeet.example.com"
    modules_enabled = { "presence_identity" }

Los datos ahora están disponibles como identidad en la clase JitsiParticipant. Puede acceder a ellos por ej. escuchando el evento USER_JOINED.
The data is now available as the identity in the JitsiParticipant class. You can access them by e.g. listening to the USER_JOINED event.

NOTA: Los valores en el token siempre serán valores válidos. Si define p. el avatar como nulo arrojará un error.
NOTE: The values in the token shall always be valid values. If you define e.g. the avatar as null it will throw an error.

Ejemplo de Token

Headers (using RS256 public key validation)

{
  "kid": "jitsi/custom_key_name",
  "typ": "JWT",
  "alg": "RS256"
}

Payload

{
  "context": {
    "user": {
      "avatar": "https:/gravatar.com/avatar/abc123",
      "name": "John Doe",
      "email": "jdoe@example.com",
      "id": "abcd:a1b2c3-d4e5f6-0abc1-23de-abcdef01fedcba"
    },
    "group": "a123-123-456-789"
  },
  "aud": "jitsi",
  "iss": "my_client",
  "sub": "meet.jit.si",
  "room": "*",
  "exp": 1500006923
}

Verificacion del Token

JWT token is currently checked in 2 places:

  • when user connects to Prosody through BOSH. Token value is passed as ‘token’ query paramater of BOSH URL. User uses XMPP anonymous authentication method.
  • when MUC room is being created/joined Prosody compares ‘room’ claim with the actual name of the room. This prevents from abusing stolen token by unathorized users to allocate new conference rooms in the system. Admin users are not required to provide valid token which is used by Jicofo for example.

Lib-jitsi-meet options

When JWT authentication is used with lib-jitsi-meet the token is passed to JitsiConference constructor:

var token = {token is provided by your application possibly after some authentication}

JitsiMeetJS.init(initOptions).then(function(){
    connection = new JitsiMeetJS.JitsiConnection(APP_ID, token, options);
    ...
    connection.connect();
});

Jitsi-meet options

In order to start jitsi-meet conference with token you need to specify the token as URL param:

https://example.com/angrywhalesgrowhigh?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

At current level of integration every user that joins the conference has to provide the token and not just the one who creates the room. It should be possible to change that by using second anonymous domain, but that hasn’t been tested yet.

Installing token plugin

Token authentication can be integrated automatically using Debian package install. Once you have jitsi-meet installed just install ‘jitsi-meet-tokens’ on top of it. In order to have it configured automatically at least version 779 of jitsi-meet is required which comes with special Prosody config template.

apt-get install jitsi-meet-tokens

Proceed to “Patching Prosody” section to finish configuration.

Patching Prosody

JWT token authentication requires prosody-trunk version at least 747.

You can download latest prosody-trunk packages from here. Then install it with the following command:

sudo dpkg -i prosody-trunk_1nightly747-1~trusty_amd64.deb

Asegúrese de que /etc/prosody/prosody.cfg.lua contenga la siguiente línea al final para incluir la configuración de host. Esto se debe a que Prosody nightly puede venir con una configuración predeterminada ligeramente diferente:
Make sure that /etc/prosody/prosody.cfg.lua contains the line below at the end to include meet host config. That’s because Prosody nightly may come with slightly different default config:

Include "conf.d/*.cfg.lua"

Also check if client to server encryption is not enforced. Otherwise token authentication won’t work:

c2s_require_encryption=false

Manual plugin configuration

Modify your Prosody config with these three steps:

1. Ajuste plugin_paths para que apunte a la ruta que apunta a jitsi y la ubicación de los complementos de Prosody. Ahí es donde se copian los complementos en la instalación del paquete jitsi-meet-token. Esto debe incluirse en la sección de configuración global (posiblemente al comienzo de su archivo de configuración de host).
1. Adjust plugin_paths to contain the path pointing to jitsi meet Prosody plugins location. That’s where plugins are copied on jitsi-meet-token package install. This should be included in global config section(possibly at the beginning of your host config file).

plugin_paths = { "/usr/share/jitsi-meet/prosody-plugins/" }

También puede configurar opcionalmente la configuración global para la autorización de clave. Ambas opciones predeterminadas para el parámetro ‘*’ que significa aceptar cualquier emisor o cadena de audiencia en tokens entrantes
Also optionally set the global settings for key authorization. Both these options default to the ‘*’ parameter which means accept any issuer or audience string in incoming tokens

asap_accepted_issuers = { "jitsi", "some-other-issuer" }
asap_accepted_audiences = { "jitsi", "some-other-audience" }

2. Under you domain config change authentication to “token” and provide application ID, secret and optionally token lifetime:

VirtualHost "jitmeet.example.com"
    authentication = "token";
    app_id = "example_app_id";             -- application identifier
    app_secret = "example_app_secret";     -- application secret known only to your token
    									   -- generator and the plugin
    allow_empty_token = false;             -- tokens are verified only if they are supplied by the client

Alternately instead of using a shared secret you can set an asap_key_server to the base URL where valid/accepted public keys can be found by taking a sha256() of the ‘kid’ field in the JWT token header, and appending .pem to the end

VirtualHost "jitmeet.example.com"
    authentication = "token";
    app_id = "example_app_id";                                  -- application identifier
    asap_key_server = "https://keyserver.example.com/asap";     -- URL for public keyserver storing keys by kid
    allow_empty_token = false;                                  -- tokens are verified only if they are supplied

3. Enable room name token verification plugin in your MUC component config section:

Component "conference.jitmeet.example.com" "muc"
    modules_enabled = { "token_verification" }

Otro sitio más de Los Lucero