Seguridad

La información siguiente proporciona una visión general de la seguridad en WebSphere Application Server.

IBM® WebSphere Application Server proporciona una infraestructura y mecanismos de seguridad para proteger los recursos J2EE (Java™ 2 Platform, Enterprise Edition) sensibles y los recursos administrativos. También analiza los requisitos de seguridad de extremo a extremo sobre:
  • Autenticación
  • Control de acceso a recursos
  • Integridad de los datos
  • Confidencialidad
  • Privacidad
  • Interoperatividad segura
La seguridad de IBM WebSphere Application Server está basada en estándares del sector y tiene una arquitectura abierta que garantiza una conectividad e interoperatividad seguras con Enterprise Information Systems, que incluye:
  • Database 2 (DB2)
  • CICS
  • [AIX Solaris HP-UX Linux Windows][z/OS]Information Management System (IMS)
  • MQ Series
  • Lotus Domino
  • IBM Directory
WebSphere Application Server también da soporte a otros proveedores de seguridad:
  • [z/OS]Un servidor de seguridad compatible con SAF (System Authorization Facility), incluido RACF (Resource Access Control Facility) de IBM z/OS Security Server.
  • Un servidor proxy inverso seguro, incluido WebSEAL

[z/OS]Gestión de identificación:

[z/OS]Para WebSphere Application Server Versión 7.x y releases anteriores:

[z/OS]Para sacar partido de las características de seguridad de SAF, los usuarios deben identificarse con un ID de usuario basado en z/OS. Puede utilizar módulos de correlación de principales para correlacionar una identidad de J2EE con el ID de usuario basado en plataforma (en este caso un ID de usuario de RACF). Se debe crear una correlación de principales del ID de usuario LDAP con el ID de usuario RACF, para que se puedan realizar las comprobaciones de EJBROLE de SAF. Para ello, debe existir un módulo de inicio de sesión de correlación que permita derivar un ID de usuario z/OS del usuario configurado en el registro LDAP. (Se puede utilizar la auditoría SMF (mediante SAF) para hacer un seguimiento de estos cambios).

[z/OS]Novedades para WebSphere Application Server Versión 8.0 y posterior:

[z/OS]Ahora tiene dos opciones para la correlación de identidades distribuidas:
  • Utilice el módulo de correlación JAAS para correlacionar la identidad J2EE con una identidad SAF.
  • Utilice la característica de correlación de identidad distribuida en SAF, que requiere una determinada versión de SAF. No se debe configurar ningún módulo de correlación JAAS en WebSphere. En este caso, los usuarios se identifican utilizando su identidad de usuario distribuido; por ejemplo, la identidad de usuario en el registro LDAP. La correlación se maneja mediante el administrador de seguridad de z/OS por medio de los perfiles de SAF RACMAP. Esta opción mejora la auditoría SMF al permitir que la identidad de usuarios distribuidos y la identidad SAF se registren en el registro de auditoría. Para obtener más información, consulte Correlación de identidad distribuida utilizando SAF.

Basado en estándares del sector

IBM WebSphere Application Server proporciona un modelo unificado, basado en permisos y políticas para proteger los recursos web, los puntos finales de servicio web y los Enterprise JavaBeans según las especificaciones J2EE. Específicamente, WebSphere Application Server es compatible con la especificación Java EE 6 y ha aprobado J2EE Compatibility Test Suite.

La seguridad de WebSphere Application Server es una arquitectura en capas construida sobre una plataforma de sistema operativo, una JVM (Java Virtual Machine) y la seguridad de Java 2. Este modelo de seguridad utiliza un conjunto amplio de tecnologías de seguridad, que incluye:
  • Modelo de seguridad de Java 2, que ofrece un control de acceso de gran precisión, basado en permisos y políticas a los recursos del sistema.
  • Protocolo de seguridad CSIv2 (Common Secure Interoperability Versión 2), además del protocolo de seguridad SAS (Secure Authentication Services). Ambos protocolos están soportados en releases anteriores de WebSphere Application Server. CSIv2 forma parte integral de la especificación J2EE 1.4 y es fundamental para la interoperatividad entre los servidores de aplicaciones de proveedores diferentes y con los servicios CORBA de empresa.
    [AIX Solaris HP-UX Linux Windows][IBM i][z/OS]Importante: z/SAS sólo está soportado entre servidores de la versión 6.0.x y anteriores que se hayan federado en una célula de la Versión 6.1.
  • Modelo de programación JAAS (Java Authentication and Authorization Service) para las aplicaciones Java, servlets y enterprise beans.
  • Arquitectura de conector J2EE para conectar adaptadores de recursos que den soporte al acceso a Enterprise Information Systems.

