Q & A: Preguntas frecuentes sobre la seguridad de WebSphere Application Server

Dado que la integridad de su entorno de procesamiento se encuentra en riesgo, las preguntas sobre la seguridad deben responderse lo antes posible. A tal fin, este artículo provee respuestas rápidas y directas a algunas de las preguntas más frecuentes sobre la seguridad de IBM® WebSphere® Application Server. This content is part of the IBM WebSphere Developer Technical Journal.

Keys Botzum, Senior Technical Staff Member , EMC

Keys Botzum es Miembro Senior del Personal Técnico de IBM Software Services for WebSphere. El Sr. Botzum tiene más de 10 años de experiencia en el diseño de sistemas distribuídos a gran escala y además se especializa en seguridad. El Sr. Botzum ha trabajado con una gran variedad de tecnologías distribuidas, incluyendo Sun RPC, DCE, CORBA, AFS, y DFS. Recientemente, ha estado concentrado en J2EE y tecnologías relativas a ésta. Posee una Maestría en Ciencias Informáticas de la Universidad de Stanford y una Licenciatura en las Ciencias Matemática e Informática Aplicadas de la Universidad Carnegie Mellon. El Sr. Botzum ha publicado varios documentos sobre WebSphere y Seguridad de WebSphere. Otros artículos y presentaciones escritos por Keys Botzum pueden encontrarse en http://www.keysbotzum.com, y también en IBM developerWorks WebSphere. También es co-autor de IBM WebSphere: Deployment and Advanced Configuration.


Nivel de autor profesional en developerWorks

Bill O'Donnell, Lead WebSphere Security Architect, WSO2 Inc

Author photoBill O'Donnell es el arquitecto principal de Seguridad de WebSphere y trabaja en la organización del desarrollo del producto WebSphere. Es responsable de la arquitectura de seguridad de WebSphere Application Server. Bill posee más de 25 años de experiencia en mainframes a gran escala y sistemas distribuidos especialmente en la arquitectura de desarrollo y en la arquitectura de infraestructura. Bill se especializa en la infraestructura integral y en la seguridad de las aplicaciones. Ha publicado varios Redbooks y es el autor de Secrets of SOA. Bill es co-sponsor del WebSphere Application Server security web site.



11-05-2010

Preguntas frecuentes

Un tema tan crítico como la seguridad del servidor de aplicaciones indica un volumen digno de preguntas igualmente críticas. Para facilitar la comprensión de la seguridad de IBM® WebSphere® Application Server en general, y de qué manera es (o debería ser) aplicado en su entorno, aquí se presentan algunas de las preguntas más frecuentes, relacionadas con WebSphere Application Server V6.1 y V7.0.

Las preguntas y respuestas enumeradas aquí son presentadas en tres amplias categorías:

Registro

  1. ¿En qué momento WebSphere Application Server se contacta con el registro en busca de información de los usuarios?
  2. ¿Trabaja WebSphere Application Server con NIS?
  3. ¿Cuáles son mis opciones si quiero activar la seguridad con una cuenta que no sea la de administrador en un entorno de® Windows?
  4. ¿Cuáles son mis opciones si deseo activar la seguridad con una ID de servidor no raíz en un entorno UNIX?®
  5. ¿Funcionará la autenticación de OS Local en un entorno distribuído?
  6. Mis usuarios se autentican con una ID de usuario pero deseo que que sean identificados con otra ID desde LDAP. ¿Es esto posible?
  7. Al utilizar un almacén federado, ¿existe alguna forma de asegurar que mi registro basado en archivos seguirá funcionando si un servidor LDAP esté desactivado?

Autenticación

  1. ¿Por qué necesito habilitar SSO al utilizar un login basado en formularios en mi aplicación WebSphere Application Server?
  2. Deseo obligar a mis usuarios a volver a conectarse después de cierto "período de inactividad". ¿De qué manera se supone que reaccione WebSphere Application Server a los tiempos de expiración y tiempos de espera de LTPA?
  3. ¿Hay algo que yo pueda hacer para evitar que mis claves de LTPA se desincronicen entre las celdas?
  4. ¿Puede una celda de WebSphere Application Server abarcar múltiples dominios de DNS?
  5. ¿Por qué no se aconseja el uso de SWAM?
  6. ¿Cuándo debería utilizar un módulo de login personalizado versus un TAI para afirmar la información de identificación?

