De plugin interno a producto protegido
Overview
La empresa tenía un potente plugin interno de Tekla Structures, pero no podía entregarlo a contratistas externos sin poner en riesgo su propiedad intelectual: cualquiera podía copiar las DLL del directorio de Tekla y repartirlas.
Construimos un sistema de licenciamiento de tres capas:
- un panel de administración (Blazor),
- un cliente de escritorio (WPF),
- un motor de compilación que en cada descarga compila, cifra y firma una copia única del plugin, ligada al identificador de hardware del usuario.
Los contratistas trabajan hoy con la misma herramienta que el equipo interno. La empresa decide quién la recibe, en qué máquina y hasta cuándo, todo desde una sola interfaz, y ninguna de las partes necesita confiar a ciegas en la otra.
Antecedentes
El cliente volvió con el plugin de Tekla Structures que habíamos construido juntos antes, el conjunto de herramientas que genera sus paneles LGSF. Al tomar contratos más grandes, el equipo interno ya no daba abasto con el volumen, así que sumar contratistas externos, desde ingenieros individuales hasta empresas completas, era la única vía práctica de crecer. El problema era que el plugin es propietario: distribuirlo sin protección no era una opción. Necesitaban una forma de dar acceso a los contratistas conservando el control total sobre quién usa la herramienta, en qué máquina y por cuánto tiempo.
Problema
Por qué la protección estándar no alcanzaba
Partimos por definir exactamente qué había que proteger y de qué. Una simple clave de serie no sobrevive en este entorno: el plugin corre dentro de Tekla Structures, donde el usuario tiene acceso completo al sistema de archivos, así que los propios ensamblados se pueden copiar y compartir. El licenciamiento tenía que ligar cada copia a una máquina concreta, imponer un límite de tiempo y resistir manipulaciones incluso si el usuario cambiaba el reloj del sistema.
El plugin son DLL que viven en el directorio de Tekla Structures, legibles por quien las ejecuta.
Una clave de serie no protege nada si los archivos mismos se pueden copiar.
Las licencias debían caducar solas, sin confiar en el reloj local.
La empresa necesitaba otorgar y revocar accesos por persona y por máquina.
Solución
Diseñamos un sistema de tres capas, cada una a cargo de una parte concreta del flujo de licenciamiento:
Servidor: Windows Server con IIS
Guarda las cuentas, las licencias y las fuentes del plugin. Autentica a los usuarios, registra a qué máquina está ligada cada licencia, controla las fechas de vencimiento y ejecuta el proceso de compilación cuando se solicita. Que sea Windows no es un detalle de implementación: el plugin apunta a .NET Framework 4.8, así que la compilación tiene que correr en un host Windows.
Cliente: la aplicación LSTK
Una aplicación de escritorio en WPF con la que los usuarios se autentican y descargan el plugin. En el momento de la descarga, envía al servidor la clave de hardware de esa máquina: el número de serie de la placa madre.
Motor de compilación y protección
En cada solicitud de descarga el servidor ejecuta un ciclo completo de build: compila el plugin desde el código fuente, lo cifra con claves privadas del lado del servidor y calcula un checksum hash para impedir manipulaciones. Cada copia licenciada se compila de verdad para su usuario, en lugar de salir de un único binario compartido. El resultado es un ensamblado cifrado, ligado a una máquina y con fecha de vencimiento definida.
Sistema de licenciamiento LGSF — arquitectura
Cómo funciona
Desde la cuenta de usuario hasta el plugin funcionando, todo el recorrido son cinco pasos:
El administrador crea la cuenta de usuario
El administrador registra al usuario en el panel Blazor y le asigna un tipo de licencia y una duración.
El usuario inicia sesión en la aplicación LSTK
El usuario abre la aplicación de escritorio, ingresa sus credenciales y se autentica contra el servidor.
La descarga dispara la generación de la licencia
Al hacer clic en Descargar, la aplicación envía al servidor la clave de serie de hardware del computador, y el servidor compila, cifra y firma el plugin, creando una copia única para esa máquina.
El plugin se instala en Tekla Structures
El plugin cifrado se coloca directamente en el directorio correcto de Tekla Structures. Funciona solo en ese computador y solo durante el período asignado.
Renovación mediante una nueva descarga
Cuando la licencia vence, el usuario vuelve a hacer clic en Descargar en la aplicación LSTK. Si el administrador aprobó la renovación, se genera una copia licenciada nueva.
Flujo de licenciamiento LGSF paso a paso
Resultado
El plugin pasó de ser un archivo en un pendrive a un producto de software controlado y distribuible. Tras el primer mes de uso:
Los contratistas externos reciben la misma herramienta que el equipo interno, sin riesgo de exponer la propiedad intelectual.
Cada copia queda ligada criptográficamente a una máquina y caduca por sí sola.
Todas las licencias se gestionan desde una única interfaz de administración: quién tiene acceso, en qué equipo y hasta cuándo.
Incorporar a un contratista es crear una cuenta y una descarga, no una negociación sobre confianza.
+15%
Capacidad de ingeniería
10
Horas de onboarding ahorradas
Tecnologías
Windows Server con IIS
C#
Blazor Server
WPF
Tekla Open API
Otros casos
De modelado manual a diseño de marcos de acero basado en datos
Cómo reemplazamos un flujo BIM manual de 3 a 5 días por la generación automática de modelos a partir de datos de análisis estructural, reduciendo el tiempo de modelado en más de un 90% y eliminando discrepancias entre el análisis y el diseño
Del modelado manual al diseño LGSF automatizado
Una empresa de estructuras de acero liviano seguía diseñando sus paneles en CAD 2D, mientras fabricación exigía LOD 500. Convertimos sus reglas de diseño en un conjunto de plugins para Tekla
Descubre dónde estás perdiendo tiempo y dinero ahora mismo