Los modelos e interfaces de seguridad estándar que admiten la comunicación de sockets seguros, el cifrado de mensajes y el cifrado de datos son JSSE (Java Secure Socket Extension) y JCE (Java Cryptographic Extension).

Paradigma de la arquitectura abierta

Un servidor de aplicaciones forma parte integral de la infraestructura de sistemas de empresa de varios niveles. IBM WebSphere Application Server adopta el paradigma de la arquitectura abierta, y proporciona varios puntos de plug-in para integrarse con los componentes de software de empresa para proporcionar seguridad de principio a fin. Los puntos de plug-in se basan en las especificaciones J2EE estándar, siempre que sea aplicable.

Paradigma de arquitectura abierto

El fondo sombreado de color azul oscuro indica el límite entre WebSphere Application ServerVersión 9.0 y otros componentes de aplicación de empresa.

[AIX Solaris HP-UX Linux Windows][IBM i]WebSphere Application Server proporciona los mecanismos SWAM (Simple WebSphere Authentication Mechanism), LTPA (Lightweight Third Party Authentication) y Kerberos como mecanismo de autenticación. Sólo se puede configurar una implementación de registro de usuarios para que sea el registro de usuarios activo en el dominio de seguridad de WebSphere Application Server. WebSphere Application Server proporciona las siguientes implementaciones de registro de usuarios: sistema operativo local UNIX, Windows e IBM i y LDAP (Lightweight Directory Access Protocol). También proporciona implementaciones de referencia del registro de usuarios basadas en JDBC (Java Database Connectivity) y en archivos. Da soporte a la combinación flexible de mecanismos de autenticación y registros de usuario. SWAM es fácil de configurar y muy útil en entornos de un solo servidor de aplicaciones. También se puede utilizar SWAM en un entorno distribuido, si está habilitada la aserción de identidad. La característica de aserción de identidad sólo está disponible en el protocolo de seguridad CSIv2.
Nota: SWAM estaba en desuso en un release anterior de WebSphere Application Servery se eliminará en futuros releases.

[AIX Solaris HP-UX Linux Windows][IBM i]El mecanismo de autenticación LTPA está diseñado para la seguridad de todas las plataformas. Los servidores en sentido descendente pueden validar la señal de seguridad. También soporta el establecimiento de una relación de asociación de confianza con servidores proxy seguros inversos y SSO (Inicio de sesión único), lo que se analizará más adelante. Aparte de la combinación de LTPA y la interfaz de registro de usuarios personalizado o LDAP, la versión 6.x o posteriores da soporte a LTPA con una interfaz de registro de usuarios del sistema operativo local. La nueva configuración es particularmente útil para un solo nodo con varios servidores de aplicaciones. Puede funcionar en un entorno distribuido si la implementación del registro de usuarios del sistema operativo local es un registro de usuarios centralizado, como por ejemplo Windows Domain Controller, o si se puede mantener en estado constante en varios nodos.

[AIX Solaris HP-UX Linux Windows][IBM i][z/OS]WebSphere Application Server da soporte a la arquitectura de conector J2EE y ofrece autenticación gestionada por contenedor. Proporciona un módulo de correlación de credenciales y principales J2C (Java 2 Connector) predeterminado que correlaciona cualquier credencial de usuario autenticado con una credencial de contraseña para el dominio de seguridad EIS (Enterprise Information Systems) especificado. El módulo de correlación es un módulo de inicio de sesión JAAS especial que está diseñado según las especificaciones JAAS y el conector de Java 2. También se pueden conectar otros módulos de inicio de sesión de correlación.

[z/OS]

Registros de usuario y control de acceso