Otras preguntas sobre la seguridad

  1. ¿Cómo puedo cambiar mis claves (base de datos, LDAP, y demás) sin causar una interrupción?
  2. ¿Cuáles son las extensiones de propiedad de WebSphere Application Server que le proveen seguridad a J2EE™
  3. WebSphere Application Server almacena las contraseñas XOR codificadas. Me gustaría utilizar algo más sólido. ¿Qué puedo hacer?
  4. ¿De qué manera puedo depurar las excepciones de seguridad de Java 2™ y AccessControlExceptions?
  5. ¿Existe alguna documentación disponible sobre la mejor manera en la que se puede configurar Microsoft Active Directory con WebSphere Application Server?

Registro

1. ¿En qué momento WebSphere Application Server se contacta con el registro para solicitar información del usuario?

WebSphere Application Server consulta el registro en busca de información del usuario y de las operaciones administrativas. Por este motivo, el registro debe estar casi el 100% disponible para que una sesión de WebSphere Application Server funcione.

Éstas son las razones por las cuales WebSphere Application Server contacta el registro:

  • Cuando los usuarios se autentican (contraseña o certificado, no se necesita con un proxy de Web SSO). WebSphere Application Server podría consultar cuando éste:
    • Verifica la contraseña del usuario.
    • Asigna la información del certificado a un userid.
    • Convierte las identificaciones de usuario para registrar los userids únicos (por ejemplo, LDAP DN).
    • Obtiene información de grupo.
  • Cuando un token de LTPA es enviado a un servidor por primera vez. WebSphere Application Server obtiene información del grupo aun cuando un token de Lightweight Third Party Authentication (LTPA) es enviado a un servidor por primera vez (por ejemplo, mediante el tráfico de WebSEAL o IIOP) porque el token de LTPA contiene sólo el nombre distinguido de usuario. Lo mismo se aplica para Trust Association Interceptors (TAIs) porque normalmente se provee sólo el userid. Si se utiliza WebSphere Application Server V5.1.1, y la divulgación del objeto está habilitada, y el TAI o módulo de login contiene información del grupo (como puede suceder con el nuevo WebSEAL TAI en WebSphere Application Server V5.1.1), entonces WebSphere Application Server no consultará a LDAP en busca de información sobre el grupo de usuario para ese usuario.
  • Cuando la divulgación del objeto falla. Aun cuando la divulgación del objeto esté habilitada, si la la misma estuviera a punto de fallar (por ejemplo, si un servidor se desactivara), entonces WebSphere Application Server intentará recrear el objeto a menos que una contraseña de la cache personalizada haya sido determinada.
  • Cuando los usuarios se autentican para operaciones administrativas (Web, JMX y otras).
  • Siempre que se inicie una aplicación, los vínculos de los roles son verificados conr especto al registro
  • Siempre que un administrador establezca información vinculante en la consola administrativa.

2. ¿Funciona WebSphere Application Server con NIS?

WebSphere Application Server no da soporte directamente a NIS (Network Information Service) para la autenticación. Da soporte a LDAP, OS y a la personalización. Al ejecutarse en un sistema operativo UNIX, WebSphere Application Server utiliza las APIs estándares de la contraseña de UNIX (getpw*, y demás) para verificar la contraseña (WebSphere Application Server debe ejecutarse como raíz para que esto funcione). Si esas APIs realizan una llamada a NIS, entonces WebSphere Application Server utilizará NIS para la autenticación, pero esto es transparente para WebSphere Application Server. Sin embargo, cuando un registro OS es utilizado en UNIX, entonces las celdas de múltiples nodos no son soportadas.

Es posible escribir un registro personalizado para utilizar NIS.

En la mayoría de los casos, la respuesta a esta pregunta es no.

3. ¿Cuáles son mis opciones si deseo activar la seguridad con una cuenta que no sea de administrador en un entorno de Windows?®

