Visión general del uso de Kerberos para servicios web

Puede utilizar una señal Kerberos para completar funciones parecidas que podría hacer con otras señales de seguridad binaria, como señales Lightweight Third Party Authentication (LTPA) y Secure Conversation.

Generador de señales

Una vez creada la señal Kerberos desde el centro de distribución de claves (KDC), el generador de seguridad de servicios web codifica e inserta la señal en el mensaje SOAP y la propaga para su aceptación o consumo. Si es necesaria la integridad de mensajes o clave de confidencialidad, se utiliza una subclave de Kerberos o una clave de sesión de Kerberos desde un ticket de Kerberos. Una clave se puede derivar de la subclave de Kerberos o de la clave de sesión de Kerberos. Web Services Security utiliza la clave desde la señal Kerberos para firmar y cifrar las partes del mensaje según se describe en la especificación OASIS Web Services Security Kerberos Token Profile versión 1.1. El tipo de clave a utilizar está predeterminado por la política o configuración de Web Services Security. Además, el tamaño de la clave derivada es configurable.

El valor de la clave de firma o de cifrado se construye a partir del valor de una de las claves siguientes:
  • La subclave Kerberos cuando se presenta en el autenticador
  • Una clave de sesión directamente a partir del ticket si falta la subclave
  • Una clave que está derivada de alguna de las claves previas
Cuando se hace referencia a la señal de Kerberos como una clave de signatura, el algoritmo de signatura debe ser un código de autenticación de mensajes oculto, que es http://www.w3.org/2000/09/xmldsig#hmac-sha1. Cuando se hace referencia a la señal Kerberos como una clave de cifrado, debe utilizar uno de los algoritmos de cifrado simétricos siguientes:
  • http://www.w3.org/2001/04/xmlenc#aes128-cbc
  • http://www.w3.org/2001/04/xmlenc#aes256-cbc
  • http://www.w3.org/2001/04/xmlenc#tripledes-cbc
Atención:
  • El servidor de aplicaciones sólo tiene soporte para la versión 5 de Kerberos.
  • Puede utilizar la suite del algoritmo simétrico de tipo AES en la seguridad de servicios web cuando el ticket de Kerberos cumple sólo con la RFC-4120.
  • Una clave de Kerberos con el tipo de clave de 128 bits RC4-HMAC sólo se utiliza cuando el KDC está en un servidor Microsoft Windows 2003.
  • Una clave Kerberos con tipos de clave de 128 y 256 bits AES se utiliza cuando el KDC está en un servidor Microsoft Windows 2008.
  • Un ticket de Kerberos debe ser reenviable y no contener una dirección cuando el proveedor de servicios esté en ejecución en un clúster.
  • Debe importar una política de seguridad de Java™ cuando utilice un algoritmo de cifrado de 256 bits AES.

Para obtener información sobre la utilización de una señal de Kerberos en un entorno de reino cruzado o de confianza, lea el tema "Seguridad de las señales de Kerberos en un entorno de reino individual, cruzado o de confianza".

Consumidor de señales

El consumidor de Web Services Security recibe y extrae la señal Kerberos del mensaje SOAP. A continuación, el consumidor aceptará la señal de Kerberos mediante la validación de la señal con su propia clave secreta. La clave secreta del servicio se almacena en un archivo de tabla de claves exportado. Tras su aceptación, el consumidor de Web Services Security almacena la información de la señal de solicitud asociada en el asunto de contexto. También puede derivar la clave correspondiente a la señal de petición. La clave se utiliza para verificar y descifrar el mensaje. Si la señal de petición es reenviable, y no contiene una dirección, el servidor de aplicaciones puede utilizar la señal almacenada para llamadas en sentido descendente.

Formato y referencia de señal

Para aplicaciones JAX-WS, utilice los scripts de mandato administrativo o conjuntos de políticas personalizadas existentes para que la política personalizada especifique el tipo de señal de Kerberos, el firmado de mensaje y el cifrado de mensaje. El modelo de programación JAX-WS para WebSphere Application Server proporciona una configuración mínima para habilitar el perfil de señal de Kerberos con la señal de Kerberos.

Para aplicaciones JAX-RPC, utilice el descriptor de despliegue para especificar que la señal personalizada utilice la señal de Kerberos. Puede utilizar la señal Kerberos para autenticación, pero no la puede utilizar para la firma y cifrado de mensajes.

WebSphere Application Server tiene soporte para las siguientes clases del manejador de retorno de llamada para señales de Kerberos de la versión 5:
  • com.ibm.websphere.wssecurity.callbackhandler.KRBTokenConsumeCallbackHandler

    Esta clase es un manejador de retorno de llamada para la señal Kerberos versión 5 en el lado del consumidor. Esta instancia se utiliza para generar objetos WSSVerification y WSSDecryption para validar una señal de seguridad binaria de Kerberos.

  • com.ibm.websphere.wssecurity.callbackhandler.KRBTokenGenerateCallbackHandler

    Esta clase es un manejador de retorno de llamada para la señal Kerberos versión 5 en el lado del generador. Esta instancia se utiliza para generar los objetos WSSSignature y WSSEncryption para generar una señal de seguridad binaria Kerberos.

La especificación de OASIS Web Services Security Kerberos Token Profile Versión 1.1 indica que la señal Kerberos se conecta al mensaje SOAP con el elemento <wsse:BinarySecurityToken>. El ejemplo siguiente muestra el formato del mensaje. El tipo en negrita muestra la información de señal de seguridad binaria desde las otras partes del ejemplo.