La información sobre los usuarios y los grupos reside en un registro de usuarios. En WebSphere Application Server, un registro de usuarios autentica un usuario y recupera información sobre los usuarios y grupos, para ejecutar funciones relacionadas con la seguridad, incluidas la autenticación y la autorización.

WebSphere Application Server proporciona las siguientes implementaciones de registro de usuarios:
  • Sistema operativo local basado en SAF
  • LDAP
  • Depósitos federados

Además de los registros de Local OS, LDAP y repositorios federados, WebSphere Application Server también proporciona un plug-in para dar soporte a cualquier registro utilizando la característica Registro personalizado (también llamado Registro de usuarios personalizado).

Cuando se selecciona la implementación del registro del sistema operativo local de WebSphere Application Server, puede integrar las funciones de z/OS Security Server, como RACF (Resource Access Control Facility), utilizando directamente SAF (Security Access Facility) en el entorno de WebSphere. Si configura un registro distinto del sistema operativo local, también puede aprovechar los recursos de z/OS Security Server con dos opciones. Puede configurar un módulo de correlación JAAS conectable (seguido de un módulo de inicio de sesión JAAS proporcionado por WebSphere Application Server para z/OS) en las configuraciones de inicio de sesión del sistema adecuadas. En WebSphere Application Server Versión 8.5, puede utilizar como alternativa la característica de correlación de identidades distribuidas.

Para más información, consulte Selección de un registro o repositorio.

Configuraciones de WebSphere Application Server: Con WebSphere Application ServerVersión 9.0 para z/OS puede integrar aplicaciones que no son z/OS con recursos específicos de z/OS como SAF (System Authorization Facility) y RACF. Esto permite unificar registros de WebSphere Application Server para z/OS y plataformas que no son z/OS. Por ejemplo:

Tabla 1. Configuración de ejemplo de registro de WebSphere Application Server.

En esta tabla se muestra un ejemplo de configuraciones de registro de WebSphere Application Server

Configuración del servidor de aplicaciones Tipo de registro Método de autorización Ventaja
WebSphere Application Server LDAP Enlaces de WebSphere y proveedores de seguridad externos, por ejemplo Tivoli Access Manager Registros compartidos (en un plataforma heterogénea)
WebSphere Application Server para z/OS RACF Enlaces de WebSphere y EJBROLE de RACF Acceso centralizado y recursos de auditoría (puede incluir servidores que ejecutan la versión 4.0)
Entorno mixto de WebSphere Application Server LDAP o personalizado Enlaces de WebSphere, proveedores de seguridad externos y EJBROLE de RACF Registros compartidos, acceso centralizado y recursos de auditoría
A continuación se proporcionan algunas imágenes que ilustran lo que se ha descrito en la tabla anterior.
  • Configuración de registro de red de WebSphere Application Server configuración de registro de red
  • Configuración de registro de red de WebSphere Application Server para z/OS:configuración de registro de red de z/OS
  • Registro de red de WebSphere Application Server con extensiones de seguridad de z/OS registro de red con extensiones de seguridad de z/OS

Mecanismos de autenticación

En WebSphere Application Server, se admiten los mecanismos de autenticación siguientes:
  • Lightweight Third Party Authentication (LTPA)

    Lightweight Third Party Authentication genera una señal de seguridad para usuarios autenticados, que puede utilizarse para representar a ese usuario autenticado en llamadas posteriores al mismo servidor o a otros servidores dentro de un dominio de inicio de sesión único (SSO).

  • Kerberos

    Para este release de WebSphere Application Server se ha añadido soporte de seguridad para Kerberos como mecanismo de autenticación. Kerberos es un protocolo de autenticación de red desarrollado, flexible, abierto y muy seguro. Kerberos incluye las funciones de autenticación, autenticación mutua, integridad y confidencialidad de mensajes, así como funciones de delegación.

  • SWAM (Simple WebSphere Authentication Mechanism)
    SWAM es fácil de configurar y muy útil en entornos de un solo servidor de aplicaciones, pero fuerza una autenticación de ID de usuario y contraseña para cada solicitud.
    Nota: SWAM estaba en desuso en un release anterior de WebSphere Application Servery se eliminará en futuros releases.

Protocolos de autenticación IIOP