Al ejecutar los procesos de WebSphere Application Server como cuenta que no sea de administrador, si la seguridad global está habilitada, el registro de usuario debe ser LDAP o un registro personalizado

Para utilizar el registro de usuario Local OS, el usuario bajo el cual son ejecutados los procesos del producto debe tener los privilegios de Administrtive y Act entre los privilegios del sistema operativo para llamar a las APIs del sistema operativo Windows que autentica o reúne la información de usuario y del grupo. El proceso requiere una autoridad especial, la cual es otorgada a través de estos privilegios. El usuario en este ejemplo no debería ser igual a la identificación del servidor de seguridad (el requisito por el cual es un usuario válido en el registro). Este usuario se registra en una máquina (si utiliza una línea de comando para comenzar el proceso del producto) o el registro en la configuración del usuario en el panel de servicios (si los procesos del producto han comenzado a utilizar los servicios). Si la máquina forma parte también de un dominio, este usuario debería ser parte del Domain Admin en el dominio para realizar las llamadas a las APIs del sistema operativo en el dominio, además de tener el privilegio de Act como parte del privilegio del sistema operativo en la máquina local.

4. ¿Cuáles son mis opciones si deseo activar la seguridad con una identificación de servidor no raiz en un entorno de UNIX?®

Al ejecutar WebSphere Application Server como no raiz, si la seguridad global se encuentra habilitada, el registro de usuario debe ser LDAP o un registro personalizado.

Para utilizar el registro de usuario Local OS, el usuario bajo el cual los procesos del producto son ejecutados debe tener el privilegio de raíz. Este privilegio es necesario para llamar a las APIs del sistema operativo UNIX para autenticar o reunir información del usuario y del grupo. Para este proceso se necesita autoridad especial, la cual es otorgada por el privilegio de raiz. El uso del registro del usuario Local OS requiere el agente del nodo, el administrador de despliegue, y el proceso del servidor de aplicaciones para ejecutar como raíz.

5. ¿Funcionará la autenticación Local OS en un entorno distribuido?

En WebSphere Application Server Network Deployment con nodos de servidor de aplicaciones distribuidos en más de una máquina, usted no puede utilizar la autenticación Local OS. En este entorno, usted debe usar LDAP o un registro personalizado. Pero existe una excepción, un registro de dominio de Windows es un registro centralizado y puede ser utilizado en esta situación. Tenga en cuenta que aunque NIS es técnicamente es un registro centralizado, no es apropiado utilizarlo con WebSphere Application Server Network Deployment.

Puede encontrar más información en el artículo del Centro de Información: Local operating system registries.

6. Mis usuarios se autentican con un userid pero deseo que sean identificados con otra identificación desde LDAP. ¿Es esto posible?

Existe una forma de configurar WebSphere Application Server para hacerlo. Esto implica que la entrada LDAP para cada usuario tenga un atributo que contenga una secuencia de caracteres que puedan utilizarse para la segunda identificación de usuario. Por ejemplo, llamemos a este atributo myname. Supongamos que el userid utilizado para la autenticación está contenida en un atributo LDAP denominado uid.

En la configuración LDAP de WebSphere Application Server (desde la consola administrativa, haga un clic en Security > User Registries > LDAP > Advanced LDAP Settings), modifique el campo de asignación de la identificación de usuario de *:uid a *:myname . Esto básicamente le dice a WebSphere Application Server que establezca para el J2EE principal que es devuelto a la aplicación el valor del atributo LDAP myname. Por lo general, WebSphere Application Server devolvería la misma identificación de usuario que se utilizó para iniciar la sesión.

Por ejemplo, supongamos que una entrada LDAP de usuario tiene los siguientes pares de atributos/valores: uid=dale.sue.ping, myname=sueping.

Con este cambio en la configuración LDAP de WebSphere Application Server LDAP, el usuario iniciaría la sesión con un userid de dale.sue.ping, se autenticaría con WebSphere Application Server/LDAP y, si la autenticación fuera exitosa, WebSphere Application Server fijaría el principal J2EE en sueping.