<S11:Envelope xmlns:S11="…" xmlns:wsu="…">
   <S11:Header>
      <wsse:Security xmlns:wsse="…">
          <wsse:BinarySecurityToken 
              EncodingType="http://docs.oasis-open.org/wss/2004/01/
                 oasis-200401-wss-soap-message-security-1.0#Base64Binary" 
              ValueType="http://docs.oasis-open.org/wss/
                 oasis-wss-kerberos-token-profile-1.1#Kerberosv5_AP_REQ" 
              wsu:Id="MyToken">boIBxDCCAcCgAwIBBaEDAgEOogcD…
          </wsse:BinarySecurityToken>
          …
      </wsse:Security>
    </S11:Header>
    <S11:Body>
        …
    </S11:Body>
</S11:Envelope>

El elemento <wsse:SecurityTokenReference> hace referencia a la señal Kerberos. El elemento <wsu:Id>, que se especifica dentro del elemento <wsse:BinarySecurityToken> y se muestra dentro del ejemplo siguiente en negrita, hace referencia directa a la señal en el elemento <wsse:SecurityTokenReference>.

El valor de atributo @wsse:TokenType en el elemento <wsse:SecurityTokenReference> coincide con el valor de atributo ValueType del elemento <wsse:BinarySecurityToken>. El atributo Reference/@ValueType no es necesario. No obstante, si se especifica el atributo, su valor debe ser equivalente al atributo @wsse11:TokenType.

El ejemplo siguiente muestra el formato de mensaje, la correlación entre los elementos <wsu:Id> y <wsse:SecurityTokenReference> y las relaciones entre los valores de atributo @wsse:TokenType y ValueType.
<S11:Envelope xmlns:S11="…" xmlns:wsu="…">
   <S11:Header>
      <wsse:Security xmlns:wsse="…">
          <wsse:BinarySecurityToken 
               EncodingType="http://docs.oasis-open.org/wss/2004/01/
                    oasis-200401-wss-soap-message-security-1.0#Base64Binary" 
               ValueType="http://docs.oasis-open.org/wss/
                    oasis-wss-kerberos-token-profile-1.1#Kerberosv5_AP_REQ" 
               wsu:Id="MyToken">boIBxDCCAcCgAwIBBaEDAgEOogcD…
          </wsse:BinarySecurityToken>
          </wsse:Security>
   </S11:Header>
</S11:Envelope>
      <wsse:Security>
       </wsse:Security>
          <wsse:SecurityTokenReference 
               TokenType="http://docs.oasis-open.org/wss/
                    oasis-wss-kerberos-token-profile-1.1#Kerberosv5_AP_REQ">
               <wsse:Reference URI="#MyToken" 
                    ValueType="http://docs.oasis-open.org/wss/
                        oasis-wss-kerberos-token-profile-1.1#Kerberosv5_AP_REQ">
              </wsse:Reference>
          </wsse:SecurityTokenReference>
         …
      <wsse:Security>
      </wsse:Security>
    <S11:Header>
    </S11:Header>
    <S11:Body>
        …
    </S11:Body>
 <S11:Envelope>
 </S11:Envelope>

Se utiliza el elemento <wsse:KeyIdentifier> para especificar un identificador para la señal Kerberos. El valor del identificador es un valor de hash SHA1 de la señal Kerberos codificada en el mensaje anterior. El elemento debe tener un atributo ValueType con un valor #Kerberosv5APREQSHA1. El mecanismo de referencia KeyIdentifier se utiliza en intercambios posteriores de mensajes una vez que se acepta la señal inicial de Kerberos. El ejemplo siguiente muestra la información del identificador de clave resaltada:

<S11:Envelope xmlns:S11="…" xmlns:wsse="…" xmlns:wsu="…">
    <S11:Header>
      <wsse:Security>
         …
         <wsse:SecurityTokenReference 
               wsse11:TokenType=http://docs.oasis-open.org/wss/
                   oasis-wss-kerberos-token-profile-1.1#Kerberosv5_AP_REQ>
               <wsse:KeyIdentifier 
                   ValueType="http://docs.oasis-open.org/wss/
                       oasis-wss-kerberos-token-profile-1.1#Kerberosv5APREQSHA1">
                       GbsDt+WmD9XlnUUWbY/nhBveW8I= 
               </wsse:KeyIdentifier>
          </wsse:SecurityTokenReference>
          …
      </wsse:Security>
   </S11:Header>
   <S11:Body>
       …
    </S11:Body>
</S11:Envelope>

Referencias múltiples a la señal Kerberos

El cliente no necesita enviar una señal Kerberos en todas las peticiones una vez que la identidad Kerberos está validada y aceptada por el servicio. La especificación OASIS Web Services Security Kerberos Token Profile versión 1.1 sugiere el uso de una clave SHA1 codificada con el elemento <wsse:KeyIdentifier> dentro del elemento <wsse:SecurityTokenReference> por cada mensaje subsecuente tras la aceptación del paquete AP_REQ inicial. No obstante, el entorno de ejecución de Web Services Security debe correlacionar el identificador de clave con una señal Kerberos en memoria caché para continuar el proceso. IBM® WebSphere Application Server 7.0 y posterior tiene soporte para este almacenamiento en caché de SHA1, según se describe en el perfil, por omisión. No obstante, el servidor de aplicaciones también proporciona la posibilidad de generar nuevas señales AP_REQ por cada solicitud con el ticket de Kerberos de servicio existente. Cuando interactúe con Microsoft .NET, no utilice almacenamiento en caché pSHA1; genere un paquete AP_REQ por cada petición.


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=cwbs_kerberosusageoverview
File name: cwbs_kerberosusageoverview.html