Un portal de clientes, una intranet y una aplicación web pueden compartir tecnología, pero atienden usuarios y tareas diferentes. Define quién entra, qué información puede consultar y qué acción necesita completar. La selección debe partir del proceso y sus permisos, no de una etiqueta de producto.
APLICABILIDAD
¿Dónde importa esta decisión?
- Empresas de servicios
- Equipos de marketing y operaciones
Distingue usuarios externos, internos y procesos compartidos
Un portal suele facilitar autoservicio a clientes o socios; una intranet organiza información y trabajo interno; una aplicación web puede resolver un proceso específico de cualquiera de esos grupos. Estas categorías se superponen. El requisito importante es describir tareas, datos y límites de acceso, no forzar el proyecto dentro de una clasificación rígida.
Mapea el recorrido actual incluyendo correo, documentos y sistemas existentes. Si el portal solo añade otra pantalla que exige al equipo copiar información manualmente, quizá no reduzca trabajo. Identifica dónde vive el dato oficial y quién lo actualiza. La visibilidad de un estado es útil únicamente si corresponde a la operación real.
Diseña permisos por recurso y acción
No confundas iniciar sesión con tener autorización para ver cualquier documento. Define qué puede consultar, crear o modificar cada usuario y cómo se relaciona con una organización o expediente. OWASP recomienda comprobar permisos en cada solicitud. Ocultar un botón no sustituye impedir que alguien acceda directamente a un recurso que no le corresponde.
Prueba dos organizaciones con datos separados y varios roles. Un usuario de una no debe obtener archivos de la otra cambiando un identificador. Incluye revocación de acceso, usuarios que cambian de función y enlaces compartidos. Los archivos descargables requieren el mismo cuidado que las pantallas; una ruta pública puede anular controles correctos en el portal.
Valida autoservicio y operación posterior
Ejemplo de primera entrega: consultar estado, descargar un documento permitido y solicitar una corrección. Define confirmaciones, tiempos de actualización y responsable de atender la solicitud. No prometas actualización inmediata si el sistema de origen se sincroniza por lotes. Explicar esa limitación puede evitar consultas y expectativas que la tecnología todavía no satisface.
Evalúa si las personas completan tareas sin asistencia y si disminuye trabajo manual real. Conserva soporte para excepciones y evita retirar el canal anterior antes de comprobar adopción. Documenta recuperación, registros y administración de permisos. Una aplicación útil no es solo la interfaz: incluye el proceso que mantiene información correcta y resuelve problemas después de entrar.
ENTIDADES ANALIZADAS
FUENTES
Referencias utilizadas.
- Diseño y validación de autorizacionesOWASP Cheat Sheet Series
PREGUNTAS FRECUENTES
Respuestas breves para decidir.
¿Un portal y una intranet son lo mismo?
No necesariamente. Suelen atender públicos diferentes, pero pueden compartir funciones. Define usuarios, tareas y límites de acceso antes de elegir nombre o tecnología.
¿Basta con una contraseña para proteger documentos?
No. Hay que comprobar autorización sobre cada recurso y acción, incluyendo descargas y accesos directos. También deben probarse revocaciones y separación entre organizaciones.
¿Qué conviene incluir primero?
Un recorrido de autoservicio completo y verificable, con datos confiables y atención de excepciones. Evita lanzar muchas pantallas que dependen de procesos aún no resueltos.