Si la aplicación tiene la capacidad de extraer el principal J2EE, la aplicación verá el usuario como "sueping" y no como "dale.sue.ping."

7. Al utilizar un almacén federado, ¿existe una manera de asegurar que el registro basado en archivos continúe funcionando cuando el servidor LDAP está desactivado?

Si, una de las opciones de la configuración permite realizar la autenticación para continuar cuando uno o más registros están desactivados, si la identificación se encuentra en uno de los registros que aún están listos y en funcionamiento. El comando de configuración del almacén federado para permitir esto es:

$AdminTask createIdMgrRealm -name ibmRealm -allowOperationIfReposDown true

Puede encontrar más información relativa a este tema en el artículo del Centro de Información: IdMgrRealmConfig command group for the AdminTask object.


Autenticación

8. ¿Por qué necesito habilitar SSO al utilizar un login basado en formularios en mi aplicación WebSphere Application Server?

Al habilitar SSO, WebSphere Application Server mantiene el estado del usuario como una cookie de LDAP en todos los pedidos a la Web. Si SSO no se encuentra habilitada, cada pedido requiere autenticación por separado. Si usted decide utilizar un login basado en formularios, una vez que el formulario complete la autenticación, el usuairo es entonces redireccionado a la URL pedida originalmente. Sin SSO, la autenticación del usuario se perderá y la autenticación fallará. Esto no sucede al utilizar la autenticación básica porque la información de la autenticación se encuentra en cada pedido HTTP y WebSphere Application Server puede utilizarlo siempre que lo necesite (esto tiene un impacto tanto en la seguridad como en la performance).

9. Deseo obligar a mis usuarios a iniciar la sesión nuevamente tras un cierto período de inactividad. ¿De qué forma trabaja WebSphere Application Server en relación con los tiempos de expiración de la sesión y con los tiempos de espera de LTPA?

El token de LTPA de Websphere Application Server expira basándose en el tiempo de vida de la sesión de login, y no en la inactividad. De este modo, las sesiones de login de WebSphere Application Server no expiran si el usuario no realiza ninguna acción durante un tiempo determinado. Sin embargo, la Sesión de HTTP sí expira debido a motivos de inactividad. Si en su aplicación usted necesita que expire el uso de una determinada aplicación debido a la inactividad, debe codificar esto en forma explícita en su aplicación. Puede detectar cuando la sesión de un usuario haya expirado y obligarlo a iniciar la sesión de nuevo si cree que es necesario (realmente, una nueva sesión). Tenga en cuenta que al hacer esto afecta los Single Sign On en todas las aplicaciones.

Una segunda opción que es una pequeña variación de la primera es el uso de HTTPSession.getLastAccessTime() para registrar cuándo se realizó el último pedido del cliente. Si pasó demasiado tiempo, usted puede, por supuesto, no aprobar el acceso y forzarlo a autenticarse de nuevo.

Cualquiera de estas opciones puede hacer transparente el código de aplicación por medio del uso de filtros servlet.

Es importante tener presente que IBM Tivoli® Access Manager proporciona los tiempos de expiración de las sesiones de autenticación provocados por la inactividad y por el tiempo de vida.

Los usuarios por lo general se preguntan por qué WebSphere Application Server trabaja de este modo. ¿Por qué expiran las sesiones de login inactivas? La razón es que WebSphere Application Server es fundamentalmente un sistema distribuido débilmente acoplado. Los servidores de aplicaciones que participan en un dominio SSO no necesitan comunicarse entre sí. Ni siquiera es necesario que estén en la misma celda. Por lo cual, si usted desea limitar el tiempo de vida de inactividad de un token de LTPA (conocido como token SSO), tendría que actualizar el token con el último tiempo de uso en cada pedido (o quizá en el primer pedido visto durante un intervalo de un minuto). Esto significa que el token cambiaría por si mismo frecuentemente (es decir que el buscador aceptaría frecuentemente nuevas cookies) y que WebSphere Application Server tendría que descifrar y verificar el token entrante cuando tiene que validarlo. Esto podría ser caro (WebSphere Application Server hoy sólo valida un token en el primer uso de cada servidor de aplicaciones). No es posible resolver todos los problemas con un caching inteligente o algo por el estilo, pero WebSphere Application Server hoy en día no funciona de esta manera.

