Auth

Auth es un core módulo que se requiere para acceder ipf services Actualmente, hay 3 tipos de autenticación que son compatibles: Autenticación Básica, OAuth 2. 0 y SAML.

Los métodos de autenticación se pueden habilitar con los siguientes comandos:

ipf.business-operations.auth.basic-auth.enabled = true

ipf.business-operations.auth.saml2.enabled = true

ipf.business-operations.auth.oauth2.enabled = true

Configuración

Para cada tipo de autenticación, usted necesitará proporcionar un archivo de configuración. También es necesario cambiar el valor predeterminado del max-age del encabezado Strict Transport Security para HTTP solicitudes.

Autenticación Básica

La autenticación básica no debe ser utilizada en producción y está desactivada por defecto. Está destinada únicamente para fines de desarrollo y pruebas.

Para entornos de producción, los clientes deben utilizar autenticación SSO a través de Saml 2 u OAuth 2, que proporcionan una mayor seguridad y soporte para MFA.

Para la autenticación básica, deberá proporcionar una configuración similar a la del ejemplo a continuación, especificando los usuarios y el mapping entre las entidades de procesamiento y los roles de ipf.

users = [
  {
    username: "admin"
    password: "p4ssw0rd"
    roles: {
      BANK_ENTITY_1 = [ROLE_HTM_VIEWER, ROLE_HTM_EXECUTE, ROLE_HTM_APPROVER, ROLE_HTM_B_C, ROLE_HTM_B_R, ROLE_AUDIT, ROLE_METRICS, ROLE_PAYMENT, ROLE_PAYMENT_EXPORT, ROLE_DPS_P_R, ROLE_DPS_AS_R, ROLE_DPS_AS_C, ROLE_DPS_AS_A, ROLE_DPS_AS_U, ROLE_DPS_AS_D, ROLE_DPS_GP_R, ROLE_DPS_GP_C, ROLE_DPS_GP_A, ROLE_DPS_GP_U, ROLE_DPS_GP_D, ROLE_DPS_PE_R, ROLE_DPS_PE_C, ROLE_DPS_PE_A, ROLE_DPS_PE_D, ROLE_DPS_PE_U, ROLE_DPS_BF_R, ROLE_DPS_BF_C, ROLE_DPS_BF_A, ROLE_DPS_BF_D, ROLE_DPS_BF_U, ROLE_DPS_SO_R, ROLE_DPS_SO_C, ROLE_DPS_SO_U, ROLE_DPS_SO_A, ROLE_DPS_SO_D]
      BANK_ENTITY_2 = [ROLE_AUDIT, ROLE_METRICS, ROLE_PAYMENT, ROLE_DPS_P_R, ROLE_DPS_AS_R, ROLE_DPS_GP_R, ROLE_DPS_PE_R, ROLE_DPS_BF_R, ROLE_DPS_SO_R]
    }
  }, {
    username: "guest"
    password: "guest"
    roles: {
      BANK_ENTITY_1 = [ROLE_GUEST, ROLE_PAYMENT]
    }
  }
]
users = ${? env.users}

OAuth 2

Si está utilizando OAuth 2, deberá proporcionar una configuración similar al ejemplo a continuación.