El protocolo de autenticación IIOP hace referencia a los mecanismos utilizados para autenticar solicitudes desde un cliente Java a WebSphere Application Server para z/OS, o entre servidores de aplicaciones J2EE. CSIv2 (Common Secure Interoperability Versión 2) se implementa en WebSphere Application Server para z/OS Versión 6.x o posteriores y se considera el protocolo estratégico.

[z/OS]

Seguridad de conector de WebSphere Application Server para z/OS

WebSphere Application Server da soporte a la arquitectura de conector J2EE y ofrece autenticación gestionada por contenedor. Proporciona un módulo de correlación de credenciales y principales J2C predeterminado que correlaciona cualquier credencial autenticada de usuario con una credencial de contraseña para el dominio de seguridad EIS (Enterprise Information Systems) especificado. También se da soporte a los conectores específicos de z/OS cuando el sistema EIS está en el mismo dominio de seguridad que WebSphere Application Server. En este caso, las contraseñas no son necesarias, ya que las credenciales de autenticación utilizadas para las solicitudes de J2EE se pueden utilizar como credenciales de EIS.

Seguridad de servicios web

WebSphere Application Server permite proteger los servicios web basándose en la especificación de seguridad de servicios web de OASIS (Organization for the Advancement of Structured Information Standards) Versión 1.1. Estos estándares especifican cómo proporcionar protección para el intercambio de mensajes en entornos de servicios web. La especificación define los recursos centrales para proteger la integridad y la confidencialidad de los mensajes y proporciona los mecanismos para asociar al mensaje demandas relacionadas con la seguridad.

Asociaciones de confianza

La asociación de confianza permite integrar los servidores de seguridad de terceros con la seguridad de IBM WebSphere Application Server. En concreto, un servidor proxy inverso puede actuar como servidor de autenticación frontal mientras que WebSphere Application Server aplica su propia política de autorización a las credenciales resultantes que pasa el servidor proxy. El servidor proxy inverso aplica sus políticas de autenticación a cada petición web asignada a WebSphere Application Server. Los productos que implementan los interceptores de asociaciones de confianza (TAI) son:
  • IBM Tivoli Access Manager para e-business
  • WebSEAL
  • Proxy de memoria caché
Para obtener más información sobre la utilización de la asociación de confianza, consulte Asociaciones de confianza.

Propagación de atributos de seguridad

La propagación de atributos de seguridad permite a WebSphere Application Server transportar atributos de seguridad de un servidor a otro en la configuración. Los atributos de seguridad incluyen contenido de sujetos autenticados e información sobre contextos de seguridad. WebSphere Application Server puede obtener estos atributos de seguridad de:
  • Un registro de usuarios de empresa que consulta atributos estáticos
  • Un módulo de inicio de sesión personalizado que puede consultar atributos estáticos o dinámicos
La propagación de atributos de seguridad ofrece servicios de propagación que utilizan la serialización Java para los objetos contenidos en el sujeto. Para obtener más información sobre la propagación de atributos de seguridad, consulte Propagación de atributos de seguridad.

Modalidad de interoperatividad de inicio de sesión único

En WebSphere Application Server, la opción de modalidad de interoperatividad habilita conexiones SSO (Inicio de sesión único) para que WebSphere Application Server versión 6.1.x o posteriores pueda interactuar con versiones anteriores del servidor de aplicaciones. Cuando se selecciona esta opción, WebSphere Application Server añade el LtpaToken antiguo en la respuesta para que se pueda enviar a otros servidores que sólo funcionan con este tipo de símbolo. Esta opción sólo se aplica cuando está habilitada la opción Propagación de atributos de seguridad de entrada web. Para obtener más información sobre el inicio de sesión único, consulte Implementación del inicio de sesión único para minimizar las autenticaciones de usuario web.

[AIX Solaris HP-UX Linux Windows][IBM i][z/OS]

Seguridad para recursos de J2EE con contenedores web y contenedores EJB

