seguridad de API

Puede proteger las API con dos niveles diferentes que le ayudan a controlar quién puede llamar a las API y qué autorización debe tener esa persona.

Al llamar a una API, debe pasar por los dos niveles de seguridad siguientes:

  1. Autenticación con un ID de usuario, un certificado o ambos. La API de inicio de sesión se llama antes de que se llame a cualquier otra API.
  2. Autorización, que verifica la API a la que puede acceder.

Este procedimiento de seguridad es para cada llamada de API que se realiza a través de un proceso de servidor de aplicaciones. De forma predeterminada, los servidores de agente y de integración, tienen siempre acceso completo a las API.

Una vez que ha pasado la comprobación de autenticación, una comprobación de autorización determina a qué API y recursos se puede acceder. Esta comprobación de autorización es además de la seguridad de la interfaz de usuario (UI). Por ejemplo, la seguridad de la interfaz de usuario puede ayudarle a acceder a una pantalla que lista los usuarios. Para generar una lista de usuarios en la pantalla, es posible que también tenga que pasar una comprobación de autorización para la API de getUserList que lista los usuarios.

Otros ejemplos de comprobaciones de autorización incluyen:
  • Si utiliza la API de getCommonCodeList con fines de visualización, no debería poder obtener información de usuario que esté explícitamente restringida de la salida de la API.
  • Si llama a la API de getUserList antes de asignar una alerta, no debería poder obtener contraseñas de usuario.
  • Si utiliza la API de UserHierarchy para cambiar la contraseña:
    • Usted no debe ser capaz de cambiar su propia bandera IsSuperUser.
    • No debe poder modificar la información de otro usuario.
    • No debe poder suscribirse a más grupos de usuarios, lo que le daría más acceso al sistema.

Esta seguridad se implementa utilizando los archivos de plantilla apisecimpureza. Estos archivos de plantilla apisecurity son archivos XML que documentan los elementos de entrada y salida a los que todas las API (de forma predeterminada) están limitadas. Estos archivos se generan automáticamente durante el despliegue de XAPI, aunque la generación de documentos está desactivada.

Nota: Los servicios no utilizan el archivo apisecimpureza.

Las plantillas se utilizan para las comprobaciones de autorización de entrada y salida. Estas plantillas sustituyen las plantillas normales.

Por ejemplo, una plantilla de entrada con las líneas OrganizationCode=#PROHIBITED# y IsSuperUser=#PROHIBITED# impedirá que se suscriba a más grupos de usuarios y obtenga más permisos.

La plantilla de salida complementa el filtrado que realiza la plantilla predeterminada basada en la documentación. Si un elemento está limitado porque no está configurado en el archivo apisecurity, nunca se devolverá en la salida, aunque esté presente en la plantilla basada en la documentación.

Nota: En determinados puntos de la entrada y salida, las API como multiApi y getPage tienen acceso de autorización para cualquier elemento. Pero otras API que se llaman mediante estas API deben pasar por la comprobación de autorización.

El acceso a la seguridad de la API y al nivel de permisos están controlado en las propiedades siguientes del archivo yfs.properties. Todas las anomalías de autorización se registran en una categoría de registro denominada sci.apisecurity.

  • api.security.enabled
    • Y (valor predeterminado)—Habilitar seguridad de API
    • N—No habilitar seguridad de API
  • api.security.mode
    • STRICT—Si falla cualquier validación, se genera una excepción. Esto es adecuado para sistemas de producción, si todos los permisos están configurados correctamente.
    • LAX—Filtrar y registrar una entrada no válida, pero continuar con el proceso. El filtrado permite al sistema hacer la mayor parte del trabajo pese a la entrada o salida incorrecta, mientras que el registro ayuda a identificar los puntos que requieren un cambio.
      Nota: El sistema puede seguir lanzando una excepción cuando el filtrado produce un comportamiento ambiguo.
    • DEBUG—Registrar entrada y salida no válidas, pero no filtrar nada o generar excepciones. Esto sólo es adecuado durante el desarrollo inicial para identificar los permisos necesarios para varios procesos.

Si no especifica una modalidad de seguridad, no hay filtrado, excepciones generadas o comprobación de autorización. Hay un registro limitado.

  • api.security.override .apiName.mode

    Utilice este valor para sustituir los permisos sobre las API individuales. Esta propiedad utiliza los mismos valores que api.security.mode.

  • api.security.smc.enabled
    • Y-Habilitar la seguridad de API para el Gestor de aplicaciones
    • N (valor predeterminado) -No habilitar la seguridad de API para el Gestor de aplicaciones
  • api.security.console.enabled
    • Y—Habilitar la seguridad de la API para la consola de aplicación
    • N (valor predeterminado)—No habilitar la seguridad de la API para la Consola de aplicación

Al realizar la actualización, debe inhabilitar inicialmente esta función y otorgar todo el acceso a través de propiedades. En un sistema actualizado, puede integrar esta función habilitando la seguridad de una API cada vez, mientras define y prueba los permisos. Si está habilitada, sólo el grupo de usuarios del sistema ha concedido permiso a las API; para todos los demás grupos de usuarios personalizados, debe otorgarse el permiso adecuado. Para obtener información sobre los permisos de grupo de usuarios, consulte Acerca del modelado de la organización.