oauth2 {
    enabled = false
    registration-id = "example-app-id"
    client-id = "login-app-client-id"
    client-secret = "secret"
    scopes = "openid, roles"
    authorization-uri = "http://example-url/auth"
    token-uri = "http://example-url/token"
    jwk-set-uri = "http://example-url/certs"
    userinfo-uri = "http://example-url/userinfo"
    return-url = "/"
    roles-attribute = "roles"
    roles-separator = ","
    roles-from-attributes = true
    username = "preferred_username"
    ipf-roles = false
    roles-mapping {
      BANK_ENTITY_1 {
        TECHNICAL_BANK_OPERATOR = [ROLE_PAYMENT, ROLE_PAYMENT_EXPORT, ROLE_DPS_P_R, ROLE_DPS_AS_R, ROLE_DPS_AS_C, ROLE_DPS_AS_A, ROLE_DPS_AS_U, ROLE_DPS_AS_D, ROLE_DPS_GP_R, ROLE_DPS_GP_C, ROLE_DPS_GP_A, ROLE_DPS_GP_U, ROLE_DPS_GP_D, ROLE_DPS_PE_R, ROLE_DPS_PE_C, ROLE_DPS_PE_A, ROLE_DPS_PE_D, ROLE_DPS_PE_U, ROLE_DPS_BF_R, ROLE_DPS_BF_C, ROLE_DPS_BF_A, ROLE_DPS_BF_D, ROLE_DPS_BF_U, ROLE_DPS_SO_R, ROLE_DPS_SO_C, ROLE_DPS_SO_U, ROLE_DPS_SO_A, ROLE_DPS_SO_D]
        BANK_ASSISTANT = [ROLE_METRICS, ROLE_PAYMENT_EXPORT, ROLE_PAYMENT, ROLE_DPS_P_R, ROLE_DPS_AS_R, ROLE_DPS_GP_R, ROLE_DPS_PE_R, ROLE_DPS_BF_R, ROLE_DPS_SO_R]
      },
      BANK_ENTITY_2 {
        CSM_BANK_OPERATOR = [ROLE_DPS_P_R, ROLE_DPS_AS_R, ROLE_DPS_AS_C, ROLE_DPS_AS_A, ROLE_DPS_AS_U, ROLE_DPS_AS_D, ROLE_DPS_GP_R, ROLE_DPS_GP_C, ROLE_DPS_GP_A, ROLE_DPS_GP_U, ROLE_DPS_GP_D, ROLE_DPS_PE_R, ROLE_DPS_PE_C, ROLE_DPS_PE_A, ROLE_DPS_PE_D, ROLE_DPS_PE_U, ROLE_DPS_BF_R, ROLE_DPS_BF_C, ROLE_DPS_BF_A, ROLE_DPS_BF_D, ROLE_DPS_BF_U, ROLE_DPS_SO_R, ROLE_DPS_SO_C, ROLE_DPS_SO_U, ROLE_DPS_SO_A, ROLE_DPS_SO_D]
        PAYMENTS_BANK_OPERATOR = [ROLE_PAYMENT, ROLE_PAYMENT_EXPORT]
        BANK_SUPPORT_OPERATOR = [ROLE_AUDIT, ROLE_METRICS, ROLE_DPS_P_R, ROLE_DPS_AS_R, ROLE_DPS_GP_R, ROLE_DPS_PE_R, ROLE_DPS_BF_R, ROLE_DPS_SO_R]
      }
    }
  }

Las propiedades más importantes son roles-atributos, ipf-roles y roles-mapping.

roles-attribute se refiere al reclamo de token que contiene los roles del usuario. Un nombre de atributo que contiene una lista delimitada de roles. Opcional si el atributo a roles-mappings ya están especificados.

ipf-roles es un flag que puede tomar 2 propiedades: verdadero o falso. Si se establece en verdadero, señalará el hecho de que el usuario tiene roles de IPF (auditoría, métricas, etc.) directamente en el token y no roles bancarios. Si se establece en falso, señalará el hecho de que el cliente tiene roles bancarios en el token (roles desconocidos para el IPF que están presentes en los roles-mapping). Esta propiedad nos ayuda a analizar los roles mapping y asigne los roles correctos al usuario.

roles-mapping representa el mapping entre entidades de procesamiento, roles bancarios y roles de IPF. Cada entidad de procesamiento puede contener múltiples roles bancarios y cada rol bancario puede contener múltiples roles de IPF. Al otorgar acceso, estamos analizando el mapping proporcionada por los clientes y asigne los roles correctos al usuario en función de esto mapping. Si los clientes utilizan roles IPF en el token, se debe proporcionar la clave del rol bancario, pero será completamente ignorada (puede ser un texto aleatorio). Esta estructura debe ser seguida en ambos casos.

Una lista completa de las propiedades de configuración de OAuth se puede encontrar aquí:Configuración del Servicio GUI de OPS Propiedades de OAuth 2

SAML 2

Si está utilizando SAML 2, deberá proporcionar una configuración similar al ejemplo a continuación.

  saml2 {
    enabled = false
    verification-certificate = "classpath:idp.crt"
    registration-id = "example-app-id"
    single-sign-on-service-location = "http://example-url/SingleSignOnService.php"
    single-log-out-service-location = "http://example-url/SingleLogoutService.php"
    identity-provider-entity-id = "http://example-url/metadata.php"
    service-provider-entity-id = "http://example-url/service-provider-metadata/"${ipf.business-operations.auth.saml2.registration-id}
    assertion-consumer-service-location = "<override for redirect URL>" //In the case of Gateway rewrite breaking the default for spring which is "{baseUrl}/login/saml2/sso/{registrationId}"
    want-authn-requests-signed = false
    uid-attribute = "uid"
    roles-attribute = "roles"
    roles-separator = ","
    return-url = "/"
    ipf-roles = true
  }

Las propiedades más importantes son roles-atributos, ipf-roles y roles-mapping.

