Resumen
Se trata de construir un Punto de Acceso General (PAG) desde donde los ciudadanos puedan conocer y acceder todo lo que las Administraciones Públicas tienen de ellos.
Servicios de identificación
- NIF/NIE/otro documentación admitida -pasaporte, identificador de la seguridad social, permiso de residencia, carnet de estudiante, carnet profesional, ...-)
- nombre, apellidos
- teléfono móvil
- correo electrónico
- Se podría añadir el idioma como dato a capturar y posteriormente a transferir entre los distintos portales integrados con el PAG.
El registro no solo estaría abierto a personas físicas, si no a entidades con o sin CIF. Así mismo, se permitiría el que existiesen distintos usuarios del tipo entidad con el mismo CIF, de forma que entidades divididas en departamentos con autonomía en la gestión, puedan tener su propio usuario manteniendo la confidencialidad de cada uno de los procedimientos soportados por cada departamento.
Así mismo se permitiría el acceso con certificado electrónico, de forma que esa información también pudiera ser transmitida entre los portales integrados con el fin de ofrecer más servicios a aquellos usuarios registrados con esa identidad fuerte. Estos usuarios también tendrían asignados un usuario y contraseña, de forma que una vez identificados con certificado electrónico, puedan identificarse con usuario y contraseña (más sencillo de utilizar desde cualquier dispositivo) sin perder su característica de usuario verificado.
En el caso de que un usuario con certificado digital se registrase en la plataforma y ese mismo usuario ya existiera (alguien hubiera intentado suplantarle empleando sus datos de filiación), se le obligará a cambiar la clave y se avisará del hecho de forma que el afectado pueda tomar las medidas que considere pertinentes, o al menos, revise los trámites que se han realizado en su nombre.
Integración de sistemas de tramitación externas con el PAG
Todo sistema que se integre con el PAG deberá realizar al menos tres pasos imprescindibles:
Alta de procedimientos
La integración de los distintos procedimientos soportados por plataformas externas e integrados con el PAG se caracterizará por la utilización de los siguientes parámetros:
- nombre del trámite
- código del procedimiento (puede que para un mismo procedimiento existan distintas versiones, situación típica en los procedimientos basados en convocatorias de carácter periódico y repetitivo)
- Información de ayuda
- página web
- teléfono
- correo electrónico
- otros datos de contacto (RRSS, ...)
- ¿cómo tramitar? documento explicativo, preferentemente visual, que explique la tramitación dle procedimiento
- información sobre el trámite a utilizar en un buscador
- Palabras de búsqueda a utilizar en el buscador
- Forma de tramitación:
- sin certificado digital se puede realizar toda el procedimiento
- sin certificado digital se puede hacer parte del procedimiento (típicamente, el paso al registro electrónico requiere el uso de un certificado digital)
- sin certificado digital no se puede hacer ninguna gestión en el procedimiento
- Si el procedimiento necesita la presentación de alguna documentación en papel de forma inexcusable (originales, fotocopias comuplsadas, ..)
- Fecha de inicio y fin de presentación de solicitudes o procedimiento siempre abierto
- Información técnica de ayuda a la integración del PAG con la plataforma donde reside el procedimiento
- Si el trámite requiere que el usuario esté previamente identificado en el PAG o también permite el acceso al mismo sin registro previo siempre que se identifique con certificado electrónico (se permite este acceso sin registro previo para facilitar el acceso a ciertos trámites de carácter informativo donde el registro previo puede ser una barrera de entrada, como por ejemplo, conocer los puntos del carnet de conducir o los títulos universitarios del interesado)
- Información interna de la Administración, muy relacionada con lo que actualmente puede contener la base de datos de procedimientos de la AGE (Ministerio, unidad, responsable, ...)
- Parámetros técnicos de integración de aplicación (descritos con posterioridad):
- servicio web de consulta de solicitudes
- URL de acceso general manteniendo la identificación del PAG
- URL de acceso general sin mantener la identificación (requerirá login en la plataforma externa)
- URL de alta de nuevas solicitudes manteniendo la identificación del PAG
Facilidades del PAG
El PAG dispondrá de un buscador de procedimientos donde se facilite la labor del interesado basándose en los datos que previamente se han rellenado en el alta de cada procedimiento
Implementación de los servicios web de integración
Si nos retrotraemos a la funcionalidad que se quiere implementar con el PAG no es si no la de poder conocer los trámites que tiene toda las AAPP del interesado identificado en el sistema y poder acceder a cada uno de ellos o iniciarlos. Se trata pues de que el ciudadano disponga de buscar qué procedimientos ha iniciado en todas aquellas plataformas integradas con el PAG. Algo así como un botón "Mis trámites" que una vez pulsado busque en todas las plataformas externas información sobre el interesado.
Para ello es necesario que las plataformas externas dispongan de:
Servicio web de consulta a utilizar por el PAG: ¿tienes algo de este usuario?, ¿dame detalles de lo que tienes?
El PAG mandará como parámetros de entrada
- el código del procedimiento (por si una misma aplicación externa maneja varios procedimientos)
- datos de filiación del interesado (nombre, apellidos, documento identificativo -incluido si es una entidad con departamento-, correo electrónico, ..)
- se deberá tener la posibilidad de enviar una lista con los antiguos documentos asociados al interesado, para facilitar la integración en un solo usuario de aquellos usuarios que cambian de documento (por ejemplo, con el paso de NIE a NIF)
- nivel de identificación en el PAG: indicación de si alguna vez el usuario se identificó en el PAG con certificado electrónico
Como resultado, la aplicación remota devolverá un código con tres valores distintos, que combinado con sucesivas consultas para conocer los detalles de cada solicitud nos da el siguiente escenario
- No confía en la identidad del ciudadano y por tanto no puede informar de si existe algún procedimiento asociado al mismo. La plataforma de destino requiere un nivel de identificación superior (certificado digital) al que el interesado utilizó para identificarse en el PAG.
- facilidades de acceso a la plataforma de tramitación externa:
- se le muestra al interesado un enlace de acceso a la plataforma externa que requiere identificación previa (basado en el campo "URL de acceso general sin mantener la identificación (requerirá login en la plataforma externa")
- El interesado no ha participado en el procedimiento.
- facilidades de acceso a la plataforma de tramitación externa:
- se le muestra al interesado un enlace de acceso a la plataforma externa que no requiere identificación previa (basado en el campo "URL de acceso general manteniendo la identificación del PAG")
- se le muestra al interesado un enlace de acceso directo para crear una solicitud en la plataforma externa (basado en el campo "URL de alta de nuevas solicitudes manteniendo la identificación del PAG")
- El interesado ha participado en el procedimiento
- facilidades de acceso a la plataforma de tramitación externa:
- se le muestra al interesado un enlace de acceso a la plataforma externa que no requiere identificación previa (basado en el campo "URL de acceso general manteniendo la identificación del PAG")
- se le muestra al interesado un enlace de acceso directo para crear una solicitud en la plataforma externa (basado en el campo "URL de alta de nuevas solicitudes manteniendo la identificación del PAG")
- se le muestra al interesado información de cada una de las solicitudes basándose en la información devuelta por el servicio web (se necesitaría estandarizar la información a devolver, que en todo caso podría consistir en:
- número de solicitud
- estado de la solicitud
- fecha de alta
- fecha de última modificación
- fecha de registro
- campo para un texto libre a utilizar de manera discrecional por la aplicación externa
- URL con el enlace de de acceso directa a cada una de ellas manteniendo la identificación del PAG, basándose también en la información que devuelva el mismo servicio web.
Adicionalmente, y para dotar de mayor capacidad de gestión en el acceso a la información por parte de las aplicaciones remotas, se dispondrá de un parámetro en el servicio web que permita flexibilizar la informaicón a mostrar más allá de los tres casos anteriores. Así, independientemente de esos casos y de las situaciones e información a mostrar allí descritas, la aplicación remota podrá indicar si:
- se muestra el enlace de acceso general a la aplicación externa y el enlace de acceso a cada una de las solicitudes según los casos anteriormente descrito
- no se muestra el enlace de acceso general a la aplicación externa pero si el enlace de acceso a las solicitudes si las hubiera (la aplicación externa está "cerrada" pero permito la consulta de los expedientes ya cursados)
- se muestra el el enlace de acceso general a la aplicación externa pero no el enlace de acceso a las solicitudes si las hubiera (por la razón que fuera no se quiere hacer público el acceso a los expedientes)
- no se muestra el el enlace de acceso general a la aplicación externa pero no el enlace de acceso a las solicitudes si las hubiera (solo se informa de las solicitudes existentes pero no se permite acceder a mayor información sobre las mismas y tampoco a la aplicación externa al PAG)
La aplicación remota también devolverá al PAG una indicación sobre si este debe o no debe mostrar el botón de acceso general (posteriormente vemos de donde se obtiene esta información) a la misma, de forma que
- y el PAG ofrecerá el acceso directo a cada una de las posibles solicitudes dentro del procedimiento implicado. Así mismo, también se ofrecerá la posibilidad de acceder directamente a dar de alta una solicitud en la plataforma externa. En ambos casos, no será necesario volver a identificarse.
Como ya veremos posteriormente, el PAG ofrecerá al interesado la posibilidad de acceder directamente a dar de alta una solicitud en la plataforma externa sin necesidad de volver a identificarse.
Sistema de login único
Existen muchas formas de construir un sistema de login único, ya sea basadas en soluciones comerciales o en soluciones de código abierto basadas en el uso de tokens o similares. Como lo que se trata es de integrar plataformas de tramitación ya existentes con el nuevo PAG, lo más lógico sería la utilización de sistemas lo menos intrusivos posibles. Siguiendo esa tendencia, una posible aproximación de muy sencilla implementación sería la siguiente
Para permitir el paso de el PAG a las aplicaciones externas sin que el usuario deba volver a identificarse se utilizará un sistema basado en un código de sesión.
La sesión de un usuario se identifica a través de un código único e irrepeible. Dicho código es concatenado a las URLs que proporcionan acceso autenticado a las aplicaciones externas mediante un parámetro de tipo GET, por lo que todas las direcciones que se faciliten para accesos autenticados (acceso general, alta de solicitud y consulta de solicitud) deben finalizar con la especificación de un parámetro GET que contendrá el código de sesión (el nombre del parámetro es indiferente). Un ejemplo podría ser el siguiente:
https://sede.ministerio.gob.es/AplicacionTramitacionExpdte/versolicitudtud.jsp&<nombre_del_parametro_a_utilizar_aplicacion_externa>=<valor del código>
Una posible construcción del código podría ser la utilización de un hash a partir de:
- documento del usuario
- código interno de la aplicación.
- fecha en milisegundos
- el tiempo en milisegundos
Cuando un aplicación integrada es llamada a través de una URL generada por el PAG debe utilizar el código de sesión que se le transmite para identificar al usuario logado. Para ello, una vez recogido el código de sesión, la aplicación externa puede utilizar unos servicios web desplegados en el PAG que tienen el objetivo de gestionar los usuarios registrados en el PAG. Así podría obtener los datos del usuario logado en el PAG.
Puede darse el caso de que el usuario identifico en el PAG no esté dado de alta en la aplicación externa (por ser la primera vez que accede a ella, por ejemplo), lo que supondrá que esa aplicación externa tendrá que hacer las tareas asociadas a una primer alta, pudiendo solicitar al usuario algún dato específico adicional a los que proporcionó cuando se registró en el PAG, teniendo en cuenta que los datos proporcionados en el PAG en el proceso de registro deberán estar bloqueados de forma que no se puedan cambiar en la aplicación externa (ni por parte de los gestores ni por parte de los solicitantes). Los datos adicionales suministrados permanecerán en la aplicación externa sin comunicarse al PAG, ya que se consideran necesarios únicamente para la tramitación del procedimiento en cuestión.
La seguridad del token utilizado para validar la sesión es transparente a las aplicaciones externas y funciona de la siguiente manera:
- cuando el usuario 'pincha' en cualquiera de los enlaces que le llevan a la aplicación externa, realmente la petición se encamina al PAG que calcula el token, donde se incluye el tiempo de generación
- una vez calculado, se envía un redirect al navegador cliente para que este realice la correspondiente petición (GET) a la aplicación externa
- cuando la aplicación externa recibe el token, lo tiene que validar contra u servicio web del PAG, y es este servicio web el que, confrontando el tiempo en el que el token fue generado y el tiempo en que recibe la petición de validación, valida o no el token
Durante el tiempo de validez del token, este puede ser utilizado cuantas veces se quiera, siendo este el único punto débil de la solución. Por ejemplo, si el usuario es capaz de copiar la URL de la aplicación externa -la que es envíada en el redirect y que incluye la información del token) y se la envía por correo electrónico a un conocido, este, sin necesidad de autenticarse podrá entrar a las solicitudes del originario del mensaje, que lo que creía que hacía era mandar la URL de acceso a la aplicación y no mandaba el acceso a su expediente.
Recordamos que este comportamiento se dará mientras que el token es válido, luego cuanto menor sea su tiempo de validez, más seguridad se tiene. ¿Cuál puede ser el tiempo aconsejado? Si se analiza el proceso, ni el PAG, ni la aplicación externa ni el servicio web de consulta dle token tienen por qué tardar mucho en
contestar ni en procesar la información y el consumo de tiempo se realiza en el transcurso en el que el redirect y el get viajan por la red, es decir, dependiendo de la velocidad de la conexión del navegador cliente. Se podría considerar un token válido durante 30 segundos.
En el caso de que se recibiera un token con el tiempo expirado y que por tanto la aplicación externa recibiera la correspondiente indicación por parte de los servicios web del PAG, aquella debería informarlo al ciudadano, indicando que deberá volver a entrar al PAG a generar la sesión de usaurio (el PAG, en la página donde se muestra el acceso a la aplicación externa y a las solicitudes podría colocar un botón con una leyenda adecuada para la ocasión y que al pincharla sirviera para recalcular todos los enlaces mostrados en la ventana)
Al sistema expuesto le faltaría el permitir el enlazar el acceso desde aplicaciones externas entre si, ya que el modelo diseñado siempre implica el paso por el PAG para acceder a una aplicaci´pon externa, no permitiendo el paso entre aplicaciones externas entre si.
Otras facilidades para la gestión de usuarios en el PAG
Puede darse el caso de que los gestores de las aplicaciones externas puedan dar de alta solicitudes en sus sistemas de tramitación interna que quieran que estén disponibles a través del PAG. Para ello, el PAG debería contar con unos servicios web que permitieran gestionar los usuarios en ella registrados, no solo en la consulta para conocer si ya están dados de alta, si no sobre todo, permitir nuevas altas por parte de esaas aplicaciones de tramitación.
Funcionalidades en la aplicaciones externas integradas con el PAG
Adicionalmente a todas las funcionalidades comentadas con anterioridad, es necesario recalcar otras características que deben incorporar las aplicaciones externas integradas con el PAG:
- el usuario no tendrá un interfaz para modificar los datos con los que se registró en el PAG incluyendo la clave
- aunque la aplicación externa posea una tabla de usuarios, la información para la identificación del usuario debe obtenerse de las funcionalidades que ofrezca el PAG
- es recomendable que la aplicación externa no tenga una pantalla de identificación disponible para el usuario, ya que de esa forma el usuario final podrá acceder a dicha aplicación a través de dicha pantalla, obviando las facilidades que ofrece el PAG y perdiendo la visión globalizadora de esta, con la consiguiente pérdida de información sobre otros procedimientos en los que interaccionó con las AAPP
- sería conveniente que las aplicaciones externas mantuvieran accesibles los procedimientos ya cerrados o caducados, de forma que el interesado pueda tener una información histórica de toda su relación con las AAPP y no solo aquella relacionada con procesos en curso
¿Y cuánto se tardaría en montar todo esto? Esta es la parte más sencilla del asunto. La parte que corresponde al PAG ya está desarrollada y funcionando en entornos intraministeriales. Y de ahí a la pregunta del millón, ya dejo que te la hagas tú, estimado lector.
No hay comentarios:
Publicar un comentario