Cada contenedor ofrece dos tipos de seguridad: la seguridad declarativa y la seguridad programada. En la seguridad declarativa, la estructura de seguridad de una aplicación (que incluye la integridad y la confidencialidad de los datos, los requisitos de autenticación, los roles de seguridad y el control de acceso) se expresa en un formato externo a la aplicación. En concreto, el descriptor de despliegue es el principal vehículo de la seguridad declarativa en la plataforma J2EE. WebSphere Application Server mantiene una política de seguridad J2EE, incluida la información derivada del descriptor de despliegue y la especificada por los desplegadores y administradores en un conjunto de archivos del descriptor XML. En el tiempo de ejecución, el contenedor utiliza la política de seguridad definida en los archivos del descriptor XML para implantar las restricciones de datos y el control de acceso. Cuando la seguridad declarativa no es suficiente para expresar el modelo de seguridad de la aplicación, el código de la aplicación puede utilizar la seguridad programada para tomar las decisiones de acceso. La API (interfaz de programación de aplicaciones) para la seguridad programada consta de dos métodos de la interfaz EJBContext de EJB (Enterprise JavaBeans) (isCallerInRole, getCallerPrincipal) y tres métodos de la interfaz HttpServletrequest de servlet (isUserInRole, getUserPrincipal y getRemoteUser).

[AIX Solaris HP-UX Linux Windows][z/OS]

Seguridad Java 2

WebSphere Application Server da soporte al modelo de seguridad de Java 2. Los códigos de sistema como el subsistema administrativo, el contenedor web y el contenedor EJB, se ejecutan en el dominio de seguridad de WebSphere Application Server, al que en la actual implementación se otorga el permiso AllPermission y puede acceder a todos los recursos del sistema. El código de aplicación que se ejecuta en el dominio de seguridad de aplicación y al que, de forma predeterminada, se le otorgan los permisos de acuerdo con las especificaciones J2EE, sólo puede acceder a un conjunto restringido de recursos del sistema. Las clases de tiempo de ejecución de WebSphere Application Server están protegidas por el cargador de clases de WebSphere Application Server y son invisibles para el código de aplicación.

[AIX Solaris HP-UX Linux Windows][z/OS]

Seguridad del conector J2EE (Java 2 Platform, Enterprise Edition)

WebSphere Application Server da soporte a la arquitectura de conector J2EE y ofrece autenticación gestionada por contenedor. Proporciona un módulo de correlación de credenciales y principales J2C predeterminado que correlaciona cualquier credencial autenticada de usuario con una credencial de contraseña para el dominio de seguridad EIS (Enterprise Information Systems) especificado.

[z/OS]También se da soporte a los conectores específicos de z/OS cuando el sistema EIS está en el mismo dominio de seguridad que WebSphere Application Server. En este caso, las contraseñas no son necesarias, ya que las credenciales de autenticación utilizadas para las solicitudes de J2EE se pueden utilizar como credenciales de EIS.

[z/OS]Para obtener más información, consulte Identidad de hebra de conexiones.

[z/OS]Proceso de WebSphere Application Server

De forma predeterminada, todos los procesos de servidor de aplicaciones comparten una configuración de seguridad común, definida en un documento XML de seguridad a nivel de célula. La configuración de seguridad determina si se ha aplicado la seguridad de WebSphere Application Server, si se ha forzado la seguridad de Java 2, la configuración del mecanismo de autenticación y el registro de usuarios, las configuraciones del protocolo de seguridad, las configuraciones de inicio de sesión JAAS y las configuraciones SSL. Las aplicaciones pueden tener sus propios requisitos de seguridad exclusivos. Cada proceso del servidor de aplicaciones puede crear una configuración de seguridad por servidor, para dar respuesta a sus propios requisitos de seguridad o correlacionarse con un dominio de seguridad de WebSphere. No todas las configuraciones de seguridad se pueden modificar a nivel de servidor de aplicaciones. Algunas configuraciones de seguridad que pueden modificarse a nivel de servidor de aplicaciones incluyen la posibilidad de aplicar la seguridad de aplicaciones, la seguridad de Java 2 y las configuraciones del protocolo de seguridad. Los dominios de seguridad de WebSphere permiten más control sobre la configuración de seguridad y se pueden correlacionar con servidores individuales. Para obtener más información, consulte Varios dominios de seguridad.

[z/OS]Para obtener más información general, consulte Estados de seguridad con soporte de identidades de hebra.