10. ¿Hay algo que pueda hacer para evitar que mis contraseñas de LTPA se desactualicen entre las celdas?

Si. WebSphere Application Server V6.1 presenta un dispositivo que permite automáticamente regenerar sus contraseñas de LTPA por omisión. Mientras que ésta es una característica positiva para la configuración de una celda, cualquier usuario que tenga celdas múltiples y necesite que las contraseñas de LTPA sean actualizadas entre las celdas debería desactivar el dispositivo auto-regen de LTPA. En WebSphere Application Server V7, este dispositivo es desactivado por omisión, y en nuevos perfiles creados en V6.1.0.23 este dispositivo se encuentra desctivado por omisión.

11. ¿Pueden las celdas de WebSphere Application Server abarcar múltiples dominios de DNS?

Antes de la existencia de WebSphere Application Server V6, la respuesta era no. Esto es así debido a que cuando usted configura la seguridad de WebSphere Application Server, uno de los items que usted necesita para especificar era el dominio de SSO del token de LTPA. Si usted deja esto en blanco, el dominio del token o de la cookie se fija en blanco, lo que significa que la cookie vuelve sólo al mismo servidor. Si usted coloca un valor, el dominio de la cookie se determina para ello y luego la cookie vuelve a los servidores dentro del mismo dominio de DNS. Éste es el comportamiento requerido por la especificación de HTTP. El problema es que si su celda (o en realidad los servidores de la Web) respondieron a pedidos por dominios de DNS múltiples, no hay manera de especificar más de un dominio. A partir de la aparición de WebSphere Application Server V6, el valor del dominio de SSO especificado a WebSphere Application Server puede contener múltiples dominios de DNS. Ahora, usted puede especificar todos los dominios que necesite. Cuando WebSphere Application Server crea la cookie, fija el valor de dominio para la cookie (la especificación de HTTP permite sólo un valor) al valor del pedido entrante que conincide con uno de los dominios configurados.

Puede encontrar ejemplos de nombres de dominios válidos en ibm.com y tx.gov. Puede encontrar ejemplos de nombres de dominios inválidos en y state_tx.gov. Algunos usuarios han tenido problemas en Internet Explorer (IE), dado que IE 5 y IE 6 aparentemente no aceptan los tokens de LTPA cuando el dominio definido en el campo de dominio de SSO es menor que cinco caracteres, excluyendo el período, como por ejemplo "cn.ca". Microsoft has a fix for this.

12. ¿Por qué no se aconseja el uso de SWAM?

Simple WebSphere Authentication Mechanism (SWAM) ha sido creado para los entornos de tiempo de ejecución de aplicaciones simples, no distribuidos. Esta restricción del servidor de aplicaciones se debe al hecho de que SWAM no da soporte a las credenciales remitibles. Esto significa que si un servlet o un bean de una empresa en el proceso del servidor de una aplicación apela a un un método remoto en un bean de una empresa que reside en otro proceso del servidor de aplicaciones, la identidad del llamador no es transmitida al segundo proceso del servidor. Lo que sí es transmitida es una credencial no autenticada, lo cual, dependiendo de los permisos de seguridad configurados en los métodos EJB, podría causar errores de autorización.

SWAM puede utilizarse como mecanismo de autenticación en la edición básica de WebSphere Application Server. SWAM no es una opción soportada por WebSphere Application Server Network Deployment V5.0. El uso del mismo en la edición básica tampoco es recomendado dado que depende del objeto de la sesión HTTP para mantener el estado del usuario, lo cual es problemático ya que el nivel de la sesión HTTP no forma parte de la infraestructura de seguridad.

13. ¿Cuándo debería utilizar un módulo de login personalizado contra un TAI para corroborar la información de la identidad?

Nota: Si un usuario ya ha sido autenticado por algún sistema de autenticación distinto de WebSphere Application Server, es posible indicarle a WebSphere Application Server sobre la información de la identidad del usuario en lugar de solicitarle al usuario que se autentique nuevamente. Esto es conocido como reafirmación de la identidad. Para obtener más información sobre la reafirmación de identidad relacionada con TAI, remítase a Advanced authentication in WebSphere Application Server.

