Bases de datos en castellano. BEA WebLogic: Guía de Administración bases de datos mysql oracle sqlite access mssql

La implementación de la Seguridad en un Servidor WebLogic ampliamente desplegado consiste en campos de configuración que definen la política de seguridad para ese despliegue. El Servidor WebLogic proporciona una Consola de Administración para ayudarnos a definir la política de seguridad. Usando la consola, especificamos valores especificos de seguridad para los siguientes elementos de nuestro servidor:

Reinos

Usuarios y Grupos

Listas de Control de Acceso (ACLs) y permisos para recursos del Servidor WebLogic

Protocolo SSL

autentificación mutua

Auditoria de proveedores

Filtros Personalizados

Propagación del contexto de seguridad

Como las características de seguridad están muy relacionadas, es dificil determinar dónde empezar cuando se configura la seguridad. De hecho, definir la seguridad para nuestro despliegue de Servidor WebLogic podría ser un proceso iterativo. Aunque más de una secuencia de pasos podría funcionar, recomendamos el siguiente procedimiento:

Cambiar la password del sistema para proteger nuestro Servidor WebLogic.

Especificar un reino de seguridad. Por defecto, el Servidor WebLogic está instalado con el reino File. Sin embargo, podríamos preferir un reino de seguridad alternatio o un reino de seguridad personalizado.

Definir usuarios para el reino de seguridad. Podemos organizar posteriormente los usuarios implementando grupos en el reino de seguridad.

Definir ACLs y permisos para los recursos de nuestro Servidor WebLogic.

Proteger la conexión de red entre los clientes y el Servidor WebLogic usando el protocolo SSL. Cuando se implementa SSL, el Servidor WebLogic usa su certificado digital, enviado por una autoridad de certificación creible, para autentificar la os clientes. Este paso es opcional pero lo recomendamos.

Mejorar la protección de nuestro Servidor WebLogic implementando autentificación mutua. Cuando ésta se implementa, el propio Servidor WebLogic debe autentificarse ante el cliente y luego el cliente se debe autentificar ante el Servidor WebLogic. De nuevo este paso es opcional, pero los recomendamos.

Esta sección describe estos pasos de configuración y los campos que configuramos en la Consola de Administración.

Configurar el Controlador de Seguridad Java

Cuando ejecutamos WebLogic Server bajo Java 2 (JDK 1.3), WebLogic Server usa el "Java Security Manager" para controlar los recursos del Servidor WebLogic. El controlador de seguridad Java necesita incluir un fichero de política de seguridad para configurar los permisos. La distribución de WebLogic Server incluye un fichero de política de seguridad llamado weblogic.policy que contiene un conjunto de permisos por defecto. Con este fichero, podemos arrancar WebLogic Server sin crear primero nuestro propio fichero de política de seguridad.

Editar las siguientes líneas en el fichero weblogic.policy, reemplazamos la localización del directorio en que instalamos WebLogic Server.

