[AIX Solaris HP-UX Linux Windows][IBM i]

Autenticación de la capa de mensajes

Define la información de credencial y envía esta información a través de la red para que un servidor receptor pueda interpretarla.

Cuando se envía información de autenticación a través de la red mediante una señal, la transmisión se considera que es una autenticación de la capa de mensajes porque los datos se envían con el mensaje en un contexto de servicio.

Un cliente Java™ puro utiliza Kerberos (KRB5) o autenticación básica, o la autenticación básica GSSUP (Generic Security Services Username Password) como mecanismo de autenticación para establecer la identidad del cliente.

[AIX Solaris HP-UX Linux Windows][IBM i][z/OS]No obstante, un servlet puede utilizar la autenticación básica GSSUP o el mecanismo de autenticación del servidor, Kerberos (KRB5) o LTPA (Lightweight Third Party Authentication) para enviar información de seguridad en la capa de mensajes. Utilice KRB5 o LTPA autenticando o correlacionando las credenciales de autenticación básica con el mecanismo de seguridad del servidor.

La señal de seguridad que contiene una credencial basada en señales es específica del mecanismo de autenticación. El modo en que se interpreta la señal solamente lo conoce el mecanismo de autenticación. Por lo tanto, cada mecanismo de autenticación tiene un ID de objeto (OID) que lo representa. El OID y la señal de cliente se envían al servidor, para que éste sepa qué mecanismo debe utilizar cuando lea y valide la señal. La lista siguiente contiene los OID de cada mecanismo:

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

BasicAuth (GSSUP):  oid:2.23.130.1.1.1
KRB5: OID: 1.2.840.113554.1.2.2
LTPA:    oid:1.3.18.0.2.30.2
SWAM:     No hay OID ya que no es direccionable

Nota: SWAM está en desuso en WebSphere Application Server Versión 9.0 y se eliminará de releases futuros.
En el servidor, los mecanismos de autenticación pueden interpretar la señal y crear una credencial, o pueden autenticar los datos de la autenticación básica del cliente y crear una credencial. En ambos casos, la credencial creada es la credencial recibida que utiliza la comprobación de autorización para determinar si el usuario tiene acceso para invocar el método. Puede especificar el mecanismo de autenticación utilizando la siguiente propiedad en el lado del cliente:
  • [AIX Solaris HP-UX Linux Windows][IBM i][z/OS]com.ibm.CORBA.authenticationTarget
La autenticación básica (BasicAuth) y KRB5 son actualmente los únicos valores válidos. Puede configurar el servidor con la consola administrativa.
Nota: Cuando se habilita la opción de realizar la autenticación básica, si el cliente no se ha configurado del mismo modo, no pasa una credencial, como un ID de usuario y una contraseña.
[AIX Solaris HP-UX Linux Windows][IBM i][z/OS]

Configuración de reintentos de autenticación

Hay situaciones en las que desea que vuelva a visualizarse un indicador si ha especificado incorrectamente el ID de usuario y la contraseña o un método de reintento cuando se produce un error determinado en el cliente. Si puede corregir el error mediante algún tipo de información en el lado del cliente, el sistema realiza automáticamente un reintento sin que el cliente vea el error, si el sistema se ha configurado correctamente.

Algunos de estos errores son:
  • Especificar un ID de usuario y una contraseña que no sean válidos
  • Tener una credencial caducada en el servidor
  • No encontrar la sesión con estado en el servidor
De forma predeterminada, los reintentos de autenticación están habilitados y se realizan tres reintentos antes de devolver un error al cliente. Utilice la propiedad com.ibm.CORBA.authenticationRetryEnabled (True o False) para habilitar o inhabilitar los reintentos. Utilice la propiedad com.ibm.CORBA.authenticationRetryCount para especificar el número de reintentos.
[AIX Solaris HP-UX Linux Windows][IBM i][z/OS]

Validación inmediata de una conexión de autenticación básica

En WebSphere Application Server Versión 6.x, se define un comportamiento durante request_login para una conexión BasicAuth. En los releases anteriores al versión 5, una conexión BasicAuth toma el ID de usuario y la contraseña especificados mediante el método loginSource y crea una credencial BasicAuth. Si el ID de usuario o la contraseña no son válidos, el programa cliente no lo sabrá hasta que se intente la primera solicitud de método. Cuando se especifique el ID de usuario o la contraseña durante una conexión con indicador o una conexión programada, se autenticarán de forma predeterminada con el servidor de seguridad y como resultado se devolverá True o False. Si es False, se devuelve una excepción org.omg.SecurityLevel2.LoginFailed al cliente indicando que el ID de usuario y la contraseña no son válidos. Si es True, se devuelve la credencial BasicAuth al emisor de la llamada de request_login. Para inhabilitar esta característica en el cliente puro, especifique com.ibm.CORBA.validateBasicAuth=false. De forma predeterminada, esta característica se establece como True. En el servidor, especifique esta propiedad en las propiedades dinámicas de seguridad.

Nota: Establezca com.ibm.CORBA.validateBasicAuth=false siempre que se conecte a un servidor z/OS. Actualmente esta función no funciona correctamente desde un cliente distribuido a un servidor z/OS ya que SecurityServer se localiza mediante el principal "UNAUTHENTICATED", que no se acepta en el sistema z/OS.

Icon that indicates the type of topic Reference topic



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