0.9.0 - ci-build
VigiCanPY - Local Development build (v0.9.0). See the Directory of published versions
VigiCanPY implementa seguridad basada en oAuth2 con tokens, por lo cual la primera llamada de las aplicaciones autorizadas debe realizarse a la url que provee el token ([auth]).
Previo al uso del servicio de autenticación, la aplicación que realiza el pedido debe solicitar a los administradores del sistema.
Registrar una URI fija para la aplicación en el federador (debe ser la del dominio) En el caso de utilizar firma digital: Registrar una clave pública RSA (SHA-256) Una vez registrada la aplicación, se establece una relación de confianza entre la aplicación y el federador, esto es, la aplicación se considera ‘pre-autorizada’ para acceder a los pacientes asociados.
El administrador asignará al sistema un identificador denominado client_id
En tiempo de ejecución, el servicio debe obtener un token de acceso para poder acceder a la información. Estos tokens de acceso pueden ser generados automáticamente, sin necesidad de intervención humana, con una expiración recomendada de 15 minutos.
[SecretWord] Palabra clave otorgada por la DNSIS a cada dominio [urlAuth] URL de Autorización
La aplicación cliente debe generar un token JWT firmado con la palabra clave otorgada por la DNSIS con la siguiente información
Ejemplo de Código JS
function CreateJWTToken()
{
var jwt = require('jsonwebtoken');
c = authc.authConfig();
var myTokenContent=
{
iss: c.iss,
iat: Date.now(),
exp: Date.now() + 6000000 ,
aud: c.aud,
sub: c.sub,
name: c.name,
ident: c.ident,
role: c.role
}
var token = jwt.sign(myTokenContent, c.secretWord);
return token;
}
La aplicación cliente debe realizar un POST a [urlAuth] del JSON del AuthorizationRequest
AuthorizationRequest
elemento
|
contenido
|
ejemplo
|
grantType
|
clientCredentials
|
valor fijo
|
scope
|
VER Tabla de Scopes
|
Patient/*read,Patient/*.write
|
clientAssertionType
|
urn:ietf:params:oauth:client-assertion-type:jwt-bearer
|
valor fijo
|
clientAssertion
|
[token jwt creado en el paso 1]
|
Operación
|
Scopes
|
Consultas/Federacion Pacientes
|
Patient/*.read,Patient/*.write
|
Registro en Nomivac
|
Immunization/*.write
|
Consulta de Resumen de Historia Clínica IPS
|
Patient/*.read,DocumentReference/*.read,Bundle/*.read
|
Consulta REFES
|
Organization/*.read
|
Consulta REFEPS
|
Practitioner/*.read,PractitionerRole/*.read
|
tokenInicial=CreateJWTToken();
var authRequest={
"grantType": "client_credentials",
"scope": "Patient/*.read,Patient/*.write",
"clientAssertionType": "urn:ietf:params:oauth:client-assertion-type:jwt-bearer",
"clientAssertion": tokenInicial
};
La respuesta será un objeto JSON con las siguientes propiedades AuthorizationResponse
elemento
|
descripción
|
detalles
|
scope
|
Nivel de Acceso Otorgado
|
Ver tabla scopes
|
access_token
|
Token Otorgado por el Servidor
|
Este es el token que debe incluir en todas las solicitudes al bus
|
expires_in
|
Cantidad de segundos de expiración del token
|
Se sugiere 900 (quince minutos)
|
token_type
|
Tipo de Token
|
Valor fijo: bearer
|
Ejemplo de Respuesta JSON
{ "access_token": "m7rt6i7s9nuxkjvi8vsx", "token_type": "bearer", "expires_in": 900, "scope": "patient/write,patient/read" }
### Inclusión del Token en el Encabezado de las Solicitudes HTTPS
En todas las invocaciones al bus de interoperabilidad debe incluirse el token obtenido como encabezado (header) de la solicitud HTTPS.
Nombre: Authorization Valor: Bearer: [access_token]
El token será validado por el bus de interoperabilidad (verificando si la aplicación puede o no acceder/modificar la información requerida del paciente)