La configuración de la seguridad del subsistema de administración viene siempre determinada por el documento de seguridad a nivel de célula. La configuración de la seguridad del contenedor web y el contenedor de EJB viene determinada por el documento opcional de seguridad a nivel de servidor, que tiene prioridad sobre el documento de seguridad a nivel célula.

La configuración de seguridad, a nivel de célula y a nivel de servidor de aplicaciones, está gestionada por la aplicación de consola administrativa basada en la web o por la aplicación de scripts adecuada.

[z/OS]Nota: No se puede cambiar los mecanismos de autenticación en el nivel de servidor.

Seguridad Web

Cuando se especifica una política de seguridad para un recurso web y se aplica la seguridad de IBM WebSphere Application Server, el contenedor web realiza el control de acceso cuando un cliente web solicita el recurso. El contenedor web solicita los datos de autenticación al cliente web si no existe ninguno según el método de autenticación especificado, garantiza que se cumplan las restricciones de datos y determina si el usuario autenticado tiene el rol de seguridad necesario. WebSphere Application Server soporta los siguientes métodos de inicio de sesión:
  • Autenticación básica HTTP
  • Autenticación de clientes HTTPS
  • Inicio de sesión basado en formularios
  • Señal SPNEGO (Simple and Protected GSS-API Negotiation)
La correlación de certificados de cliente con credenciales de seguridad de WebSphere Application Server utiliza la implementación UserRegistry para realizar la correlación.

[AIX Solaris HP-UX Linux Windows][IBM i]En WebSphere Application Server, el registro de usuarios del sistema operativo local no da soporte a la función de correlación.

[AIX Solaris HP-UX Linux Windows][IBM i]Cuando se configura el mecanismo de autenticación LTPA y se habilita SSO (inicio de sesión único), se emite para un cliente autenticado una cookie de seguridad, que puede representar al usuario dentro del dominio de seguridad especificado.

Se recomienda utilizar SSL (Capa de sockets seguros) para que no intercepten ni se reproduzcan la cookie de seguridad o la información de autenticación básica. Cuando se configura una asociación de confianza, WebSphere Application Server puede correlacionar una identidad de usuario autenticado con las credenciales de seguridad a partir de la relación de confianza establecida con el servidor proxy inverso seguro.

Seguridad web

Cuando deba considerar los colaboradores de seguridad web y los colaboradores de seguridad EJB:
  1. El colaborador de seguridad web utiliza una implementación del gestor de acceso para aplicar el control de acceso basado en roles. El gestor de acceso toma decisiones de autorización basándose en la política de seguridad derivada del descriptor de despliegue. Un principal de usuario autenticado puede acceder al archivo JSP o al Servlet solicitado si el principal de usuario tiene uno de los roles de seguridad necesarios. Los servlets y los archivos JSP pueden utilizar los métodos HttpServletRequest: isUserInRole, getUserPrincipal y getRemoteUser. Por ejemplo, la consola administrativa utiliza el método isUserInRole para determinar el conjunto apropiado de funciones administrativas que se deben exponer a un principal de usuario.
  2. El colaborador de seguridad de EJB utiliza una implementación del gestor de acceso para aplicar el control de acceso basado en roles. El gestor de acceso toma decisiones de autorización basándose en la política de seguridad derivada del descriptor de despliegue. El principal del usuario autenticado puede acceder al método EJB solicitado si tiene uno de los roles de seguridad necesarios. El código de EJB puede utilizar los métodos EJBContext isCallerInRole y getCallerPrincipal. El código EJB también puede utilizar el modelo de programación JAAS para realizar el inicio de sesión de JAAS y los métodos WSSubject doAs y doAsPrivileged. El código del bloque doAs y doAsPrivileged PrivilegedAction se ejecuta bajo la identidad Subject. De lo contrario, el método de EJB se ejecuta bajo la identidad RunAs o la identidad de llamante, en función de la configuración de RunAs.

Seguridad de EJB

Cuando la seguridad está habilitada, el contenedor de EJB aplica el control de acceso al invocar el método de EJB. La autenticación se realiza independientemente de qué se haya definido un permiso de método para el método EJB específico.