Tabla 1. Módulo de login vs. TAI
DispositivoMódulo de loginTAI
Marca registrada de IBMNo, pero requiere código específico de WebSphere Application Server de todos modos
Dificultad de usoMás difícilMás fácil
Autenticación multifaseNo
Elimina el desafío del registro en la WebNo
Puede utilizarse para llamadas Web
Puede utilizarse para llamadas RMI No
(Re)llamadas para logins de propagaciónNo

Otras preguntas sobre la seguridad

14. ¿Cómo cambio mis contraseñas (base de datos, LDAP, y otros) sin causar una interrupción?

  1. Alterne el uso de un par de identificaciones de usuario, tales como useridA y useridB, y suponga que está ejecutando por medio del useridA.
  2. Establezca la nueva contraseña para useridB.
  3. Cambie todo uso/evento de useridA por useridB con la nueva contraseña. Es útil en estos casos tener todo documentado.
  4. Recicle cada servidor en el cluster de a uno por vez, de esta forma siempre habrá un nodo ejecutándose.
  5. Establezca la nueva contraseña para useridA. Si salteó algo en el paso 3, la contraseña se romperá pero no afectará los otros eventos que hayan sido modificados correctamente.
  6. La próxima vez que modifique las contraseñas, vuelva a cambiar de useridB a useridA.

Dado que ambas combinaciones de identificación de usuario /contraseña son válidas durante la transición, usted no tiene que preocuparse por la sincronización.

15. ¿Qué extensiones de propiedad le proporciona WebSphere Application Server a la seguridad de J2EE?™

  • El token LTPA no es lo más típico, pero se trata simplemente de una credencial/token y no afecta al equipo de desarrollo de aplicaciones.
  • Redirecciona a la URL ibm_security_logout para eliminar el token LTPA una vez que el usuario cierra la sesión.
  • WSSubject, WSCredential, y WSPrincipal son extensiones IBM para clases estándar Subject, Credential, y Principal de J2EE. Son necesarios en algunos casos debido a defectos en las clases estándar.
  • Trust Association Interceptors (TAI) con frecuencia son utilizados para la interfaz de WebSphere Application Server con servidores alternos SSO (WebSEAL, ClearTrust, Siteminder, y otros). De nuevo, ésta es simplemente la capa de autenticación y no debería afectar la transferibilidad de las aplicaciones; sin embargo, cuando usted se mueve a otro contenedor J2EE debe asegurarse de que entre el servidor alterno SSO y WebSphere Application Server haya una interfaz similar. Controle que sus desarrolladores estén utilizando las APIs de los servidores alternos SSO.
  • Custom User Registry (CUR) es también una capa de integración para los usuarios que no estén utilizando uno de los tipos de registros estándar de WebSphere Application Server (Sistema operativo, LDAP) o no estén utilizándolos en la forma tradicional.
  • Java 2 Security Policy Files contiene algunas extensiones menores del el estándar. De nuevo, forman parte de la infraestructura y no del código de aplicaciones, pero el archivo was.policy está incluído en el archivo EAR.
  • APIs de WebSphere Application Server Administrative son funciones administrativas de WebSphere Application Server que se encuentran disponibles en el formulario API de manera que pueden solicitarse desde las aplicaciones. Aunque parte de esto puede realizarse utilizando JMX estándar, otras APIs son específicas de WebSphere Application Server. Es poco probable (y debería estar prohibido) que éstas sean utilizadas en aplicaciones empresariales, pero téngalas en cuenta en caso de escribir aplicaciones administrativas.
  • wsadmin scripting técnicamente no forma parte de sus aplicaciones empresariales tampoco, pero tenga presente que los scripts escritos para las funciones adminstrativas deben reescribirse si se trasladan a otro producto. Para tareas como el despliegue, es mejor utilizar algo como Ant, el cual es accesible. Tenga en cuenta que algunos comandos de Ant que vienen con WebSphere Application Server, IBM WebSphere Studio Application Developer, e IBM Rational® Application Developer son exclusivos de IBM.

