CONECTORES / LTI 1.3
Módulo LTI 1.3 de P2LRN
P2LRN incluye un proveedor LTI 1.3 universal y self-hosted: valida lanzamientos OIDC/JWT, publica JWKS, ofrece catálogo y Deep Linking, ejecuta el mismo Player, persiste estado por alumno/intento y puede entregar calificaciones mediante AGS. No es un plugin distinto para cada LMS ni forma parte del ZIP del curso.
Código fuente del proveedor LTI 1.3
El ZIP técnico incluye el código actual de integration/lms: proveedor criptográfico, servidor HTTP, store SQLite, cliente AGS, contratos de lanzamiento y pruebas. También incluye el Host Adapter necesario para la frontera con Player. No es un plugin específico de Moodle/Canvas/Sakai/Chamilo/Open edX ni un binario precompilado.
Node.js 22.13+ y distribuciones compiladas de Toolkit y Player. Para un despliegue real se necesita además una clave RSA persistente, almacenamiento privado y un proxy HTTPS de confianza.
node integration/lms/lti-server.mjs inicia el proveedor después de configurar sus variables de entorno. Por defecto escucha en loopback.
El proveedor contempla validación JWT, issuer/audience, nonce/state, protección frente a replay, Deep Linking, persistencia, Player, AGS OAuth y aislamiento entre instituciones.
p2lrn.org no es un gateway LTI multiinstitución para registrar directamente en un LMS. Cada despliegue debe alojar el proveedor en una URL HTTPS propia, conservar sus claves y registrar explícitamente sus plataformas de confianza.
Arquitectura: un único Player
El LMS conserva estudiantes, docentes, matrículas y libreta de calificaciones. El gateway comprueba la identidad y selecciona el contenido publicado; el Host Adapter gestiona carga y guardado de estado, eventos y notas. Player abre siempre el mismo .p2lrn, independientemente del fabricante del LMS.
OIDC: inicio y lanzamiento seguro
- El administrador registra explícitamente la plataforma mediante
issuer,client_id, despliegues permitidos, URLs de autorización/token y claves JWKS confiables. /lti/logincrea una transacción constateynonceúnicos y de vida corta./lti/launchvalida la firma RS256 y los claimsiss,aud/azp,exp,iat, versión, tipo,deployment_id,target_link_uriy binding autorizado.stateynoncese consumen para bloquear replay antes de crear la sesión de runtime.
Estas comprobaciones viven en el backend. El navegador sólo recibe una sesión limitada para el contenido ya autorizado.
JWKS y claves públicas
El proveedor publica su conjunto de claves en /lti/jwks y firma respuestas de Deep Linking con su clave RSA persistente. Para validar al LMS sólo utiliza claves pertenecientes a registros administrativos de confianza; una URL recibida desde un JWT desconocido no se convierte en fuente confiable.
Las claves privadas, el token administrativo, SQLite y el catálogo de paquetes permanecen fuera de la web pública y fuera de cada .p2lrn.
Deep Linking: elegir curso y lección
El servidor implementa catálogo y selector protegido. Un profesor puede elegir un curso, unidad o actividad publicada y el proveedor devuelve un ltiResourceLink firmado con un p2lrn_binding_id opaco ligado a tenant, registro, despliegue, paquete, contentRoot y entidad.
packageId + contentRoot + entityId identifica contenido y revisión.
El vínculo opaco evita confiar únicamente en resource_link.id, que puede cambiar al copiar cursos.
Un administrador puede crear un binding manual autorizado mediante POST /lti/admin/bindings y configurar su valor opaco como parámetro personalizado del LMS.
Ni el profesor ni el alumno pueden elegir una URL o entidad arbitraria para saltarse el catálogo autorizado.
AGS: enviar calificaciones
El proveedor implementa Assignment and Grade Services. El navegador puede reportar una observación, pero una nota oficial sólo se envía después de que el servidor la valide como autoritativa. POST /lti/admin/grades registra la decisión y utiliza un outbox persistente e idempotente para el envío OAuth2.
Con scope lineitem.readonly puede localizar y reutilizar una columna compatible del mismo resourceLinkId, respetando su scoreMaximum.
Sólo se crea una nueva cuando el LMS concedió explícitamente el scope de escritura lineitem.
Los fallos permanecen en /lti/admin/ags/pending y pueden reintentarse sin aceptar redirecciones o destinos ajenos al LMS registrado.
NRPS: roles y matrículas (opcional)
NRPS sigue siendo opcional y no está implementado actualmente en este módulo. Los roles del lanzamiento LTI sí se validan dentro de los claims firmados. No se debe anunciar sincronización de listas de alumnos mediante NRPS hasta implementar y probar ese servicio.
Estado actual del proveedor
createP2LRNLtiProvider(), createP2LRNLtiServer() y SQLite persistente para registros, despliegues, catálogo, bindings, transacciones, sesiones, intentos, estado, eventos y outbox AGS.
Firma/verificación JWT, state/nonce/replay, catálogo, selector y respuesta Deep Linking firmada.
Runtime autorizado, carga/guardado de estado y eventos, inspección de intentos, OAuth2 AGS, reutilización segura de lineitems y reintentos persistentes.
NRPS no forma parte de este módulo. La compatibilidad con una instalación concreta de Moodle, Canvas, Sakai, Chamilo u Open edX debe validarse con la versión, configuración y políticas reales del LMS antes de utilizar esa integración.
El servidor implementa /lti/login, /lti/launch, /lti/deep-link, /lti/deep-link/confirm, /lti/jwks, /lti/health, runtime y administración. Esas rutas pertenecen a tu despliegue del proveedor, no a la web estática de P2LRN.
Seguridad y aislamiento multiinstitución
- Validar criptográficamente JWT y comprobar
iss,aud,azp,exp,iat,nonce,state, versión, tipo de mensaje ydeployment_id. - Consumir cada transacción una sola vez; prevenir replay y acceso entre instituciones o despliegues.
- Particionar el progreso por institución, despliegue, vínculo, alumno, intento, paquete, revisión y actividad.
- No exponer claves privadas, credenciales del LMS, datos personales ni tokens dentro de un
.p2lrno URLs del navegador. - Rechazar cualquier acceso a un contenido no publicado, actividad inexistente o servicio no autorizado.
- Verificar en servidor los resultados antes de transmitir notas oficiales.
Flujo docente y alumno implementado
El administrador registra una plataforma y despliegues explícitos, catálogo y bindings; emisores/despliegues desconocidos se rechazan.
Deep Linking muestra sólo contenido publicado y devuelve un recurso firmado ligado a la revisión.
OIDC/JWT valida identidad y despliegue, crea una sesión limitada y abre el mismo Player P2LRN.
El runtime persiste estado/eventos por sesión e intento. Una decisión de nota validada puede enviarse a AGS mediante el outbox.
Este circuito está cubierto por pruebas HTTP automatizadas del proveedor. La comprobación contra cada LMS real debe realizarse además en la instalación y versión que vaya a utilizarse.
Comprobación antes del despliegue
- Construir Toolkit y Player, generar una clave RSA persistente y desplegar el servidor tras HTTPS; no exponer el token administrativo, la clave privada, SQLite ni el directorio de paquetes.
- Registrar issuer, client ID, deployment ID, URLs y JWKS de la instancia LMS real; comprobar
/lti/healthy/lti/jwks. - Publicar un
.p2lrnreal en el catálogo y verificar Deep Linking o binding manual autorizado. - Probar profesor y alumno: login, launch, Player, reanudación, expiración, replay, acceso denegado y copia de curso.
- Cuando haya AGS, comprobar la columna y la nota en el libro real. No declarar NRPS ni compatibilidad universal donde no se haya probado.
- Repetir la matriz con cuestionarios, juegos 3D, SCORM/H5P, móvil y políticas de cookies/iframes de la versión concreta del LMS.
Más información del estándar en 1EdTech LTI. Para las diferencias por plataforma consulta Conectores LMS.