roles-attribute se refiere al reclamo de token que contiene los roles del usuario. Un nombre de atributo que contiene una lista delimitada de roles.

ipf-roles es un flag que puede tomar 2 propiedades: verdadero o falso. Si se establece en verdadero, señalará el hecho de que el usuario tiene roles IPF (auditoría, métricas, etc.) directamente en el token y no roles bancarios. Si se establece en falso, señalará el hecho de que el cliente tiene roles bancarios en el token (roles desconocidos para el IPF que están presentes en los roles-mapping). Esta propiedad nos ayuda a analizar los roles mapping y asigne los roles correctos al usuario.

roles-mapping representa el mapping entre entidades de procesamiento, roles bancarios y roles de IPF. Cada entidad de procesamiento puede contener múltiples roles bancarios y cada rol bancario puede contener múltiples roles de IPF. Al otorgar acceso, estamos analizando el mapping proporcionada por los clientes y asigne los roles correctos al usuario en función de esto mapping. Si los clientes utilizan roles IPF en el token, se debe proporcionar la clave del rol bancario, pero será completamente ignorada (puede ser un texto aleatorio). Esta estructura debe ser seguida en ambos casos.

Una lista completa de las propiedades de configuración SAML se puede encontrar aquí:Configuración del Servicio GUI de OPS Propiedades SAML2

HTTP

El encabezado de Seguridad de Transporte Estricto está configurado para aplicarse a todas las solicitudes y subdominios, asegurando que todo el tráfico se sirva de manera segura a través de HTTPS.

El preload La directiva está habilitada, permitiendo que el dominio sea añadido a la lista de precarga HSTS para una mayor seguridad. (Nota: Este atributo no tiene efecto a menos que el dominio sea añadido con éxito a la lista de precarga.)

El max-age el atributo del encabezado puede ser configurado a través de la hsts-max-age ajuste:

  • ipf.business-operations.auth.http.hsts-max-age

El hsts-max-age El valor debe ser incrementado

  • Por defecto, max-age está configurado en 300 segundos (5 minutos). El mínimo recomendado es 31536000 segundos (1 año), pero se aconseja aumentar este valor de manera incremental durante el despliegue.

  • Un valor predeterminado más bajo proporciona un período de gracia para las pruebas. Una vez que un navegador aplica HSTS para un dominio, recuerda la política hasta que expire el max-age. Aumentar el max-age es sencillo, pero reducirlo puede ser un desafío debido a la aplicación por parte del navegador.

  • La mejor práctica es comenzar con un valor bajo, probar exhaustivamente y aumentar gradualmente hasta un valor seguro a largo plazo. Puede encontrar más información aquí:https://hstspreload.org/

JSON Fecha de expiración del token web

La duración durante la cual un token es válido puede ser configurada a través de la configuración del jwt.expiry propiedad, a partir del momento de la creación del token. La configuración predeterminada para esta propiedad es de 1 hora.

La fecha de caducidad puede ser proporcionada en las siguientes unidades de tiempo:

  • Milisegundos (ms). Por ejemplo, 60ms

  • Segundos (s). Por ejemplo, 60s

  • Minutos (m). Por ejemplo, 60m

  • Horas (h). Por ejemplo, 60h

  • Días (d). Por ejemplo, 7d Hay un límite inferior y superior establecido para la duración de la caducidad, que si no se respeta, la aplicación no podrá iniciarse. La duración mínima que un token debe ser válido es de 1 minuto. La duración máxima que un token puede ser válido es de 7 días.

jwt.expiry = 1h
La propiedad mencionada también se utiliza para establecer la propiedad maxAge de la cookie.

JSON Algoritmo de Firma de Token Web

El tipo de algoritmo de firma utilizado para firmar y verificar tokens JWT es configurable. Los algoritmos soportados son:

  • HS512- Algoritmo Simétrico.

  • ES512- Algoritmo asimétrico.

El algoritmo de firma puede ser configurado a través de la jwt.signature-algorithm propiedad de configuración.

El valor predeterminado es jwt.signature-algorithm = 'HS512'.

Cualquiera que sea el algoritmo que decida utilizar, la configuración precisa es vital.

  • Para que la firma HS512 predeterminada funcione,jwt.secret debe ser sobrescrito.

  • Para que la firma ES512 funcione,jwt.path-private-key y jwt.path-public-key Las propiedades de configuración deben definirse apuntando a las rutas de los archivos de clave en formato pem respectivamente.

  • Ejemplo de configuración de ES512

jwt.signatureAlgorithm = "ES512",

jwt.path-private-key = "classpath:keys/private-key.pem",

jwt.path-public-key = "classpath:keys/public-key.pem",