Anexo
Número:
IF-2018-09344965-APN-DNSAYFD#MM
CIUDAD DE BUENOS AIRES
Viernes 2 de Marzo de 2018
Referencia: Anexo I - Módulo de
Interoperabilidad INTEROPER.AR
RESOLUCIÓN
SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA
ANEXO I
DESCRIPCIÓN MÓDULO DE
INTEROPERABILIDAD DECRETO N° 1273/2016
I.- Propósito
El presente documento tiene como objetivo definir las características
del módulo de INTEROPERABILIDAD, en adelante INTEROPER.AR, administrado
por la DIRECCIÓN NACIONAL DE SISTEMAS DE ADMINISTRACIÓN Y FIRMA
DIGITAL, dependiente de la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA
del MINISTERIO DE MODERNIZACIÓN
II.- Breve descripción de INTEROPER.AR
El presente documento describe el módulo INTEROPER.AR del Sistema de
Gestión Documental Electrónica - GDE.
INTEROPER.AR es una capa de interoperabilidad que permite la
interoperabilidad y el intercambio seguro de datos entre sistemas
informáticos de gobierno.
Los organismos alcanzados por el Decreto N° 1273/2016 pueden utilizar
el módulo INTEROPER.AR para facilitar, por ejemplo, la gestión de
oficios judiciales, la tramitación interna que requiere datos o
información disponible en otro organismo, o el suministro a terceros de
datos o información en forma ágil, segura y con valor legal.
III.- Composición
1.- INTEROPER.AR se compone de:
1.1. El módulo de interoperabilidad que puede ser adoptado por todos
los organismos que exponen sus servicios
1.2. Un esquema de autenticación, reglas y protocolos para facilitar
las comunicaciones de forma directa y segura entre sistemas
1.3. Un Directorio de servicios
1.4. El Marco normativo
1.5. La Autoridad Central de administración del módulo.
1.6. Los sistemas informáticos o bases de datos distribuidas de las
entidades y jurisdicciones proveedores de información.
2. - La autenticación entre sistemas informáticos o bases de datos que
utilizan el modulo INTEROPER.AR está basada en estándares, es
administrada por un organismo central pero la autorización y las bases
de datos y los servicios permanecen distribuidos y autónomos, bajo la
administración y exclusivo control de las entidades o jurisdicciones
que los implementan.
3. - Conectarse a INTEROPER.AR permite a los organismos ahorrar costos
y tiempos, porque acceden a una multiplicidad de servicios y bases de
datos ofrecidos por otros organismos sin la dificultad de desarrollar
soluciones para cada integración. Además le garantiza que todas las
solicitudes de información que le llegan a través de INTEROPER.AR están
debidamente autenticadas por un órgano central. La administración y
autorización de quién accede a los datos propios del organismo se
mantiene bajo exclusivo control de cada jurisdicción.
4. - INTEROPER.AR es un acelerador para el desarrollo de mejores
soluciones al ciudadano, porque permite aplicaciones y servicios más
inteligentes, que no preguntan lo que el Estado ya sabe y le acercan al
ciudadano la información que requiere, sin imponer barreras
innecesarias basadas en estructuras organizacionales.
5. - INTEROPER.AR provee a los organismos respuestas con total valor
jurídico, emitidas por la autoridad competente para responder en
función de las competencias sustantivas que posee y los datos que
administra, ya que cada dato es provisto por el organismo que tiene
competencia sobre él. Evita la duplicidad de datos, los padrones y
bases de datos no actualizadas, las inconsistencias entre sistemas,
brindando un servicio de respuesta automática, con datos actualizados.
6. - INTEROPER.AR garantiza el origen y el valor probatorio de cada
solicitud y de cada respuesta, porque cada una tiene asociada una firma
digital del sistema que la emite.
IV.- Funcionamiento
1.- Autenticación de los sistemas informáticos y bases de datos.
El módulo INTEROPER.AR brinda un servicio de autenticación de los
sistemas informáticos y bases de datos que lo integran.
Este servicio de autenticación está centralizado en la autoridad que lo
administra, la DIRECCIÓN NACIONAL DE SISTEMAS DE ADMINISTRACIÓN Y FIRMA
DIGITAL, que gestiona las altas y bajas de los sistemas informáticos y
bases de datos en el módulo INTEROPER.AR.
2.- Directorio interno de servicios.
El certificador a su vez mantiene un servicio dentro de INTEROPER.AR
que es el directorio interno de servicios. Este directorio contiene
toda la información necesaria para conectarse a los demás nodos de
INTEROPER.AR - tanto información de uso, como documentación de APIs y
endpoints, incluyendo también información de ubicación dentro de la red.
3. - Publicación de servicios.
Una vez que un sistema informático o base de datos está conectado a
INTEROPER.AR puede publicar servicios usando los estándares de
interoperabilidad vigentes y consumir los servicios de otros sistemas.
Cada invocación a un servicio se realiza punto a punto. Esto hace a la
red robusta y tolerante a fallas y más segura, ya que no hay un solo
punto de falla. Cada solicitud emitida o recibida es autenticada,
cifrada y registrada para auditoría.
4. - Proveedores de servicios.
El modulo INTEROPER.AR facilita la interacción entre los organismos, ya
que prevé su interoperabilidad, mediante un procedimiento sencillo y
robusto desde el punto de vista de seguridad informática y jurídica.
Para integrar un sistema provisto por otro miembro de INTEROPER.AR, el
organismo debe consultar el servicio de directorio. Con la información
del directorio se realiza una conexión directa hacia el proveedor del
servicio. Esta conexión puede ser por internet. El solicitante remite a
través de INTEROPER.AR una solicitud de servicio con firma digital y se
la envía al proveedor del servicio. El proveedor del servicio verifica
la firma digital de la solicitud, verifica contra la Autoridad Central
la validez de la firma y aplica reglas propias de autorización y acceso
a sus datos. En caso de autorizar la transacción entonces devuelve una
respuesta firmada digitalmente. Ambos participantes almacenan la
evidencia de la operación.
V.- Marco Normativo.
El marco normativo que sustenta al módulo INTEROPER.AR está conformado
por la Ley N° 25.506, los Decretos Nros. 434 del 1° de Marzo de 2016,
561 del 6 de Abril de 2016, 1273 del 19 de Diciembre de 2016, 894 del
1° de noviembre de 2017 y la Resolución N° 6 del 10 de Enero de 2017 de
la SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA del MINISTERIO DE
MODERNIZACIÓN (RESOL-2017- 6-APN - SECMA#MM).
En efecto, la Ley N° 25.506 de Firma Digital, reconoció la eficacia
jurídica del documento electrónico, la firma electrónica y la firma
digital, y en su artículo 48 estableció que el Estado Nacional, dentro
de las jurisdicciones y entidades comprendidas en el artículo 8° de la
Ley N° 24.156, promoverá el uso masivo de la firma digital de tal forma
que posibilite el trámite de los expedientes por vías simultáneas,
búsquedas automáticas de la información y seguimiento y control por
parte del interesado, propendiendo a la progresiva despapelización.
Por otra parte, el Decreto N° 434 del 1° de Marzo de 2016 aprobó el
Plan de Modernización del Estado con el objetivo de alcanzar una
Administración Pública al servicio del ciudadano en un marco de
eficiencia, eficacia y calidad en la prestación de servicios,
contemplando como segundo eje el desarrollo, mejora continua e
integración de sistemas de gestión, planteando como objetivo incorporar
nuevos sistemas y aprovechar iniciativas ya desarrolladas e
implementadas que permitan encontrar soluciones transversales de
administración integradas al Sistema de Gestión Documental y Expediente
Electrónico, procurando cambiar el modelo de desarrollo sectorial,
hacia uno homogéneo y cohesionado, para lo cual previó como actividad
definir los estándares tecnológicos para promover la interoperabilidad
de los sistemas y evitar que el ciudadano tenga que aportar información
ya obrante en la Administración.
Adicionalmente, resulta consecuencia de lo dispuesto por el Decreto N°
561 del 6 de Abril de 2016, que aprobó la implementación del sistema de
Gestión Documental Electrónica - GDE, como sistema integrado de
caratulación, numeración, seguimiento y registración de movimientos de
todas las actuaciones y expedientes del Sector Público Nacional,
facultando en su artículo 6° a la SECRETARIA DE MODERNIZACIÓN
ADMINISTRATIVA del MINISTERIO DE MODERNIZACIÓN a dictar las normas
complementarias, aclaratorias y operativas necesarias para la
implementación de dicho sistema y el funcionamiento de los sistemas
informáticos de gestión documental.
Pero fundamentalmente, el módulo INTEROPER.AR es consecuencia de lo
establecido en el Decreto N° 1273 del 19 de Diciembre de 2016, que
dispuso la obligación de las entidades y jurisdicciones enumeradas en
el artículo 8 de la Ley N° 24.156 que componen el Sector Público
Nacional a intercambiar la información pública que produzcan, obtengan,
obre en su poder o se encuentre bajo su control con cualquier otro
organismo público que así se lo solicite.
El mencionado Decreto N° 1273 del 19 de Diciembre de 2016 facultó a la
SECRETARIA DE MODERNIZACIÓN ADMINISTRATIVA del MINISTERIO DE
MODERNIZACIÓN a dictar los protocolos de intercambio, pautas de
interoperabilidad, normas complementarias, aclaratorias, técnicas y
operativas necesarias para el cumplimiento de lo dispuesto en su
artículo 1°.
En tal sentido, la SECRETARIA DE MODERNIZACIÓN ADMINISTRATIVA emitió la
Resolución N° 6 de fecha 10 de Enero de 2017, en la cual estableció,
por una parte, las "Pautas Técnicas de Interoperabilidad" y además, los
procedimientos de intercambio de información, estableciendo el efecto
positivo del silencio de la administración.
Efectivamente, la mencionada Resolución N° 6/2017 estableció que, en el
marco del Decreto N° 1273 del 19 de Diciembre de 2016, cuando un
organismo requiera información a otro, y el organismo productor de la
información no contestare en un plazo de CINCO (5) días, se le
reconocerá al silencio sentido positivo.
Complementariamente, el Decreto N° 894 del 1° de Noviembre de 2017, que
aprobó el "Reglamento de Procedimientos Administrativos Decreto N°
1759/72 T.O. 2017", estableció que las autoridades administrativas
actuarán de acuerdo con los principios de sencillez y eficacia,
procurando la simplificación de los trámites, y facilitando el acceso
de los ciudadanos a la administración a través de procedimientos
directos y simples por medios electrónicos.
En ese orden de ideas, el Anexo I del citado Decreto N° 894 del 1° de
Noviembre de 2017, que aprobó el "Reglamento de Procedimientos
Administrativos Decreto N° 1759/72 T.O. 2017", dispuso en su artículo
107 la eliminación de cargas al administrado, disponiendo que, en
aquellos casos que para la sustanciación de un procedimiento
administrativo sea necesaria la presentación de alguna información,
dato, documento o certificado que deba ser emitido por otra entidad o
jurisdicción del Sector Público Nacional, la entidad responsable del
procedimiento lo solicitará directamente por comunicación oficial al
organismo responsable de su producción y certificación. La solicitud
del dato, información, documentación o certificado deberá expresar el
motivo, el procedimiento en el cual se enmarca, y la norma que
justifica su presentación.
En síntesis, en esta instancia del proceso de modernización de la
Administración Pública Nacional, resulta oportuno instrumentar una
medida que simplifique los trámites administrativos, eliminando de
cargas al administrado en los casos que un organismo requiera
determinada información, dato, documento o certificado que deba ser
emitido por otra entidad o jurisdicción del Sector Público Nacional.
Ello así, y a los efectos de lograr una modernización efectiva de la
gestión administrativa del Estado, es esencial contar con una
herramienta de interoperabilidad que permita el intercambio directo
entre organismos de documentación y datos que actualmente se le
solicitan al particular, facilitando de manera permanente el acceso,
consulta y transferencia de información pública para lograr la
interconexión y operación simultánea.
Anexo
Número:
IF-2018-09344892-APN-SSGA#MM
CIUDAD DE BUENOS AIRES
Viernes 2 de Marzo de 2018
Referencia: Anexo II - Pautas
Técnicas de Interoperabilidad de Sistemas
RESOLUCIÓN
SECRETARÍA DE MODERNIZACIÓN ADMINISTRATIVA
ANEXO II
"Pautas Técnicas de Interoperabilidad
de Sistemas"
I. - Introducción
Las presentes "Pautas Técnicas de Interoperabilidad de Sistemas" tienen
por objeto brindar un marco de intercambio de información entre las
entidades y jurisdicciones que integran el Sector Público Nacional, en
el marco del Decreto Nro. 1273/2016.
Las interfaces de programación de aplicaciones (APIs) exponen las
funciones internas de un sistema al mundo exterior. Esto permite que
los sistemas compartan información sin requerir que los desarrolladores
tengan que compartir el código de las aplicaciones, ni entender las
complejidades internas de cada sistema.
II. - Alcances
A los fines de facilitar el intercambio de información entre las
entidades y jurisdicciones que componen el Sector Público Nacional, de
acuerdo a lo dispuesto en el Decreto Nro. 1273 del 19 de diciembre de
2016, se establecen las siguientes Pautas de Interoperabilidad. Las
entidades y jurisdicciones detalladas en el artículo 8 de la Ley Nro.
24.156 deberán intercambiar la información desarrollando APIs siguiendo
los siguientes lineamientos.
Estas "Pautas Técnicas de Interoperabilidad de Sistemas" son de
aplicación para todas las entidades y jurisdicciones que integran la
Administración Pública Nacional o Entidades de derecho Público
vinculadas o dependientes de aquélla (en adelante, organizaciones) que
participan en el intercambio de asientos registrales, ya sea para la
prestación de servicios directos a los ciudadanos, como de cara al
intercambio de información con otros órganos.
III. - Arquitectura REST
Las "Pautas Técnicas de Interoperabilidad de Sistemas" se basan en la
arquitectura REST. Dicha arquitectura especifica un conjunto de
principios de arquitectura de Software que definen la interacción entre
distintos componentes dentro de un sistema de hipermedia distribuido.
En particular, se implementará arquitectura REST sobre el protocolo
HTTP.
Los principios generales a los que deberán ajustarse son:
- Arquitectura cliente-servidor: Un cliente realiza peticiones a un
servidor, el cual devuelve respuestas.
- Stateless: Cada petición que se realiza será independiente de la
siguiente.
- Cacheable: Una vez realizada la primera petición, el resto podrán ser
obtenidas del cache en caso de no haber sufrido cambios.
- Sistema por capas: Para toda petición originada de un cliente al
servicio no será distinguible si está siendo dirigida directo al
servidor o a un sistema de chache o balanceador.
- Identificación del recurso: Se deberá indicar a través de una URI, la
misma debe cumplir con el RFC 3986.
- Operaciones uniformes: Los métodos serán los especificados en HTTP
(GET, PUT, POST, DELETE) provistos en el RFC 2616.
- Formato o representación del recurso: El tipo de contenido deberá ser
del tipo JSON, el mismo se encuentra definido en el RFC 7159
https://tools.ietf.org/html/rfc7159
IV.- Pautas en el diseño
- Se debe crear una URI para cada recurso. Estos deben ser sustantivos,
no verbos.
No se debe utilizar:
http://www.ejemplo.com.ar/entidades/obtenerentidad?id=001
Se debe utilizar: http://www.ejemplo.com.ar/entidades/001
Use los verbos HTTP (GET, POST, PUT, DELETE) para funcionar en las
colecciones y elementos.
Ponga el número de versión en la URL, por ejemplo:
http://ejemplo.gob.ar/vL0/path/to/resource
Especificar campos opcionales como una lista separada por coma.
Para indicar el formato de respuesta utilizar el campo content-type del
header siendo por defecto el formato JSON. Por ejemplo: XML:
Content-Type: application/xml JSON: Content-Type: application/json;
charset=utf-8
El formato DEBE ser del tipo: api/v2.0/resource/{id}
Utilizar sub recursos para indicar relaciones.
Si un recurso está relacionado a otro, se deberá representar como un
sub recurso del mismo. Ejemplo: /organismos/{id del
organismo}/empleados/{id_empleado}
No obstante es válido y muchas veces necesario que exista /empleados
como top-level uri dentro de la API.
En el caso de que una representación incluya una lista de objetos
relacionados debe incluir links a las URI de cada objeto.
De otra forma sólo se puede navegar el árbol de relación teniendo
información externa a los resultados que indique dónde ir a buscar cada
recurso.
Una URi que apunta a un sub-recurso (ej,
/organismos/{id_organismo}/empleados/ 123 puede devolver la
representación del sub-recurso o simplemente utilizar un redirect http
para indicar el top-level que lo devuelve (ej HTTP 307 moved
temporarily)
- Categorizar los recursos de acuerdo a las acciones que los clientes
pueden realizar sobre los mismos, por ejemplo una representación del
recurso o modificación.
Para las representaciones, se deben utilizar el verbo HTTP GET.
Para las modificaciones, se deben utilizar los verbos HTTP POST, PUT
y/o DELETE.
- Los request GET no deben tener efectos sobre el recurso al que
apuntan. Sólo deben devolver su representación. Por lo tanto, invocar
al recurso no debería tener como resultado modificarlo.
- Manejo de errores y respuestas usando códigos HTTP estándar
Usar los códigos de estado HTTP para indicar el resultado de las
invocaciones a la API. Los más importantes son los siguientes:
- 200 ,201,204
- 304, 307
- 400,401,403,404,422
- 500
Las respuestas de errores DEBEN incluir los códigos de estados HTTP,
mensaje para el desarrollador, mensaje para el usuario final, código de
error interno, enlaces con documentación al respecto. Por ejemplo:
{
"status" : 400,
"developerMessage" : "Descripción clara del problema. Sugerencias de
cómo resolver el problema.", "userMessage" : "Este es el mensaje para
el usuario final.", "errorCode" : "[444444|exceptionName]",
"moreInfo" :
"http://www.ejemplo.gob.ar/developer/path/to/help/for/444444,
http://drupal.org/node/444444",
}
- Mantener en minúsculas la URI.
- Usar UTF-8 y aceptar caracteres "especiales" como comillas, tildes,
símbolos.
- Esconder las extensiones de las tecnologías utilizadas (.php, .asp,
.jsp, etc).
- Se deberá utilizar como encoding UTF8, y deberá ser informado en la
cabecera (Conten-tType: application/json; charset=utf-8)
- Se deberán utilizar fechas según ISO 8601 en UTC Para solo fechas, el
formato debe ser 2016-01-27.
Para fechas completas, el formato debe ser 2016-01-27T10:00:00Z.
- Una API que retorna JSON DEBE usar el content type adecuado al tipo
de datos y encoding que devuelve.
El recomendado es:
Content-Type: application/json; charset=utf-8
Ejemplos válidos de URLs Lista de artículos:
GET http://www.ejemplo.gob/api/vL0/articulos
Filtrando con query string:
GET http://www.ejemplo.gob/api/v1.0/articulos?year=2016&sort=desc
Un artículo en formato JSON:
GET http://www.ejemplo.gob/api/vL0/articulos/1234
Todos los comentarios de un artículo en particular:
GET http://www.ejemplo.gob/api/vL0/articulos/1234/comentarios
Especificar campos opcionales en una lista separada por coma:
GET http://www.ejemplo.gob/api/v1.0/articulos/1234?fields=title,body
Agregar un comentario a un artículo específico:
POST http://ejemplo.gob/api/vL0/articulos/1234/comentarios
Ejemplos NO válidos de URLs:
Sustantivos singulares: http://www.ejemplo.gob/api/vL1/articulo
http://www.ejemplo.gob/api/vL1/articulo/1234
Verbo en la URL: http://www.ejemplo.gob/api/vL1/articulo/1234/create
Filtro fuera del query string
http://www.ejemplo.gob/api/vL1/articulos/2016/desc
V.- Verbos HTTP
Los verbos HTTP, o métodos, se deben utilizar en el cumplimiento de sus
definiciones de la norma HTTP/1.1 .
Este es un ejemplo de cómo deben ser los verbos HTTP para crear, leer,
actualizar y eliminar las operaciones en un contexto particular:
VI.- Soporte JSON
- Las respuestas DEBEN ser objetos JSON (no arrays). Usar un array para
retornar resultados limita la capacidad de incluir metadata sobre
resultados, y limita la capacidad de las API's para agregar top-level
keys en el futuro.
- Se puede incluir un parámetro especial para devolver los datos en
otros formatos como XML, CSV u otro.
GET http://www.ejemplo.gob/api/v1.0/articulos?format=csv
GET http://www.ejemplo.gob/api/vL0/articulos.csv
- No usar claves impredecibles. Realizar el parsing de una respuesta
JSON donde las claves son impredecibles es difícil.
- Usa guión_bajo para las claves. Diferentes lenguajes usan diferentes
convenciones. JSON usa guión_bajo, no camelCase.
Más info en json.org
VII.- Documentación
Para documentar los Servicios WEB REST se debe incluir una introducción
funcional que describa qué hace la API, y para cada servicio lo
siguiente:
Nombre
URI
Ejemplo de uso incluyendo invocación con curl y la respuesta del
ejemplo.
Descripción de los parámetros obligatorios y opcionales
Valores por default Códigos de error.
Ejemplo de documentación
Listar Reparticiones Obtiene la lista de reparticiones
Uso: curl "http://ejemplo.gob.ar/api/v1/reparticiones" -H
"Authorization: tokendeautenticacion"
El comando anterior devuelve una respuesta JSON como :
{
items: [
{
"id": 1,
"name": "reparticionl",
"propiedad": "valor"
},
{
"id": 2,
"name": "reparticion2",
"propiedad": "valor"
},
]
}
Este endpoint devuelve las reparticiones según los parámetros de filtro
HTTP Request
GET http://example.com/api/kittens
Parámetros del request: Parametro Default Descripción
incluir_externos false Si está en true, la respuesta incluye
reparticiones externas.
activas true Si está en false, la respuesta incuirá reparticiones que
no están activan en el sistema
Nota — Este servicio no requiere autenticación.
También se admitirá utilizar herramientas de documentación como:
SWAGGER MkDocs Aglio
Documentar los ejemplos de la forma mas genérica posible, contemplando
mas de un lenguaje de ser posible (por ejemplo Python y Java)
VIII. - Seguridad
Con el objetivo de ofrecer escalabilidad, y generar servicios WEB
stateless (sin estado) y aptos para aplicaciones móviles, se deberá
implementar seguridad a través de los siguientes lineamientos:
Autenticación Basada en Tokens
Se implementará a partir de JSON WEB TOKEN (JWT) explicado en el RFC
7519 utilizando para asegurarlo los estándares JWS y JWE (RFC 7515 y
7516) utilizándo como mínimo el algoritmo HMAC
Protocolo de comunicación segura
La implementación de los servicios WEB RESTFul deberá ser implementada
en https para ofrecer encriptación.
IX. - Versiones
Nunca libere la versión de una API sin su número de versión.
Los números de versión deben abarcar dos niveles de versión: x.x
Las versiones DEBEN ser enteros, no decimales, con el prefijo 'v'.
Dar soporte al menos una versión anterior a la actual.
Ejemplos: Válido: v1.0, v2.1, v3.5 No válido: v-1.1, v1.2.5, 1.3.3
X.- Casos particulares
Para algunos tipos de intercambio de información deben tenerse especial
cuidado en la arquitectura de las APIs para que sean efectivas. Algunos
casos particulares que pueden requerir complementar REST con otros
protocolos son:
a) Transferencias Masivas. Cuando el cliente requiera tener una copia
propia de un set de datos muy grande por motivos válidos (implementar
un motor de búsqueda, hacer procesos de inteligencia de negocio, etc).
Si la API no puede transmitir la información de forma eficiente o
escalable (para el cliente como para el servidor) puede ser necesario
implementar otros métodos.
b) Notificaciones inmediatas. Las APIs REST funcionan a pedido del
cliente. En el caso de que el cliente deba tener las últimas
modificaciones o novedades de forma inmediata se pueden implementar
métodos tipo callback (si el servidor lo permite) o tecnologías de
streaming de datos, publisher subscriber, etc. De ser posible deben
mantenerse sobre HTTP (utilizando websockets, Server Sent Events,etc)
c) Transacciones costosas. Las transacciones que disparan operaciones
muy costosas deben implementarse de forma asincrona, evitando bloquear
a los sistemas que las ejecutan.
