BEA WebLogic: Guía de Administración

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:

1. Cambiar la password del sistema para proteger nuestro Servidor WebLogic.
2. 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.
3. Definir usuarios para el reino de seguridad. Podemos organizar posteriormente los usuarios implementando grupos en el reino de seguridad.
4. Definir ACLs y permisos para los recursos de nuestro Servidor WebLogic.
5. 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.
6. 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:

1. Abrimos la ventana Users en la Consola de Administraci�n.
2. Introducimos system en el campo User.
3. Introducimos una nueva password en el campo Password.
4. 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.

�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:

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:

1. Hacer una copia de seguridad del fichero fileRealm.properties y ponerla en un sitio seguro.
2. 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.

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

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.

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:

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:

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:

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:

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:

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:

�Configurar el Reino LDAP

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:

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:

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:

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:

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::

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:

1. Usamos la cuenta Administrator para entrar en el dominio Windows NT que est�mos usando con el Servidor WebLogic.
2. Vamos a Programs -> Administrative Tools.
3. Seleccionamos User Manager.
4. Definimos el usuario system.
5. Marcamos la opci�n Show Advanced User Rights.
6. Seleccionamos el Act como parte de la opci�n de sistema operativo desde el men� desplegable Rights.
7. Pulsamos el bot�n Add.
8. 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:

1. 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.
2. Como usuario root, ejecutamos los siguientes comandos para cambiar al propietario y los permisos del fichero wlauth:

   # chown root wlauth
   # chmod +xs wlauth
   

3. 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:

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:

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

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:

�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:

1. Arrancamos la Consola de Administraci�n. La Consola muestra todos los Usuarios, Grupos y ACLs conocidos en el reino de seguridad.
2. 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.
3. 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

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:

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

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:

1. Seleccionar el campo Name en la ventana Groups de la Consola de Admnistraci�n.
2. Pulsar el bot�n Create.
3. Introducir los Usuarios en el campo Add User.
4. 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:

weblogic.server
weblogic.server.servername

weblogic.admin

weblogic.servlet.topicName

weblogic.servlet.servletName

weblogic.jdbc.connectionPool.poolname

 weblogic.passwordpolicy

weblogic.jms.topic.topicName
weblogic.jms.queue.queueName

 weblogic.jndi.path

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

1. Especifiamos el nombre del recurso que queremos proteger con un ACL.

   Por ejemplo, creamos un ACL para un almacen de conexiones JDBC llamado demopool.

2. 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.

3. 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:

1. 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.
2. Almacenamos la clave privada y el certificado digital para el Servidor WebLogic.
3. 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:

1. 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.
2. 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
   

3. 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.

4. 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.
5. 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.
6. 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.
7. 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.

8. 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.
9. 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-----

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:

1. Abrimos la Consola de Adminstraci�n.
2. Abrimos la ventana Administration.
3. 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).
4. Pulsamos el bot�n Apply para grabar los cambios.
5. Reiniciamos el Servidor WebLogic.

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

�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:

1. Configuramos el Servidor WebLogic para usar el protocolo SSL. Puedes encontrar m�s informaci�n en Configurar el Protocolo SSL.
2. 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.
3. 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.
4. 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:

1. Abrir la Consola de Administraci�n.
2. Abrir la ventana Security Configuration.
3. 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.)
4. Pulsamos el bot�n Apply para grabar nuestras elecciones.
5. Reiniciamos el Servidor WebLogic.

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

�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:

1. 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.

2. Pulsamos el bot�n Create.
3. 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.

4. Para grabar nuestros cambios, pulsamos el bot�n Apply y reiniciamos el Servidor WebLogic.
5. Ejecutamos el comando tpusradd para definir el Usuario del Servidor WebLogic como un Usuario autorizado en el dominio WebLogic Enterprise.
6. 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:

1. Obtener un certificado digital del principal y poner la clave privada en el directorio TUXDIR/udataobj/security/keys del WebLogic Enterprise.
2. Usar el comando tpusradd para definir el principal como un usuario de WebLogic Enterprise.
3. 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.
4. 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.
5. Obtener un certificado digital para el Listener/Handler IIOP.
6. 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.