grant codebase file:./c:/weblogic/-{
permission java.io.FilePermission c:${/}weblogic${/}-,...

Una vez realizados estos pasos, recomendamos realizar los siguientes pasos:

Hacer una copia de seguridad del fichero weblogic.policy y ponerla en un sitio seguro.

Seleccionar los permisos sobre las protecciones del fichero weblogic.policy para que sólo el administrador del sistema donde está desplegado el Servidor WebLogic tenga privilegios de lectura y escritura.

Configuramos las propiedades java.security.manager y java.security.policy en la línea de comandos Java cuando arrancamos WebLogic Server. Estas propiedades realizan las siguientes funciones:

La propiedad java.security.manager especifica que la Máquina Virtual Java (JVM) usará una política de seguridad. No necesitamos especificar ningún argumento para esta propiedad.

La propiedad java.security.policy especifica la localización del fichero de política de seguridad a utilizar por la JVM. El argumento de esta propiedad es el nombre totalmente cualificado del fichero weblogic.policy. Por ejemplo:
```
$ java ... -Djava.security.manager\
-Djava.security.policy==c:/weblogic/weblogic.policy
```

Cambiar la Password del Sistema

Durante la instalación especificamos una password para el usuario system. La password especificada se asocia con el usuario system en el Servidor WebLogic y es almacenada en el fichero fileRealm.properties en el directorio \wlserver6.0\config\mydomain.

La password especificada corresponde al Servidor de Administración para el dominio y para todos los servidores controlados asociado con ese Servidor de Administración.

La password está encriptada y además se protege cuando el Servidor WebLogic le aplica un poco de basura. Para mejorar la seguridad, recomendamos cambiarla frecuentemente.

Para cambiar la password de system, hacemos lo siguiente:

Abrimos la ventana Users en la Consola de Administración.

Introducimos system en el campo User.

Introducimos una nueva password en el campo Password.

Confirmamos la password.

Cuando usamos un Servidor de Administración y servidores controlados en un dominio, los servidores controlados siempre deben usar la password del Servidor de Administración del dominio. Siempre debemos cambiar la password desde la Consola de Administración, ya que así, la nueva password será propagada a todos los servidores controlados del dominio. Recuerda que la password de system debe ser la misma para todos los servidores de un dominio.

Nota:
Los dominios Petstore y ExampleServer todavía almacenan la password de system en un fichero password.ini. Cuando usemos estos dominios, debemos modificar la password de system modificando la información de la password en ese fichero.

Especificar un Reino de Seguridad

Por defecto el Servidor WebLogic se instala con un reino de seguridad File. Antes de usar el reino File, necesitamos defiir varios campos que gobiernan el uso de este reino. Podemos configurar estos campos en la pestaña Filerealm de la ventana Security de la Consola de Administración.

La siguiente tabla describe cada campo de la pestaña Filerealm:

Campo	Descripción
`Max Users`	Especifica el número máximo de usuarios a usar con el reino File. Este reino está pensado para usarse con menos de 10000 usuarios. El valor mínimo para este campo es 1 y el máximo es 10000. El valor por defecto es 1000.
`Max Groups`	Especifica el número máximo de grupos a usar con el reino File. El valor mínimo para este campo es 1 y el máximo es 10000. El valor por defecto es 1000.
`Max ACLs`	Especifica el número máximo de ACLs a usar con el reino File. El valor mínimo para este campo es 1 y el máximo es 10000. El valor por defecto es 1000.

Si por alguna razón se corrompe o destruye el fichero fileRealm.properties, deberemos reconfigurar toda la información de seguridad del Servidor WebLogic. Por lo tanto, recomendamos seguir los siguientes pasos:

Hacer una copia de seguridad del fichero fileRealm.properties y ponerla en un sitio seguro.

Seleccionar los permisos de protección del fichero fileRealm.properties para que sólo el administrador del Servidor WebLogic tenga privilegios de lectura y escritura y que ningún otro usuario tenga privilegios.

Nota:
También deberíamos hacer una copia de seguridad del fichero SerializedSystemIni.dat para el reino File. Para más información sobre el fichero SerializedSystemIni.dat, puedes ir a la sección Proteger Passwords.

Si en lugar del reino File, queremos usar uno de los reinos de seguridad alternativos proporcionados por el Servidor WebLogic o un reino de seguridad personalizado, configuramos los campos del reino deseado y reinciamos el Servidor WebLogic.

Configurar el Reino Caching

Nota:
Todas las instrucciones de configuración están basadas en el uso de la Consola de Administración.

El reino Caching trabaja con el reino File, reinos de seguridad alternativos o reinos personalizados para satisfacer las peticiones de los clientes con la autentificación y autorización apropiadas. El reino Caching almacena los resultados tanto con éxito como sin éxito de las búsquedas del reino. Maneja cachés separados para Usuarios, Grupos, permisos, ACLs y peticiones de autentificación. El reino Caching Mejora el rendimiento del Servidor WebLogic cacheando las búsquedas, reduciendo el número de llamadas a otros reinos de seguridad.

El reino Caching se instala automáticamene cuando instalamos el Servidor WebLogic: el caché se configura para delegar a otros reinos de seguridad pero no está activado. Tenemos que activar el caché desde la Consola de Administración.

Cuando activamos el caché, el reino Caching graba los resultados de una búsqueda de reino en su caché. Los resultados de la búsqueda permanecen en el cache durante el número de segundos especificados definidos por los campos time-to-live (TTL) o el caché se ha llenado. Cuando el caché se llena, los nuevos resultados de búsquedas reemplazan a los resultados más antiguos. Los campos TTL determinan el tiempo que un objeto del caché es válido. Cuando más alto seleccionemos estos campos, con menos frecuencia el reino Caching llamará al reino de seguridad secundario. Al reducir la frecuencia de esas llamadas se mejora el rendimiento. La pega es que los cambios en el reino de seguridad subyacente no se reconocen hasta que el objeto del caché haya expirado.

Nota:
Cuando obtenemos un objeto desde un reino de seguridad, el objeto refleja una "foto" de objeto. Para actualizar el objeto, debemos llamar de nuevo al método get() del objeto. Por ejemplo, los miembros de un grupo se seleccionan cuando el grupo es recuperado del reino de seguridad con una llamada al método getgroup(). Para actualizar los miembros del grupo, debemos llamar de nuevo al método getgroup().

Por defecto, el reino Caching opera sobre la asumpción de que el reino secundario es sensible a las mayúsculas. En el caso de un reino de seguridad sensible a las mayúsculas, los propietarios de los nombres de usuario bill y Bill, por ejemplo, son tratados como usuarios distintos. Los reinos de seguridad Windows NT y LDAP son ejemplos de reinos de seguridad insensibles a las mayúsculas. Si estámos usando un reino de seguridad que no es sensible a las mayúsculas, debemos desactivar el campo CacheCaseSensitive. Cuando se selecciona este campo, el reino Caching convierte los nombres de usuarios a minúsculas para que el Servidor WebLogic ofrezca los resultados correctos cuando realiza comparaciones sensibles a las mayúsculas. Cuando definimos o referenciamos Usuarios o Grupos en un reino de seguridad sensible a las mayúsculas, debemos teclearlos en minúsculas.

Configurar el reino Caching implica activar varios tipos de cachés (como ACL, Authentication, Group, y Permission) y definir cómo opera cada uno de ellos. Para hacer estas tareas, definimos valores para los campos mostrados en la pestaña General de la ventana Caching Realm Configuration. Para grabar nuestros cambios, pulsamos sobre el botón Apply. Cuando hayamos finalizado de definir los campos, reiniciamos el Servidor WebLogic. La siguiente tabla describe cada uno de los campos de la pestaña General:

Campo	Descripción
Name	Muestra el reino de seguridad activo. Este campo no se puede cambiar.
Basic Realm	El nombre de la clase para el reino de seguridad alternativo o el reino de seguridad personalizado que está siendo usado con el reino Caching.
Case Sensitive Cache	Define si el reino de seguridad especificado es sensible a las mayúsculas. Por defecto, este campo está activado: el reino es sensible a las mayúsculas. Para usar un reino que lo sea (como los reinos Windows NT y LDAP), debemos desactivar este campo.

Para activar y configurar el caché ACL, definimos valores para los campos mostrados en la pestaña ACL de la ventana Caching Realm Configuration. Para grabar nuestros cambios, pulsamos sobre el botón Apply. Cuando hayamos finalizado de definir los campos, reiniciamos el Servidor WebLogic. La siguiente tabla describe cada uno de los campos de la pestaña ACL:

Campo	Descripción
Enable ACL Cache	Opción para activar el caché ACL
ACL Cache Size	El número máximo de búsquedas ACL a almacenar. El valor por defecto es 211. Este campo debería ser un número primo para un mejor rendimiento de las búsquedas.
ACL Cache Positive TTL	El número de segundos para retener los resultados de una búsqueda existosa.
ACL Cache Negative TTL	El número de segundos para retener los resultados de una búsqueda sin éxito. El valor por defecto es 10 segundos.

Para activar y configurar el caché Authentication, definimos valores para los campos mostrados en la pestaña Authentication de la ventana Caching Realm Configuration. Para grabar nuestros cambios, pulsamos sobre el botón Apply. Cuando hayamos finalizado de definir los campos, reiniciamos el Servidor WebLogic. La siguiente tabla describe cada uno de los campos de la pestaña Authentication:

Campo	Descripción
Enable Authentication Cache	Opción para activar el caché Authentication.
Authentication Cache Size	El número máximo de peticiones `Authenticate` a almacenar en el caché. El valor por defecto es 211. Este campo debería ser un número primo para un mejor rendimiento de la búsqueda.
Authentication Cache TTLPositive	El número de segundos para retener los resultados de una búsqueda existosa.
Authentication Cache TTLNegative	El número de segundos para retener los resultados de una búsqueda sin éxito. El valor por defecto es 10 segundos.

Para activar y configurar el caché Group, definimos valores para los campos mostrados en la pestaña Group de la ventana Caching Realm Configuration. Para grabar nuestros cambios, pulsamos sobre el botón Apply. Cuando hayamos finalizado de definir los campos, reiniciamos el Servidor WebLogic. La siguiente tabla describe cada uno de los campos de la pestaña Group:

Campo	Descripción
Group Cache Enable	Opción para activar el caché Group.
Group Cache Size	El número máximo de búsquedas de `Group` a almacenar en el caché. El valor por defecto es 211. Este campo debería ser un número primo para un mejor rendimiento de la búsqueda.
Group Cache TTLPositive	El número de segundos para retener los resultados de una búsqueda existosa. El valor por defecto es 60 segundos.
Group Cache TTLNegative	El número de segundos para retener los resultados de una búsqueda sin éxito. El valor por defecto es 10 segundos.
Group Membership Cache TTL	El número de segundos a almacenar los miembros de un grupo antes de actualizarlo. El valor por defecto es 10 segundos.

Para activar y configurar el caché User, definimos valores para los campos mostrados en la pestaña User de la ventana Caching Realm Configuration. Para grabar nuestros cambios, pulsamos sobre el botón Apply. Cuando hayamos finalizado de definir los campos, reiniciamos el Servidor WebLogic. La siguiente tabla describe cada uno de los campos de la pestaña User:

Campo	Descripción
Enable User Cache	Opción para activar el caché User.
User Cache Size	El número máximo de búsquedas de `User` a almacenar en el caché. El valor por defecto es 211. Este campo debería ser un número primo para un mejor rendimiento de la búsqueda.
User Cache TTLPositive	El número de segundos para retener los resultados de una búsqueda existosa. El valor por defecto es 60 segundos.
User Cache TTLNegative	El número de segundos para retener los resultados de una búsqueda sin éxito. El valor por defecto es 10 segundos.

Para activar y configurar el caché Permission, definimos valores para los campos mostrados en la pestaña Permission de la ventana Caching Realm Configuration. Para grabar nuestros cambios, pulsamos sobre el botón Apply. Cuando hayamos finalizado de definir los campos, reiniciamos el Servidor WebLogic. La siguiente tabla describe cada uno de los campos de la pestaña Permission:

Campo	Descripción
Enable Permission Cache	Opción para activar el caché Permission.
Permission Cache Size	El número máximo de búsquedas de `Permission` a almacenar en el caché. El valor por defecto es 211. Este campo debería ser un número primo para un mejor rendimiento de la búsqueda.
Permission Cache TTLPositive	El número de segundos para retener los resultados de una búsqueda existosa. El valor por defecto es 60 segundos.
Permission Cache TTLNegative	El número de segundos para retener los resultados de una búsqueda sin éxito. El valor por defecto es 10 segundos.

Configurar el Reino LDAP

Nota:
El reino de seguridad LDAP ha sido reescrito para mejorar el rendimiendo y la configurabilidad. BEA recomienda actualizar nuestra instalación WebLogic Server 6.0 al Service Pack 1.0 para aprovechar esta funcionalidad. El WebLogic Server 6.0 Service Pack 1.0 está disponible para descarga en la página de BEA Systems.

El reino de seguridad LDAP proporciona autentificación a través de un servidor Lightweight Directory Access Protocol (LDAP). Este servidor nos permite manejar todos los usuarios de nuestra organización en un sólo lugar, el directorio LDAP. El reino de seguridad LDAP actualmente soporta Netscape Directory Server, Microsoft Site Server, y Novell NDS.

Configurar el reino de seguridad LDAP implica definir campos que permitan al reino de seguridad LDAP en el Servidor WebLogic comunicarse con el servidor LDAP y campos que describan cómo se almacenan los usuarios y grupos en el directorio LDAP.

Antes de poder usar el reino de seguridad LDAP, necesitamos activar el reino Caching e introducir el nombre de la clase del reino de seguridad LDAP en el campo Basic Realm.

Para usar el reino de seguridad LDAP en lugar del reino File, vamos al nodo Security --> Realms en el panel izquierdo de la Consola de Administración. En el panel derecho, pulsamos el enlace Create a New LDAP Realm.

Para especificar el nombe del reino de seguridad LDAP y el nombre de la clase que contiene ese reino de seguridad definimos los valores de los campos mostrados en la pestaña General de la ventana LDAP Realm Create. Para grabar nuestros cambios, pulsamos el botón Apply. Cuando hayamos terminado de definir los campos, reiniciamos el Servidor WebLogic. La siguiente tabla describe todos los campos de la pestaña General:

Campo	Descripción
Name	El nombre del reino de seguridad LDAP como `AccountingRealm`.
Realm Class Name	El nombre de la clase Java que contiene el reino de seguridad LDAP. La clase Java debería estar incluida en el CLASSPATH del Servidor WebLogic.

Para permitir la comunicación entre el servidor LDAP y el Servidor WebLogic definimos valores para los campos mostrados en la pestaña LDAP en la ventana LDAP Realm Create. Para grabar nuestros cambios, pulsamos el botón Apply. Cuando hayamos terminado de definir los campos, reiniciamos el Servidor WebLogic. La siguiente tabla describe todos los campos de la pestaña LDAP:

Campo	Descripción
LDAPURL	La localización del servidor LDAP. Cambiamos la URL al nombre del ordenador en el que se esté ejecutando el servidor LDAP y el número de puerto en el que esté escuchando. Si queremos que el Servidor WebLogic se conecte al servidor LDAP usando el protocolo SSL, usamos el número de puerto SSL del servidor LDAP en la URL.
Principal	El nombre distinguido (DN) del Usuario LDAP usado por el Servidor WebLogic para conectarse con el servidor LDAP. Este usuario debe poder listar Usuarios y Grupos LDAP.
Credential	La password que autentifica al usuario LDAP, según se define en el campo `Principal`.
Enable SSL	Opción para activar el uso del protocolo SSL para proteger las comunicaciones entre el Servidor LDAP y el Servidor WebLogic. Debemos tener en mente los siguientes puntos: Desactivar este campo si el servidor LDAP no está configurado para usar el protocolo SSL. Si seleccionamos el campo `UserAuthentication` a external, este campo debe estár activado.
AuthProtocol	El tipo de autentificación usada para autentificar el servidor LDAP. Seleccionamos este campo con uno de los siguientes valores: `None` para no usar auntenticación. `Simple` para autentificación por password. `CRAM-MD5` para autentificación certificada. Netscape Directory Server soporta CRAM-MD5. Microsoft Site Server y Novell NDS soportan autentificación Simple.

Para especificar cómo se almacenan los usuarios en el directorio LDAP definimos los campos mostrados en le pestaña Users en la ventana LDAP Realm Create. Para grabar nuestros cambios, pulsamos el botón Apply. Cuando hayamos terminado de definir los campos, reiniciamos el Servidor WebLogic. La siguiente tabla describe todos los campos de la pestaña Users:

Campo	Descripción
User Authentication	Determina el método para autentificar usuarios. Seleccionamos este campo a uno de los siguientes valores: `Local` especifica que el reino de seguridad LDAP recupera datos de usuario, incluyendo la password desde el servidor de directorio LDAP, y chequea las password en el Servidor WebLogic. Esta selección es apropiada para Netscape Directory Server y Microsoft Site Server. `External` especifica que el reino de seguridad LDAP autentifica un usuario intentando unir el servidor de directorio LDAP con el nombre de usuario y la password suministrados por el cliente del Servidor WebLogic. Si elegimos esta selección, también debemos usar el protocolo SSL. Esta selección es apropiada para Novell NDS. Bind
User Password Attribute	La passwrod del usuario LDAP.
User DN	Una lista de atributos que, cuando se combinan con los atributos del campo User Name Attribute, identifican únicamente a un usuario LDAP.
User Name Attribute	El nombre de login del usuario LDAP. El valor de este campo puede ser el nombre común de un usuario LDAP pero normalmente es un string abreviado, como el ID de usuario.

Para especificar cómo se almacenan los Grupos en el directorio LDAP, asignamos valores a los campos mostrados en la pestaña Groups en la ventana LDAP Realm Create. Para grabar nuestros cambios, pulsamos el botón Apply. Cuando hayamos terminado de definir los campos, reiniciamos el Servidor WebLogic. La siguiente tabla describe todos los campos de la pestaña Groups:

Campo	Descripción
Group DN	La lista de atributos que, combinada con el campo Group Name Attribute, identica únicamente a un grupo en el directorio LDAP.
Group Name Attribute	El nombre de un Grupo en el directorio LDAP. Normalmente es un nombre común.
Group Is Context	Este checkbox booleano especifica cómo se graban los miembros del Grupo en el directorio LDAP: Marcamos este checkbox si cada entrada del Grupo contiene un usuario. Por defecto, este campo está activado. Desmarcamos este checkbox si hay una entrada Grupo que contiene un atributo por cada miembro del grupo.
Group Username Attribute	El nombre del atributo LDAP que contiene un miembro del Grupo en una entrada de Grupo.

Si hemos activado el caché, el reino Caching almacena los Usuarios y los Grupos internamente para evitar las búsquedas frecuentes en el directorio LDAP. Todo objeto en el caché de Usuarios y Grupos tiene un campo TTL que puede configurarse en el reino Caching. Si hacemos cambios en el directorio LDAP, dichos cambios no se verán reflejados en el reino de seguridad LDAP hasta que expiren los objetos almacenados en el caché o sean sacados de él. El TTL por defecto es 60 segundos para búsquedas sin éxito y 10 segundos para búsquedas con éxito. A menos que cambiemos los campos TTL para los cachés de Usuarios y Grupos, los cambios en el directorio LDAP deberían verse reflejados en el reino de seguridad LDAP en 60 segundos.

Su algún código del lado del servido ha realizado alguna búsqueda en el reino de seguridad LDAP, como una llamada a getUser() sobre el reino de seguridad LDAP, el objeto devuelto por el reino no puede liberarse hasta que el código lo libere. Por lo tanto, un Usuario autentificado por el Servidor WebLogic permanece válido mientras que persista la conexión. incluso si borramos al usuario del directorio LDAP.

Configurar un Reino de Seguridad de Windows NT

El reino de seguridad de Windows NT usa información de cuenta definida en un dominio Windows NT para autentificar Usuarios y Grupos. Podemos ver los Usuarios y Grupos en el reino de seguridad Windows NT a través d ela Consola de Administración, pero debemos manejar los Usuarios y Grupos a través de las facilidades proporcionadas por Windows NT.

El reino de seguridad de Windows NT proporciona autentificación (Usuarios y Grupos) pero no autorización (ACLs). El usuario system definido en el Servidor WebLogic también debe ser declarado en el dominio Windows NT. Sobre una plataforma Windows NT, el Servidor WebLogic se debe ejecutar bajo la cuenta de usuario system, y los clientes deben suministrar la password del usuario system para autentificarse satisfactoriamente. Cuando definamos la cuenta system en Windows NT, nos debemos asegurar de que el propietario de la cuenta tiene permisos administrativos y que puede leer información relacionada con la seguridad desde el controlador del domino Windows NT.

Para usar el reino de seguridad Windows NT, debemos ejecutar el Servidor WebLogic como un servicio Windows NT sobre un ordenador del dominio Windows NT. No tenemos porque ejecutar el Servidor WebLogic sobre un controlador de dominio.

Como el Servidor WebLogic lee ACLs desde el fichero fileRealm.properties durante la arrancada, debemos reiniciar el Servidor WebLogic después de cambiar un ACL. Si usamos Grupos con ACLs, podemos reducir la frecuencia con la que deberemos reiniciar el Servidor WebLogic. Cambiar los miembros de un Grupo Windows NT nos permite manejar dinámicamente los accesos de Usuarios individuales a los recursos del Servidor WebLogic.

Antes de poder usar el reino de seguridad Windows NT, necesitamos activar el reino Caching e introducir el nombre de la clase del Reino de seguridad de Windows NT en el campo Basic Realm.

Para usar el reino de seguridad de Windows NT en vez de usar el reino File, vamos al nodo Security -> Realms en el panel izquierdo de la Consola de Administración. En el panel derecho pulsamos sobre el enlace Create a New NT Realm.

Configurar el reino de Seguridad de Windows NT implica configurar campos que definen un nombre para el reino y el ordenador sobre el que se está ejecutando el dominio Windows NT. Para especificar un nombre de reino, debemos definir valores para los campos mostrados en la ventana NT Realm Create de la Consola de Administración. Para grabar nuestros cambios, pulsamos el botón Apply. Cuando hayamos terminado de definir los campos, reiniciamos el Servidor WebLogic. La siguiente tabla describe todos los campos de la ventana NT Realm Configuration::

Campo	Descripción
Name	El nombre del reino de Seguridad Windows NT, como, `AccountingRealm`.
Realm Class Name	El nombre de la clase Java que implementa el reino de seguridad Windows NT. La clase Java necesita estar en el CLASSPATH del Servidor WebLogic.
Primary Domain	El host y número de puerto del ordenador donde están definidos los Usuarios y Grupos para el dominio Windows NT. Si introducimos varios host y números de puertos, debemos usar una lista separada por comas.

Una vez que tengamos configurado el reino de seguridad Windows NT en la Consola de Administración. necesitamos definir el usuario system en Windows NT:

Usamos la cuenta Administrator para entrar en el dominio Windows NT que estámos usando con el Servidor WebLogic.

Vamos a Programs -> Administrative Tools.

Seleccionamos User Manager.

Definimos el usuario system.

Marcamos la opción Show Advanced User Rights.

Seleccionamos el Act como parte de la opción de sistema operativo desde el menú desplegable Rights.

Pulsamos el botón Add.

Nos aseguramos de la variable de entorno PATH de Windows NT incluye el directorio \wlserver6.0\bin. (WebLogic Server carga la librería W1ntrealm.dll desde este directorio.)

Configurar un Reino de Seguridad UNIX

El reino de seguridad UNIX es un pequeño programa nativo, wlauth, para buscar Usuarios y Grupos y para autentificar Usuarios sobre las bases de nombres de login UNIX y sus passwords. Sobre algunas plataformas, wlauth usa PAM (Pluggable Authentication Modules) que nos permite configurar los servicios de autentificación en el sistema operativo sin alterar las aplicaciones que usan el servicio. Sobre plataformas para las que PAM no está disponible, wlauth usa un mecanismo de login estándard, que incluye passwords sombreadas, cuando son soportadas.

Como WebLogic Server lee ACLs desde el fichero fileRealm.properties durante la arrancada, debemos reiniciar el Servidor WebLogic después de cambiar un ACL. Si usamos Grupos con ACLs, podemos reducir la frecuencia con la que deberemos reiniciar el Servidor WebLogic. Cambiar los miembros de un Grupo UNIX nos permite manejar dinámicamente los accesos de Usuarios individuales a los recursos del Servidor WebLogic.

El programa wlauth ejecuta setuid root. Necesitamos permisos de root para modificar los atributos del fichero del programa wlauth y seleccionar el fichero de configuración de PAM para wlauth.

Realizamos los siguientes pasos para configurar el reino de seguridad UNIX:

Si el Servidor WebLogic está instalado en un disco de red, copiamos el fichero wlauth a un sistema de ficheros en el ordenador que ejecute el Servidor WebLogic, por ejemplo, el directorio /usr/sbin. El fichero wlauth está en el directorio weblogic/lib/arch, donde arch es el nombre de nuestra plataforma.

Como usuario root, ejecutamos los siguientes comandos para cambiar al propietario y los permisos del fichero wlauth:
```
# chown root wlauth
# chmod +xs wlauth
```

Sobre plataformas PAM (Solaris y Linux), seleccionamos la configuración PAM para wlauth.

Solaris—Añadimos las siguientes líneas a nuestro fichero /etc/pam.conf:

# Setup for WebLogic authentication on Solaris machines
#
wlauth auth required /usr/lib/security/pam_unix.so.1
wlauth password required /usr/lib/security/pam_unix.so.1
wlauth account required /usr/lib/security/pam_unix.so.1

Linux—Creamos un fichero llamado /etc/pam.d/wlauth que contenga lo siguiente:

#%PAM-1.0
#
# File name:
# /etc/pam.d/wlauth
#
# If you do not use shadow passwords, delete "shadow".
auth required /lib/security/pam_pwdb.so shadow
account required /lib/security/pam_pwdb.so

Para usar el reino de seguridad de UNIX en vez de usar el reino File, vamos al nodo Security -> Realms en el panel izquierdo de la Consola de Administración. En el panel derecho pulsamos sobre el enlace Create a New UNIX Realm.

Antes de poder usar el reino de seguridad UNIX, necesitamos activar el reino Caching e introducir el nombre de la clase del reino de seguridad UNIX en el campo Basic Realm.

Configurar el reino de Seguridad de UNIX implica configurar campos que definen un nombre para el reino y el ordenador sobre el que se está ejecutando el dominio UNIX. Para especificar un nombre de reino, debemos definir valores para los campos mostrados en la ventana UNIX Realm Create de la Consola de Administración. Para grabar nuestros cambios, pulsamos el botón Apply. Cuando hayamos terminado de definir los campos, reiniciamos el Servidor WebLogic. La siguiente tabla describe todos los campos de la ventana UNIX Realm Configuration:

Campo	Descripción
Name	El nombre del reino de Seguridad UNIX, como, `AccountingRealm`.
Realm Class Name	El nombre de la clase Java que implementa el reino de seguridad UNIX. La clase Java necesita estar en el CLASSPATH del Servidor WebLogic.
AuthProgram	El nombre del programa usado para autentificar usuarios en el reino de seguridad UNIX. En la mayoría de los casos, el nombre del programa es wlauth.

Si wlauth no está en el path de clases del Servidor WebLogic o si le hemos dado al programa un nombre distinto a wlauth, debemos añadir una propiedad en la línea de comandos Java cuando iniciemos el Servidor WebLogic. Editamos el script que usamos para arrancar el Servidor WebLogic y añadimos la siguiente opción después del comando java:

-Dweblogic.security.unixrealm.authProgram=wlauth_prog

Reemplazamos wlauth_prog con el nombre del programa wlauth, incluyendo el path completo si no está en el path de búsqueda. Arrancamos el Servidor WebLogic. Si el progama wlauth está en el path del Servidor WebLogic y se llama wlauth, este paso no es necesario.

Configurar un Reino de Seguridad RDBMS

El reino de seguridad RDBMS es un reino de seguridad personalizado proporcionado por BEA que almacena Usuarios, Grupos y ACLs en un base de datos relacional. Este reino puede ser manejada a través de la Consola de Administración.

Para usar el reino de seguridad RDBMS en lugar del reino File, vamos al nodo Security -> Realms en el panel izquierdo de la Consola de Administración. En el panel derecho, pulsamos sobre el enlace Create a New RDBMS Realm.

Antes de poder usar el reino de seguridad RDBMS, necesitamos activar el reino Caching e introducir el nombre de la clase del reino de seguridad RDBMS en el campo Basic Realm.

Configurar el reino de Seguridad RDBMS implica configurar campos que definen el driver JDBC que se va autilizar para conectar con la base de datos y definir el esquema usado para almacenar Usuarios, Grupos y ACLs en la base de datos. Para definir estos campos, debemos definir valores para los campos mostrados en las tres pestañas de la ventana RDBMS Realm Create: la pestaña General, la pestaña Database y la pestaña Schema. La siguiente tabla describe todos los campos de la pestaña General:

Campo	Descripción
Name	El nombre del reino de Seguridad RDBMS, como, `AccountingRealm`.
Realm Class Name	El nombre de la clase WebLogic que implementa el reino de seguridad RDBMS. La clase Java necesita estar en el CLASSPATH del Servidor WebLogic.

La siguiente tabla describe todos los campos de la pestaña Database:

Campo	Descripción
Driver	El nombre completo del driver JDBC. Esta clase debe estar en el CLASSPATH del Servidor WebLogic.
URL	La URL para la base de datos que estámos usando con el reino RDBMS, según lo especifica la documentación de nuestro dirver JDBC.
User Name	El nombre de usuario por defecto para la base de datos.
Password	La password del usuario por defecto de la base de datos.

Las propieades Schema usadas para definir Usuarios, Grupos y ACLs almacenados en la base de datos se listan en la pestaña Schema. Cuando finalicemos de definir los valores para los campos necesarios en cada una de las tres pestañas, grabamos los cambios pulsando el botón Apply. Luego reiniciamos el Servidor WebLogic.

Configurar un Reino de Seguridad Personalizado

Podemos crear un reino de seguridad personalizado que provenga de un almacen existente de usuarios como un servidor de directorios en la red. Para usar un reino de seguridad personalizado, creamos una implementación de los interfaces weblogic.security.acl.AbstractListableRealm o weblogic.security.acl.AbstractManageableRealm y luego usamos la Consola de Administración para instalar nuestra implemetnación.

Para instalar un reino de seguridad personalizado, vamos al nodo Security -> Realms en el panel izquierdo de la Consola de Administración. En el panel derecho, pulsamos sobre el enlace Create a New Custom Realm.

Antes de poder usar el reino de seguridad RDBMS, necesitamos activar el reino Caching e introducir el nombre de la clase del reino de seguridad RDBMS en el campo Basic Realm.

Personalizar un reino de seguridad personalizado implica configurar campos que definen el nombre del reino y el interface que lo implementa, y espeficar información que define cómo se almacenará los Usuarios, los Grupos y los ACLs en el reino de seguridad personalizado. Para definir esta información, debemos definir valores para los campos de la ventana Custom Realm Create de la Consola de Administración. Para grabar nuestros cambios, pulsamos el botón Apply. Cuando hayamos terminado de definir los campos, reiniciamos el Servidor WebLogic. La siguiente tabla describe todos los campos de la ventana Custom Realm Configuration:

Campo	Descripción
Name	El nombre del reino de Seguridad Personalizado, como, `AccountingRealm`.
Realm Class Name	El nombre de la clase WebLogic que implementa el reino de seguridad Personalizado. La clase Java necesita estar en el CLASSPATH del Servidor WebLogic.
Configuration Data	La información necesaria para conectar con el almacen de seguridad.

Probar un Reino de Seguridad Alternativo o Personalizado

Si hemos arrancado WebLogic Server con un reino de seguridad alternativo o personalizado, realizamos los siguientes pasos para asegurarnos de que el reino está funcionando apropiadamente:

Arrancamos la Consola de Administración. La Consola muestra todos los Usuarios, Grupos y ACLs conocidos en el reino de seguridad.

Usamos la Consola de Administración para añadir un ACL para el servlet de ejemplo HelloWorld. Damos acceso a este servlet a un Usuario y a un Grupo de nuestro reino de seguridad. Seleccionamos un Grupo que no incluya el usuario especificado.

Reiniciamos WebLogic Server y cargamos el servlet HelloWorld con un ACL usando la siguiente URL:
```
http://localhost:portnumber/helloWorld
```

Intentamos introducir un nombre de usuario y una passwod para un Usuario que no esté incluido en el ACL que hemos añadido para el Servlet. Deberíamos obtener un mensaje diciendo que no estámos autorizados para hacer eso.

Intentamos introducir el nombre de usuario y la password para el Usuario que incluímos en el ACL, o como un usuario individual o como miembro del Grupo. El servelt se debería cargar y mostrar el mensaje "Hello World".

Migrar Reinos de Seguridad

WebLogic Server 6.0 proporciona una nueva arquitectura de control para reinos de seguridad. La arquitectura implementada a través de MBeans nos permite manejar los reinos de seguridad a través de la Consola de Administración. Si tenemos un reino de seguridad de una versión anterior de WebLogic Server, debemos usar la siguiente información para migrar a la nueva arquitectura:

Si estámos usando los reinos de seguridad Windows NT, UNIX, o LDAP, usamos la opción Convert WebLogic Properties de la Consola de Administración para convertir el reino de seguridad a la nueva arquitectura.. Observaremos que podemos ver los Usuarios, Grupos y ACLs en la Consola de Administración, sin embargo, todavía necesitamos usar las herramientas proporcionadas por los distintos entornos para manejar los Usuarios y Grupos.

Si estámos usando un reino de seguridad personalizado, seguimos los pasos de Instalar un Reino de Seguridad Personalizado para especificar información sobre los Usuarios, Grupos y opcionalmente ACLs que están almacenados en el reino de seguridad.

El reino de seguridad Delegating ya no se soporta en WebLogic Server 6.0. Si lo estámos usando, tendremos que usar otro tipo de reino de seguridad para almacenar Usuarios, Grupos y ACLs.

Si estámos usando el reino de seguridad RDBMS, usamos una de las siguientes opciones para convertirlo:
- Si no cambiamos la fuente del reino de seguridad RDBMS, seguimos los pasos de Configurar un Reindo de Seguridad RDBMS para ejemplarizar una nueva clase para nuestro reino de seguridad RDBMS existente y definimos la información sobre el driver JDBC que se utiliza para conectar con la base de datos y el esquema utilizado. En este caso, estámos creando un MBean en WebLogic Server 6.0 para el reino de seguridad RDBMS.
- Si personalizamos el reino de seguridad RDBMS, convertirmos nuestra fuente para usar los MBeans. Usamos el ejemplo de código del directorio \samples\examples\security\rdbmsrealm como guia para convertir nuestro reino RDBMS. Una vez hayamos convertido nuestro reino de seguridad RDBMS a MBeans, seguimos los pasos de Configurar un Reindo de Seguridad RDBMS para ejemplarizar una nueva clase para nuestro reino de seguridad RDBMS existente y definimos la información sobre el driver JDBC que se utiliza para conectar con la base de datos y el esquema utilizado.

Definir Usuarios

Nota:
Esta sección explica cómo añadir Usuarios al reino File. Si estamos usando un reino alternativo, debemos usar las herramientas de control proporcionadas por ese reino para definir un Usuario.

Los Usuarios son entidades que pueden ser autentificadas en un reino de seguridad del Servidor WebLogic. Un Usuario puede ser una persona o una entidad de software, como un cliente Java. A cada usuario se le dá una identidad única dentro de un reino de seguridad del Servidor WebLogic. Como administradores del sistema deberemos garantizar que no hay dos usuarios idénticos en el mismo reino de seguridad.

Definir usuarios en un reino de seguridad implica especificar un nombre único y una password para cada Usuario que tenga acceso a los recursos del Servidor WebLogic en la ventana Users de la Consola de Administración. La siguiente tabla describe los campos de la ventana Users:

Campo	Descripción
Name	El nombre de un Usuario, es decir, una entidad que accederá a los recursos del Servidor WebLogic. Los nombres son sensibles a las mayúsculas.
Password	La password para el Usuario. La password debe ser de 8 caracteres como mínimo y son sensibles a las mayúsculas.

El reino File tiene dos usuarios especiales, system y guest:

El Usuario system es el usuario administrativo que controla las operaciones del Servidor WebLogic a nivel de sistema, como parar y arrancar servidores, y bloquear o desbloquear recursos. El Usuario system se define durante el procedimiento de instalación de WebLogic Server.

WebLogic Server proporciona automáticamente el Usuario guest. Cuando no se requiere autorización alguna, el Servidor WebLogic asigna la identidad guest a un cliente dándole acceso a cualquier recurso que esté disponible para el usuario guest. Un cliente puede entrar como el Usuario guest como nombre de usuario y guest como password.

Los usuarios system y guest son como los demás usuarios en un reino de seguridad del Servidor WebLogic:

Para acceder a recursos del Servidor WebLogic, deben tener los ACLs apropiados.

Para ejecutar una operación sobre un recurso del Servidor WebLogic, deben proporcionar un nombre de usuario y una password (o un certificado digital).

Para mejorar la seguridad de nuestro despliegue del Servidor WebLogic, recomendamos deshabilitar el usuario guest. Para hacer esto, marcamos la opción Guest Disabled sobre la pestaña General en la ventana Security de la Consola de Administración. Cuando desactivamos al usuario guest, no se borra, sólo se convierte en inaccesible para que nadie pueda entrar con ese nombre de usuario.

Para borrar Usuarios, introducimos el nombre del usuario en la caja de lista Remove These Users y pulsamos Remove.

Definir Grupos

Nota:
Esta sección explica cómo añadir Grupos al reino File. Si estamos usando un reino alternativo, debemos usar las herramientas de control proporcionadas por ese reino para definir un Grupo.

Un Grupo representa un conjunto de Usuarios que normalmente hacen algo en común, como trabajar en el mismo departamente de la compañía. Los Grupos se usan principalmente para manejar un número de Usuarios de una forma eficiente. Cuando a un Grupo se le concede algún permiso en un ACL, todos los miembros de ese grupo reciben el mismo permiso.

Podemos registar un Grupo con el reino de seguridad del Servidor WebLogic realizando los siguientes pasos:

Seleccionar el campo Name en la ventana Groups de la Consola de Admnistración.

Pulsar el botón Create.

Introducir los Usuarios en el campo Add User.

Pulsar el botón Update Group cuando hayamos terminado de añadir usuarios.

El reino File tiene uno Grupo interno: everyone. Todos los usuarios definidos en el reino de seguridad definido automáticamente son miembros del Grupo everyone.

Para borrar Grupos, introducimos el nombre del Grupo en la caja de listas Remove These Groups y pulsamos Remove.

Definir un Grupo para un Host Virtual

En el Servidor WebLogic, los host virtuales que requieren autentificación están representados en un reino de seguridad como un Grupo. Todos los usuarios de un host virtual primero se definen como usuarios del reino de seguridad para un Servidor WebLogic particular y luego son definidos como miembros del grupo que representa el host virtual.

Definir ACLs

Los Usuarios acceden a recursos en un reino de seguridad del Servidor WebLogic. Si un usuario puede o no acceder a un recurso lo determina la lista de control de acceso (ACL) para ese recurso. Una ACL define los permisos por los que un usuario puede interactuar con el recurso. Para definir ACLs, creamos una ACL para un recurso, especificamos los permisos para el recurso y luego concedemos los permisos a un conjunto especificado de Usuarios y Grupos.

Todo los recursos de un Servidor WebLogic tienen uno o más persmisos que pueden concederse. La siguiente tabla sumariza las funciones de varios recursos del Servidor WebLogic para los que se pueden restringir permisos con un ACL:

Para este recurso de WebLogic Server...	Este ACL...	Concede permisos para estas funciones...
WebLogic Servers	weblogic.server weblogic.server.servername	boot
Command-line Administration Tools	weblogic.admin	shutdown, lockserver, unlockserver
WebLogic Events	weblogic.servlet.topicName	send receive
WebLogic servlets	weblogic.servlet.servletName	execute
WebLogic JDBC connection pools	weblogic.jdbc.connectionPool.poolname	reserve reset shrink
WebLogic Passwords	weblogic.passwordpolicy	unlockuser
WebLogic JMS destinations	weblogic.jms.topic.topicName weblogic.jms.queue.queueName	send, receive
WebLogic JNDI contexts	weblogic.jndi.path	lookup modify list

Para crear ACLs para un recurso del Servidor WebLogic, abrimos la Consola de Administración y realizamos los siguientes pasos:

Especifiamos el nombre del recurso que queremos proteger con un ACL.
Por ejemplo, creamos un ACL para un almacen de conexiones JDBC llamado demopool.
Especificamos un permiso para el recurso.
Podemos crear ACLs separados por cada permiso disponible para un recurso o un ACL que conceda todos los permisos para un recurso. Por ejemplo, podremos crear tres ACLS para el almacen de conexiones JDBC, demopool: uno con el permiso reserve otro con el permiso reset, y otro con el permiso shrink. O podemos crear un ACL con los permisos reserve, reset,y shrink.
Especificamos Usuarios o Grupos que tienen los permisos especificados para el recurso.
Cuando se crean ACLs para recursos de un Servidor WebLogic, necesitamos usar la síntaxis de la tabla mostrada en Definir ACLs. Por ejemplo, el almacen de conexiones JDBC llamado demopool se especificaría como weblogic.jdbc.connectionPool.demopool.

Antes de poder reiniciar un Servidor WebLogic, necesitamos dar permiso para hacerlo a un conjunto de usuarios. Esta seguridad evita que usuarios no autorizados reinicien el Servidor WebLogic.

Configurar el Protocolo SSL

El protocolo Secure Sockets Layer (SSL) proporciona conexiones seguras permitiendo que dos aplicaciones que se conectan a través de la red se autentifiquen la una a la otra y encriptando los datos intercambiados entre las aplicaciones. El protocolo SSL proporciona autentificación de servidor y opcionalmente del cliente, confidencialidad e integridad de datos.

Para configurar el protocolo SSL, realizamos los siguientes pasos:

Obtenemos una clave privada y un certificado digital para el Servidor WebLogic. Necesitamos un certificado digital y una clave privada por cada Servidor WebLogic que use el protocolo SSL.

Almacenamos la clave privada y el certificado digital para el Servidor WebLogic.

A través de la Consola de Administración, configuramos los campos del protocolo SSL y la clave privada, el certificado digitial, y las autoridades de certificación creibles para el Servidor WebLogic. Estos campos están definidos de una forma básica; debemos definirmos para cualquier Servidor WebLogic que use el protocolo SSL.

Solicitar la Clave Privada y el Certificado Digital

Para adquirir un certificado digital desde una autoridad de certificación, necesitamos enviar nuestra petición en un formato particular llamado "Certificate Signature Request" (CSR). WebLogic Server incluye un servlet Certificate Request Generator que crea un CSR. Este servlet recolecta información sobre nosotros y genera un fichero de clave privada y un fichero de petición de certificado. Luego podemos enviar el CSR a una autoridad de certificación como VeriSign o Entrust.net. Antes de poder usar el servlet Certificate Request Generator, el Servidor WebLogic debe estar instalado y en ejecución.

Para generar un CSR, realizamos los siguientes pasos:

Arrancar el servlet Certificate Request Generator. El fichero .war para el servlet está localizado en el directorio \wlserver6.0\config\mydomain\applications. El fichero .war se instala automáticamente cuando arrancamos el Servidor WebLogic.

En un Navegador Web, introducimos la URL del servlet Certificate Request Generator de esta forma:
```
https://hostname:port/Certificate
```
Los componentes de esta URL se definen de esta forma:
- hostname es el nombre DNS de la máquina que está ejecutando el Servidor WebLogic.
- port es el número de puerto por el que el Servidor WebLogic escucha conexiones SSL. El valor por defecto es 7002.
Por ejemplo, si el Servidor WebLogic se está ejecutando sobre una máquina llamada ogre y está configurado para escuchar comunicaciones SSL en el puerto por defecto, para ejecutar el servlet Certificate Request Generator, debemos introducir la siguiente URL en nuestro navegador Web:
```
https://ogre:7002/certificate
```

El servlet Certificate Request Generator carga un formulario en nuestro navegador Web.

Completamos el formulario mostrado en el navegador, usando la información de la siguiente tabla:

Campo	Descripción
Country code	El código ISO de dos letras de nuestro país. El código para los Estados Unidos es US.
Organizational unit name	El nombre de nuestra división, departamento, u otra unidad operacional de nuestra organización.
Organization name	El nombre de nuestra organización. La autoridad de certificación podría requerir que cualquier nombre de host introducido en este campo pertenezca a un dominio registrado en esta organización.
E-mail address	La dirección e-mail del administrador. El certificado digital es enviado a esta dirección de correo.
Full host name	El nombre totalmente cualificado del Servidor WebLogic en el que será instalado el Certificado Digital. Este nombre es el usado para las búsquedas DNS del Servidor WebLogic, por ejemplo, node.mydomain.com. Los navegadores Web comparan el nombre de Host de la URL con el nombre del certificado digital. Si posteriormente cambiamos el nombre del host, debemos solicitar un nuevo certificado digital.
Locality name (city)	El nombre de nuestra ciudad. Si operamos con un licencia concedida por una ciudad, este campo es obligatorio; debemos introducir el nombre de la ciudad que nos ha concedido la licencia.
State name	El nombre del Estado o Provincia en el que opera nuestra organización si nuestra organización está en Estados Unidos o Canadá, respectivamente. No debemos abreviar.
Private Key Password	La password usada para encriptar la clave privada. Introducimos una password en este campo si queremos usar una clave protegida con el Servidor WebLogic. Si elegimos usar una clave protegida, se nos pedirá esta password siempre que se use la clave. Si especificamos una password, obtenemos una clave privada encriptada PKCS-8. BEA recomienda el uso de una password para proteger las claves privadas. Si no queremos usar un clave protegida, dejamos este campo en blanco. Para usar claves privadas protegidas, activamos el campo Use Encrytped Keys sobre la pestaña SSL de la ventana Server en la Consola de Administración.
RandomString	Un string de caracteres a utilizar para el algoritmo de encriptación. No tenemos que recordar este string en el futuro. Añade un factor externo al algoritmo de encriptación, haciéndo más dificil que alguien rompa la encriptación. Por esta razón, introducimos un string que no vaya a ser recordado. BEA recomienda utilizar un string largo con una buena mezcla de letras mayúsculas y minúsculas, dígitos, espacios y signos de puntuación; estas cadenas largas y mezcladas contribuyen a una encriptación más segura.
Strength	La longitud (en bits) de las claves a generar. Cuando más larga sea la clave, más dificil será romper la encriptación. Si tenemos una versión doméstica del Servidor WebLogic, podemos elegir entre claves de 512-, 768-, o 1024-bits. Recomendamos la clave de 1024-bits.

Pulsamos el botón Generate Request.
El servlet Certificate Request Generator muestra un mensaje informandonos de cualquier campo que esté vacío o si cualquiera ellos contiene valores nulos. Pulsamos el botón Back en nuestro navegador y corregimos los errores.

Cuando todos los campos hayan sido aceptados, el servlet Certificate Request Generator genera los siguientes ficheros en el directorio de arrancada de nuestro Servidor WebLogic:
- www_mydomain_com-key.der— El fichero de la clave privada. El nombre de este fichero debería ir dentro del campo Server Key File Name de la pestaña SSL en la Consola de Administración.
- www_mydomain_com-request.dem— El fichero de petición de certificado, en formato binario.
- www_mydomain_com-request.pem— El fichero CSR que enviamos a la autoridad de certificación. Contiene los mismos datos que el fichero .dem pero codificado en ASCII por lo que podemos copiarlo dentro del correo o pegarlo dentro de un formulario Web.

Seelccionamos una autoridad de certificación y seguimos las instrucciones de la página web de esa autoridad para comprar un certificado digital.
- VeriSign, Inc. ofrece dos opciones para WebLogic Server: Global Site Services con características de encriptación fuerte de 128-bits para navegadores Web y export, y Secure Site Services, que ofrece encriptación de 128-btis para navegadores web domésticos y encriptación de 40-btis para navegadores web de exportación.
- Entrust.net digital certificates ofrece encriptación de encriptación de 128-btis para navegadores web domésticos y encriptación de 40-btis para navegadores web de exportación.

Cuando se nos pida que seleccionemos el tipo de servidor, elegimos BEA WebLogic Server para asegurarnos de que recibimos un certificado digital que sea compatible con el Servidor WebLogic.

Cuando recibamos nuestro certificado digital de la autoridad de certificación, necesitamos almacenarlo en el directorio \wlserver6.0\config\mydomain.

Nota:
Si obtenemos un fichero de clave privada de una fuente distinta al servlet Certificate Request Generator, debemos verificar que el fichero está en formato PKCS#5/PKCS#8 PEM.

Configuramos el Servidor WebLogic para usar el protocolo SSL, necesitamos introducir la siguiente información en la pestaña SSL de la ventana Server Configuration:
- En el campo Server Certificate File Name, introducimos la localización completa del directorio y el nombre del certificado digital para el Servidor WebLogic.
- En el campo Trusted CA File Name, introducimos la localización completa del directorio y el nombre del certificado digital de la autoridad de certificación que firmó el certificado digital del Servidor WebLogic.
- En el campo Server Key File Name, introducimos la localización completa del directorio y el nombre del fichero de clave privada para el Servidor WebLogic.

Usamos la siguiente opción de la línea de comandos para arrancar el Servidor WebLogic:
```
-Dweblogic.management.pkpassword=password
```
donde password es la password definida cuando se solicitó el certificado digital.

Almacenar las Claves Privadas y los Certificados Digitales

Una vez que tenemos una clave privada y un certificado digital, copiamos el fichero de la clave privada generado por el servlet Certificate Request Generator y el certificado digital recibido de la autoridad de certificación en el directorio \wlserver6.0\config\mydomain.

Los ficheros de claves privadas y certificados digitales están generados en los formatos PEM o Definite Encoding Rules (DER). La extensión del fichero identifica el formato del fichero del certificado digital.

Un fichero de clave privada PEM(.pem) empieza y termina con las siguientes líneas respectivamente:

-----BEGIN ENCRYPTED PRIVATE KEY-----

-----END ENCRYPTED PRIVATE KEY-----

Un certificado digital PEM(.pem) empieza y termina con las siguientes líneas, respectivamente:

-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

Nota:
Nuestro certificado digital podría ser uno de los varios certificados digitales en en el fichero, cada uno limitado por las líneas BEGIN CERTIFICATE y END CERTIFICATE. Normalmente el certificado digital para un Servidor WebLogic está en un fichero, con una extensión .pem o .der, y la cadena de certificados del servidor en otro fichero. Se usan dos ficheros porque diferentes Servidores WebLogic podrían usar la misma cadena de certificados.

El primer certificado digital en el fichero de la autoridad de certificación es el primer certificado digital en la cadena de certificados del Servidor WebLogic. Los siguientes certificados del fichero son los siguientes de la cadena. El último certificado de la cadena es un certificado digital auto-firmado que termina la cadena de certificados.

Un fichero de formato DER(.der) contiene datos binarios. El Servidor WebLogic requiere que la extensión del fichero corresponda con el contenido del fichero de certificado por ese debemos asegurarnos de grabar el fichero que recibimos de nuestra autoridad de certificación con la extensión de fichero correcta.

Asignamos protecciones al fichero de la clave privada y a los certificados digitales para que sólo el usuario system del Servidor WebLogic tenga privilegios de lectura y ningún otro usuario tenga privilegios de acceso al fichero de clave primaria o al certificado digital. Si estámos creando un fichero con certificados digitales de varias autoridades de certificación o un fichero que contiene una cadena de certificados, debemos usar el formato PEM. El Servidor WebLogic proporciona una herramienta para convertir ficheros en formato DER a formato PEM, y vice-versa.

Definir Autoridades de Certificación

Cuando establecemos una conexión SSL, el Servidor WebLogic chequea la identidad de la autoridad de certificación contra una lista de autoridades de certificación creibles para asegurarse de que la autoridad que se está utilizando actualmente es verdedera.

Copiamos el certificado raíz de la autoridad de certificación en el directorio \wlserver6.0\config\mydomain de nuestro Servidor WebLogic y seleccionamos los campos descritos en Definir Campos para el Protocolo SSL.

Si queremos usar una cadena de certificados, añadimos el certificado digital codificado en PEM al certificado digital de la autoridad de certificación que envía el certificado digital para el Servidor WebLogic. El último certificado digital del fichero debería ser un certificado digital auto-firmado (es decir, el certificado rootCA).

Si queremos usar autentificación mutua, tomamos los certificados raices de las autoridades de autentificación que queremos aceptar y los incluimos en el fichero CA creible (trusted CA).

Definir Campos para SSL

Para definir campos para el protocolo SSL, realizamos los siguientes pasos:

Abrimos la Consola de Adminstración.

Abrimos la ventana Administration.

Seleccionamos la pestaña SSL. Definimos los campos de esta pestaña introduciendo valores y marcando los chekboxes necesarios. (Para más detalles, ver la siguiente tabla).

Pulsamos el botón Apply para grabar los cambios.

Reiniciamos el Servidor WebLogic.

La siguiente tabla describe todos los campos de la pestaña SSL de la ventana Server Configuration:

Nota:
Recuerda que si estámos usando una clave privada protegida PKCS-8, necesitamos especificar la password para la clave privada en la línea de comandos cuando arrancamos el Servidor WebLogic.

Campo Descripción

Enabled Checkbox que activa el uso del protocolo SSL. Por defecto, este campo está activado.

SSL Listen Port El número de puerto dedicado en el que el Servidor WebLogic escucha conexiones SSL. Por defecto es 7002.

Server Key File Name El directorio de la localización completa y el nombre del fichero de clave privada del Servidor WebLogic. La extensión del fichero (.DER o .PEM) indica el método que debería usar el Servidor WebLogic para leer los contenidos del fichero.

Server Certificate File Name El directorio de la localización completa y el nombre del fichero del certificado digital del Servidor WebLogic. La extensión del fichero (.DER o .PEM) indica el método que debería usar el Servidor WebLogic para leer los contenidos del fichero.

Server Certificate Chain File Name El directorio de la localización completa y el nombre del resto de los certificados digitales del Servidor WebLogic. La extensión del fichero (.DER o .PEM) indica el método que debería usar el Servidor WebLogic para leer los contenidos del fichero.

Client Certificate Enforced Checkbox que activa la autentificación mutua.

Trusted CA File Name El nombre del fichero que contiene el certificado digital de la autoridad(es) de certificación creibles por el Servidor WebLogic. Este fichero puede contener un sólo certificado digital o varios de ellos. La extendión del fichero (.DER o .PEM) le dice al Servidor WebLogic cómo leer los contenidos del fichero.

CertAuthenticator El nombre de la clase Java que implementa el interface CertAuthenticator.

Use Java Checkbox que activa el uso de librerías nativas de Java. WebLogic Server proporciona una implementación pura-Java del protocolo SSL: las librerías nativas de Java mejoran el rendimiendo de las operaciones SSL sobre plataformas Solaris, Windows NT, IBM AIX. Por defecto, este campo no está activado.

Use Encrypted Keys Campo que especifica que la clave privada del Servidor WebLogic ha sido encriptada con un password. Por defecto es false.

Handler Enabled

Campo que especifica si el Servidor WebLogic rechaza o no conexiones SSL que fallan en la autentificación del cliente por una de las siguientes razones:

El certificado digital del cliente solicitado no está completo.

El cliente no envió un certificado digital.

El certificado digital del cliente no fue enviado por una autoridad de certificación especificada en el campo Trusted CA Filename.

Por defecto, el SSL Handler permite a un Servidor WebLogic hacer conexiones SSL salientes a otro Servidor WebLogic. Por ejemplo un EJB en un Servidor WebLogic podría abrir un stream HTTPS sobre otro Servidor Web. Con el campo Handler Enabled activado, el Servidor WebLogic actúa como un cliente en una conexión SSL. Por defecto este campo está activado.

Sólo debemos desactivar este campo si queremos proporcionar nuestra propia implementación de conexiones SSL salientes.

Nota:
El SSL Handler no tiene efecto en la habilidad del Servidor WebLogic para manejar conexiones SSL entrantes.

Export Key Lifespan El número de veces que el Servidor WebLogic usa una clave exportable entre un servidor doméstico y un cliente exportable antes de generar una nueva. Cuando más seguro queramos que sea el Servidor WebLogic menor número de veces se debería usar la clave antes de generar una nueva. El valor por defecto es usarla 500 veces.

Login Timeout Millis El número de milisegundos que el Servidor WebLogic debería esperar una conexión SSL antes de marcar un error de time-out. El valor por defecto es 25000 milisegundos. Las conexiones SSL tardan mucho más tiempo en negociarse que las conexiones normales. Si los clientes se conectan a través de internet, debemos subir el valor por defecto para acomodarnos a la latencia adicional de la red.

Certificate Cache Size El número de certificados digitales que son divididos y almacenados por el Servidor WebLogic. El valor por defecto es 3.

Configurar la Autentificación Mutua

Cuando el Servidor WebLogic está configurado para autentificación mutua, se requiere que los clientes preseten sus certificados digitales al Servidor WebLogic que valida los certificados digitales contra una lista de autoridades de certificación creibles.

Para configurar nuestro Servidor WebLogic para el protocolo SSL y la autentificación de certificados, debemos completar los procedimientos de Configurar el Protocolo SSL.

Copiamos los certificados raíces de las autoridades de certificación a utilizar por el Servidor WebLogic en el directorio \wlserver6.0\config\mydomain. Durante la autentificación mutua, se requeire que los clientes preseten sus certificados digitales enviados por una de estas autoridades de certificación creibles.

Para configurar la autentificación mutua, pulsamos la opcion Client Certificate Enforced sobre la pestaña SSL en la ventana Server Configuration de la Consola de Administración. Por defecto, esta opción no está activada.

Configurar RMI sobre IIOP sobre SSL

El protocolo SSL puede usarse para proteger conexiones IIOP sobre objetos remotos RMI. El protocolo SSL asegura las conexiones mediante autentificación y encriptación de los datos intercambiados entre objetos. Para usar el protocolo SSL para protefer IIOP sobre conexiones RMI, hacemos los siguiente:

Configuramos el Servidor WebLogic para usar el protocolo SSL. Puedes encontrar más información en Configurar el Protocolo SSL.

Configuramos el cliente Object Request Broker (ORB) para usar el protocolo SSL. Nos debemos referir a la documentación de nuestro cliente ORB para buscar la información sobre cómo configurar el protocolo SSL.

Usar la utilidad host2ior para imprimir el WebLogic Server IOR en la consola. Esta utilidad imprime dos versiones del IOR, una para conexiones SSL y otra para conexiones no SSL. La cabecera del IOR especifica si puede usarse o no en conexiones SSL.

Usar el IOR SSL cuando obtengamos la referencia inicial al servicio CosNaming que accede al árbol JNDI del Servidor WebLogic.

Proteger Passwords

Es importante proteger las password que estámos usando para acceder a los recursos de un Servidor WebLogic. En el pasado, los nombres de usuarios y las passwords se almacenaban en texto normal en un reino de seguridad. Ahora el Servidor WebLogic emborrona todas las passwords. Cuando el Servidor WebLogic recibe una petición de un cliente, la password presentada por el ciente se emborrona y el Servidor WebLogic la compara con la password ya emborronada que tiene almacenada.

Todo fichero filerealm.properties tiene asociado un fichero SerializedSystemIni.dat que se usa para emborronar las passwords. Durante la instalación el fichero SerializedSystemIni.dat se pone en el directorio \wlserver6.0\config\mydomain. Si por cualquier razón este fichero se corrompe o se destruye, debemos reconfigurar el Servidor WebLogic.

Recomedamos seguir estos pasos:

Hacer una copia de seguridad del fichero SerializedSystemIni.dat y ponerla en el mismo sitio que la copia del fichero filerealm.properties asociado.

Configurar los permisos del fichero SerializedSystemIni.dat para que el administrador del Servidor WebLogic tenga privilegios de lectura y escritura y los otros usuarios no tengan ningún privilegio.

Si ya tenemos un fichero weblogic.properties y queremos emborronar las passwords en el fichero, usamos la opción Convert weblogic.properties de la ventana principal de la Consola de Administración para convertir el fichero weblogic.properties en un fichero config.xml. Una vez convertido este fichero, todas las passwords existentes están protegidas.

La adivinación de passwords es un tipo común de ataque de seguridad. En este tipo de ataque, un hacker intenta entrar en un ordenador usando varias combinaciones de nombres de usuario y password. El Servidor WebLogic refuerza su protección contra este tipo de ataques proporcionando un conjunto de campos diseñados para proteger passwords.

Para proteger passwords en nuestro Servidor WebLogic, debemos realizar los siguientes pasos:

Abrir la Consola de Administración.

Abrir la ventana Security Configuration.

Seleccionar la pestaña Passwords. Definimos los campos deseados en esta pestaña introduciendo valores en los prompts apropiados y marcando los checkboxes necesarios (para más detalles ver la siguiente tabla.)

Pulsamos el botón Apply para grabar nuestras elecciones.

Reiniciamos el Servidor WebLogic.

La siguiente tabla describe todos los campos de la pestaña Passwords de la ventana Security Configuration:

Campo	Descripción
Minimum Password Length	Número de caracteres requeridos en una password. Las passwords deben ser de como mínimo 8 caracteres. El valor por defecto es 8.
Lockout Enabled	Checkbox que solicita el bloqueo de una cuenta de usuario cuando se hace un intento sin éxito de entrar en esa cuenta. Por defecto este campo está activado.
Lockout Threshold	El número de introducciones de passwords falladas que un usuario puede intentar antes de que la cuenta sea bloqueada. Cualquier intento subsecuente de acceder a la cuenta (incluso si la combinación nombre de usuario/password es correcta) lanza una excepción de seguridad; la cuenta permanece bloqueada hasta que la desbloquee explicitamente el administrador del sistema o se intente otro login después de que termine el periodo de duración del bloqueo. Observamos que los intentos de login fallidos deben hacerse dentro del tiempo definido en el campo Lockout Reset Duration. El valor por defecto es 5.
Lockout Duration	El número de minutos que una cuenta de usuario permanece bloqueada en respuesta a varios intentos de login fallidos dentro de una cantidad de tiempo especificada por el campo Lockout Reset Duration. El valor por defecto es 30 minutos. Para desbloquear una cuenta de usuario, necesitamos tener el permiso `unlockuser` para la política `weblogic.password`.
Lockout Reset Duration	El número de minutos dentro del cual debe ocurrir un intento de login fallido para bloquear la cuenta de usuario. Una cuenta se bloquea si se suceden el número intentos de logins fallidos definidos en el campo Lockout Threshold dentro del tiempo definido en este campo. Por ejemplo, si el valor de este campo es cinco minutos y se hacen tres intentos de login fallidos dentro de un intervalo de seis minutos, la cuenta no se bloqueará. Si si hacen cinco intentos fallidos dentro del perido de cinco minutos, la cuenta será bloqueada. El valor por defecto es 5 minutos.
Lockout Cache Size	Especifica el tamaño de caché de intentos de logín sin utilizar y fallidos. El valor por defecto es 5.

Instalar un Proveedor de Auditoría

WebLogic Server nos permite crear un proveedor de auditoría para recibir y procesar notificaciones de eventos de seguridad, como peticiones de autentificación, fallidas o con éxito, intentos de autorización, y recepción de certificados digitales no válidos

Para usar un proveedor de auditoria, creamos una implementación del interface weblogic.security.audit.AuditProvider. Luego usamos la Consola de Administración para instalar y activar nuestra implementación.

Para instalar un proveedor de auditoría, introducimos el nombre de nuestra implementación de la clase AuditProvider en el campo Audit Provider Class de la ventana Security Configuration. Reiniciamos el Servidor WebLogic.

Podemos encontrar un ejemplo de creacción de un proveedor de auditoria LogAuditProvider en el directorio \samples\examples\security de nuestra instalación del Servidor WebLogic.

Instalar un Filtro de Conexión

Podemos crear filtros de conexiones que nos permitan rechazar o aceptar conexiones de clientes basándose en el origen y el protocolo del cliente. Después de que el cliente se conecte, y antes de que se realice ningún trabajo en su cuenta, el Servidor WebLogic pasa el número IP del cliente y el puerto, el protocolo (HTTP, HTTPS, T3, T3S, o IIOP), y el número de puerto del Servidor WebLogic al filtro de conexión. Examinando esta información, podemos elegir permitir la conexión o lanzar una FilterException para terminarla.

Para usar un filtro de conexión, primero debemos crear una implementación del interface weblogic.security.net.ConnectionFilter. Luego usamos la Consola de Administración para instalar nuestra implementación.

Para instalar un filtro de conexión, introducimos el nombre de nuestra implementación del interface weblogic.security.net.ConnectionFilter, en el campo Connection Filter de la pestaña General de la ventana Security Configuration de la Consola de Administración y reiniciamos el Servidor WebLogic.

Podemos encontrar un ejemplo de creacción de un filtro de conexión SimpleConnectionFilter en el directorio \samples\examples\security de nuestra instalación del Servidor WebLogic.

Configurar la Propagación del Contexto de Seguridad

La propagación del contexto de seguridad permite a las aplicaciones que se están ejecutando en un entorno WebLogic Server acceder a objetos y operaciones en dominios BEA WebLogic Enterprise (WLE). El componente BEA WebLogic Enterprise Connectivity (WLEC) de un Servidor WebLogic proporciona la capacidad de propagación del contexto de seguridad.

Cuando se usa la propagación del contexto de seguridad, la identidad de seguridad de un Usuario definido en un reino de seguridad WebLogic Server se propaga como parte del contexto de servicio de una petición Internet Inter-ORB Protocol (IIOP) enviada al dominio WLE sobre una conexión de red que es parte del almacen de conexiones WLEC. Toda conexión de red del almacen de conexiones WLEC ha sido autentificada usando una identidad de Usuario definida.

Para usar la propagación del contexto de seguridad, creamos un almacen de conexiones WLEC por cada dominio WLE al que queramos aceder desde el Servidor WebLogic. WebLogic Server rellena cada almacen de conexiones WLEC con conexiones IIOP. Las aplicaciones Java en un entorno WebLogic Server obtienen conexiones desde un almacen de conexiones WLEC y usa esas conexiones para llamar a objetos e invocar operaciones en los dominios WLE.

Antes de usar la propagación del contexto de segruidad, añadimos WLE_HOME/lib/wleorb.jar y WLE_HOME/lib/wlepool.jar a la variable CLASSPATH en los ficheros startAdminWebLogic.sh o startAdminWebLogic.cmd.

Aquí están los pasos para la implementación de la propagación del contexto de seguridad:

Creamos un nuevo almacen de conexiones WLEC para el propósito de la propagación del contexto de seguridad. Para crearlo vamos al nodo Services --> WLEC en el panel izquierdo de la Consola de Administración. En el panel derecho, pulsamos el enlace Create a new WLEC Connection Pool y definimos los campos descritos en la siguiente tabla:

Campo	Descripción
Name	El nombre del almacen de conexiones WLEC. El nombre debe ser único para cada almacen de conexiones WLEC.
Primary Addresses	Una lista de direcciones para Listener/Handlers IIOP que pueden usarse para establecer conexiones entre el almacen de conexiones y el dominio WLE. El formato de cada dirección es `//hostname:port`. Las direcciones deben corresponder con las direciones ISL definidas en el fichero UBBCONFIG. Las distintas direcciones están separadas por puntos y coma. Por ejemplo: `//main1.com:1024; //main2.com:1044`. Para configurar el almacen de conexiones WLEC usando el protocolo SSL, usamos el prefijo `corbalocs` con las direcciones IIOP. Por ejemplo: `corbalocs://hostname:port`.
Failover Addresses	Una lista de direcciones de `Listener/Handlers IIOP` que se usan si las conexiones no se pueden establecer con las direcciones definidas en el campo Primary Addresses. Múltiples direcciones irán separadas por puntos y coma. Este campo es opcional.
Domain	El nombre del dominio WLE al que se conecta este almacen de conexiones WLEC. Sólo podemos tener un almacen de conexiones WLEC por cada dominio WLE. El nombre de domino debe corresponder con el parámetro domainid de la sección RESOURCES del fichero UBBCONFIG del dominio WLE.
Minimum Pool Size	El número de conexiones IIOP a añadir al almacen de conexiones WLEC cuando arranca el Servidor WebLogic. El valor por defecto es 1.
Maximum Pool Size	El número máximo de conexiones IIOP que se pueden hacer desde el almacen de conexiones WLEC. El valor por defecto es 1.

Pulsamos el botón Create.

Propagamos el contexto de seguridad para un Usuario en un reino de seguridad de un Servidor WebLogic para un dominio WLE. Para hacer esto, definimos los campos de la pestaña Security en la ventana Connection Pool Configuration. La siguiente tabla muestra estos campos:

Campo	Descripción
User Name	Un nombre de usuario WLE. Este campo sólo se requiere cuando el nivel de seguridad del dominio WLE es `USER_AUTH`, `ACL` o `MANDATORY_ACL`.
User Password	La password del usuario definido en el campo User Name. Este campo es requerido sólo cuando definimos el campo User Name.
User Role	El role del usario WLE. Este campo sólo es necesario cuando el nivel de seguridad en el dominio WLE es `APP_PW`, `USER_AUTH`, `ACL`, o `MANDATORY_ACL`.
Application Password	La password de la aplicación WLE. Este campo sólo es necesario cuando el nivel de seguridad en el dominio WLE es `APP_PW`, `USER_AUTH`, `ACL`, o `MANDATORY_ACL`.
Minimum Encryption Level	El nivel de encriptación SSL mínimo usado entre el dominio WLE y el Servidor WebLogic. Los valores posibles son 0, 40, 56, y 128. El valor por defecto es 40. Cero (0) indica que los datos están firmados pero no sellados. 40, 56, y 128 especifican la longitud, en bits, de la clave de encriptación. Si no se alcanza este valor mínimo de encriptació, la conexión SSL entre el WLE y el Servidor WebLogic fallará.
Maximum Encryption Level	El nivel máximo de encriptación usado entre el dominio WLE y el Servidor WebLogic. Los posibles valores son 0, 40, 56, y 128. El valor por defecto es el máximo nivel permitido por el kit de licencia del paquete de encriptación.
Enable Certificate Authentication	Checkbox que activa el uso de certificado de autentificación. Por defecto el certificado de autentificación está desactivado.
Enable Security Context	Marcamos este checkbox para pasar el contexto de seguridad del usuario del Servidor WebLogic pasado al dominio WLE. Por defecto, el contexto de seguridad está desactivado.

Para grabar nuestros cambios, pulsamos el botón Apply y reiniciamos el Servidor WebLogic.

Ejecutamos el comando tpusradd para definir el Usuario del Servidor WebLogic como un Usuario autorizado en el dominio WebLogic Enterprise.

Seleccionamos la opción -E del comando ISL para configurar el Listener/Handler IIOP para detectar y utilizar el contexto de seguridad propagado desde el reino de Servidor WebLogic. Esta opción requiere que especifiquemos un nombre principal. Este nombre define el principal usado por el almacen de conexiones WLEC para entrar en el dominio WebLogic Enterprise. El nombre principal debería corresponder con el nombre definido en el campo User Name cuando se creó el almacen de conexiones WLEC.

Usar certificados de autentificación entre el entorno WebLogic Server y el entorno WebLogic Enterprise implica realizar una nueva negociación SSL cuando se establece la conexión desde el entorno WebLogic Server a un objeto CORBA, RMI, o un EJB en un entorno WebLogic Enterprise. Para soportar peticiones de varios clientes sobre la misma conexión SSL, debemos configurar el certificado de autentificación para que opere de la siguiente forma:

Obtener un certificado digital del principal y poner la clave privada en el directorio TUXDIR/udataobj/security/keys del WebLogic Enterprise.

Usar el comando tpusradd para definir el principal como un usuario de WebLogic Enterprise.

Definir el Listener/Handler IIOP en el fichero UBBCONFIG con la opción -E para indicar que se va a utilizar el principal para autentificación.

Definir el nombre principal en el campo User Name cuando creamos un almacen de conexiones WLEC en la Consola de Administración del Servidor WebLogic.

Obtener un certificado digital para el Listener/Handler IIOP.

Especificar el certificado digital en la opción SEC_PRINCIPAL_NAME del comando ISL y usamos la opción -S para indicar que se debería usar un puerto seguro para la comunicación entre el dominio WebLogic Enterprise y el reino de seguridad del Servidor WebLogic.