También, tenga presente que hay otras APIs de propiedad disponibles que no forman parte de la seguridad, tales como las APIs de dynacache para comandos, y el caching de objetos Java y las llamadas WebSphereMQ que están fuera de JMS.

16. WebSphere Application Server almacena las contraseñas de XOR codificadas. Me gustaría utilizar algo más sólido. ¿Qué puedo hacer?

Antes de la aparición de WebSphere Application Server V6.0.2, se podía hacer poco con respecto a esto. Si no le gustaba como WebSphere Application Server almacenaba las contraseñas para los recursos de J2C, usted podía escribir su propio módulo de login J2C personalizado para obtener las contraseñas de una fuente externa a WebSphere Application Server, pero esto no lo ayudaría con el problema de la existencia de las otras contraseñas utilizadas por WebSphere Application Server: LDAP bind, WebSphere Application Server admin, entre otros.

Con WebSphere Application Server V6.0.2, usted puede incluso configurar su propio codificador de contraseñas personalizado para implementar la protección que crea conveniente. Para hacer esto usted implementa la interfaz de conexión (com.ibm.wsspi.security.crypto.CustomPasswordEncryption) y luego especifica dos propiedades de seguridad personalizadas en security.xml. Usted también puede establecer estas propiedades en PropFilePasswordEncoder.bat/sh. Estas dos propiedades son:

  • com.ibm.wsspi.security.crypto.customPasswordEncryptionClass
  • com.ibm.wsspi.security.crypto.customPasswordEncryptionEnabled.

Para obtener más información, consulte el artículo del Centro de Información: Plug point for custom password encryption.

17. ¿Cómo puedo depurar las excepciones de seguridad Java 2 y las Excepciones de Control de Acceso?

Existen dos ayudas fundamentales, los archivos WebSphere SystemOut.log y com.ibm.websphere.java2secman.norethrow property. AccessControlException registrado en el archivo SystemOut.log contiene la violación de permiso que causa la excepción, la pila de llamadas de excepción, y los permisos otorgados a la estructura de cada pila. Esta información es por lo general suficiente para determinar el permiso faltante y el código que requiere el permiso.

Si la seguridad de Java 2 está habilitada en WebSphere Application Server, el componenente administrador de seguridad arroja una excepción java.security.AccessControl cuando ocurre una violación al permiso. Si esta excepción no se trata, por lo general, provoca un error en el tiempo de ejecución. Esta excepción también es registrada en el archivo SystemOut.log.

Sin embargo, cuando la propiedad de JVM com.ibm.websphere.java2secman.norethrow ha sido establecida y tiene un valor de verdadero, el administrador de la seguridad no arroja la excepción AccessControl. Esta información es registrada.

Para establecer la propiedad com.ibm.websphere.java2secman.norethrow para el servidor, diríjase a la consola administrativa de WebSphere Application Server y seleccione Servers > Application Servers. Debajo de Additional Properties, haga un click en Process Definition > Java Virtual Machine > Custom Properties > New. En el campo Name, ingrese com.ibm.websphere.java2secman.norethrow. En el campo Value, ingrese verdadero.

18. Existe documentación disponible en la que se indique la mejor forma de configurar Microsoft Active Directory con WebSphere Application Server?

Sí, recientemente hemos agregado algunos consejos útiles basándonos en la experiencia que nuestro equipo de IBM Software Services for WebSphere ha tenido con otros clientes. Por favor remítase a nuestro white paper Using Microsoft Active Directory with IBM WebSphere Application


Resumen

Si no encuentra aquí las respuestas a sus preguntas más importantes sobre la seguridad, asegúrese de verificar los Recursos que aparecen más abajo, y en particular la nueva página de recursos WebSphere Application Server security resources page on developerWorks, where much of the most noteworthy material on WebSphere Application Server security will be continually spotlighted.

Recursos

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere
ArticleID=489330
ArticleTitle=Q & A: Preguntas frecuentes sobre la seguridad de WebSphere Application Server
publish-date=05112010