Un cliente de aplicaciones Java puede proporcionar los datos de autenticación de varias formas. Utilizando el archivo sas.client.props, un cliente Java puede especificar si desea utilizar un ID de usuario y una contraseña para la autenticación, o si desea utilizar un certificado de cliente SSL. El certificado de cliente se almacena en el archivo de claves o en la tarjeta criptográfica de hardware, tal como está definido en un archivo sas.client.props. El ID de usuario y la contraseña se pueden definir de manera opcional en el archivo sas.client.props.

En tiempo de ejecución, el cliente Java puede realizar un inicio de sesión programado o realizar una autenticación poco activa.

En la autenticación poco activa, cuando el cliente Java accede a un enterprise bean protegido por primera vez, el tiempo de ejecución de seguridad intenta obtener los datos de autenticación necesarios. Dependiendo del valor de configuración en el archivo sas.client.props, el tiempo de ejecución de seguridad busca los datos de autenticación de este archivo o se los pide al usuario. El cliente Java también puede utilizar el inicio de sesión programado. WebSphere Application Server da soporte al modelo de programación JAAS, y el inicio de sesión JAAS (LoginContext) es la forma recomendada de iniciar sesión mediante programación. La función de ayudante login_helper request_login está en desuso en la versión 6.x y Versión 9.0. Los clientes Java programados en el APT login_helper pueden ejecutarse en esta versión.

El colaborador de seguridad de EJB utiliza una implementación del gestor de acceso para aplicar el control de acceso basado en roles.

El gestor de acceso toma decisiones de autorización basándose en la política de seguridad derivada del descriptor de despliegue. El principal del usuario autenticado puede acceder al método EJB solicitado si tiene uno de los roles de seguridad necesarios. El código EJB puede utilizar los métodos EJBContext: isCallerInRole y getCallerPrincipal. El código EJB también puede utilizar el modelo de programación JAAS para realizar el inicio de sesión JAAS y los métodos WSSubject doAs y doAsPrivileged. El código en el bloque de PrivilegedAction doAs y doAsPrivileged se ejecuta con la identidad de Sujeto. De lo contrario, el método de EJB se ejecuta con la identidad de RunAs o la identidad del llamante, dependiendo de la configuración de RunAs. La especificación RunAs de J2EE ocurre a nivel de enterprise bean. Cuando se especifica la identidad de RunAs, se aplica a todos los métodos de bean. La extensión de IBM RunAs a nivel de método presentada en la versión 4.0 continúa estando soportada en esta versión.

[z/OS]Nota: Una vez realizada la autorización, la identidad de RunAs se utiliza en sentido descendente. Normalmente es la identidad del llamante, pero también puede ser una identidad delegada.

Aprobación de FIPS (Federal Information Processing Standards)

FIPS (Federal Information Processing Standards) son los estándares y directrices emitidos por el National Institute of Standards and Technology (NIST) para los sistemas informáticos federales. Los FIPS se desarrollan cuando el gobierno federal tiene una necesidad urgente de estándares, como por ejemplo para la seguridad y la interoperatividad, pero no existen estándares ni soluciones del sector aceptables.

WebSphere Application Server integra módulos criptográficos, que incluyen JSSE (Java Secure Socket Extension) y JCE (Java Cryptography Extension), que se han sometido a la certificación FIPS 140-2.

[AIX Solaris HP-UX Linux Windows][IBM i][z/OS]Para más información, consulte Configuración de los archivos JSSE (Java Secure Socket Extension) aprobados por FIPS (Federal Information Processing Standard).

El módulo IBMJCEFIPS da soporte a los siguientes suites de cifrado simétricos:
  • AES (FIPS 197)
  • TripleDES (FIPS 46-3)
  • SHA1 Algoritmo de conversión de mensajes (FIPS 180-1)
El módulo IBMJCEFIPS da soporte a los siguientes algoritmos:
  • Algoritmos RSA y DSA de firma digital (FIPS 186-2)
  • ANSI X 9.31 (FIPS 186-2)
  • IBM Random Number Generator

El módulo criptográfico IBMJCEFIPS contiene los algoritmos aprobados por FIPS, que constituyen un subgrupo adecuado de los que aparecen en los módulos IBM JCE.


Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=welc_security
File name: welc_security.html