Debido a una modificación en la arquitectura inicial, se nos solicito mover unas maquinas virtuales (creadas con OVM) de su repositorio local hacia un “Storage” de SAN.
Esto porque mediante otro software se iban a replicar todos los cambios de un servidor a otro para tener un ambiente DRP. Debido a que “se queria” simplificar la administración no se hizo uso de las capacidades de H-A de OVM.
La siguiente guía puede ser aplicada en los siguientes escenarios (ya sea directa o indirectamente):

  1. Cuando se requiere migrar del storage local hacia un storage de Fibra Optica
  2. Cuando se copia bit a bit las VM’s y estas llegan a un servidor OVM que no fue configurado para ello
  3. Cuando se configuro un servidor con un repositorio inicial y los discos fueron cambiados lo que modifico a su vez los UUID’s

Los siguientes son los pasos necesarios para lograr la migración de la VM’s:

  1. Instalar y configurar los drivers de la tarjeta de fibra. Dependiendo de la marca, serán los pasos necesarios, la mayoría cuenta con sus drivers y únicamente es necesario compilarlos e instalarlos. En conjunto con este paso les recomendamos instalar las sg3-utils, las cuales les ayudarán a detectar issues con la configuración de las LUNS.
  2. Configurar el multipath, para ello deberemos editar el archivo /etc/multipath.conf y dejarlo acorde a la configuración de nuestro ambiente. El siguiente ejemplo es la configuración común de EMC y un Storage Clarion, por supuesto si leemos el manual de multipath.conf encontraremos más información al respecto.
    ## This is the /etc/multipath.conf file recommended for
    ## EMC storage devices.
    ## OS : RHEL5
    ## Arrays : CLARiiON
    ## Use user friendly names, instead of using WWIDs as names.
    defaults {
    user_friendly_names yes
    }

    ## The blacklist is the enumeration of all devices that are to be
    ## excluded from multipath control
    devnode_blacklist {
    ## Replace the wwid with the output of the command
    ## 'scsi_id -g -u -s /block/internal scsi disk name'
    ## Enumerate the wwid for all internal scsi disks.
    ## Optionally, the wwid of VCM database may also be listed here.
    # wwid 20010b9fd080b7321
    #devnode "sd[a]$"
    devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)0-9*"
    devnode "^hda-z"
    devnode "^cciss!c0-9d0-9*"
    }
    devices {
    ## Device attributes for EMC CLARiiON
    device {
    vendor "DGC"
    product "*"
    path_grouping_policy group_by_prio
    getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
    prio_callout "/sbin/mpath_prio_emc /dev/%n"
    hardware_handler "1 emc"
    features "1 queue_if_no_path"
    no_path_retry 300
    path_checker emc_clariion
    failback immediate
    }
    }

  3. En caso de que necesitemos re-scanear los dispositivos y/o las luns, es preciso ejecutar:
    echo “1” > /sys/class/fc_host/hostX/issue_lip
    echo “- – -” > /sys/class/scsi_host/hostX/scan
    Donde X es el ID asociado (normalmente) con cada tarjeta de fibra.
  4. Arrancar el demonio del multipath. Estó generará (en base al archivo antes descrito), los dispositivos con los cuales podremos trabajar. Para validar las configuraciones nos valdremos del comando multipath -ll el cual nos pintará los dispositivos:
    mpath1 (360060160539022006d7b78ce81b4df11) dm-1 DGC,RAID 5
    [size=52G][features=1 queue_if_no_path][hwhandler=1 emc][rw]
    \_ round-robin 0 [prio=2][active]
    \_ 0:0:1:1 sdf 8:80 [active][ready]
    \_ 1:0:1:1 sdn 8:208 [active][ready]
    \_ round-robin 0 [prio=0][enabled]
    \_ 0:0:0:1 sdb 8:16 [active][ready]
    \_ 1:0:0:1 sdj 8:144 [active][ready]
    mpath0 (360060160539022006c7b78ce81b4df11) dm-0 DGC,RAID 5
    [size=52G][features=1 queue_if_no_path][hwhandler=1 emc][rw]
    \_ round-robin 0 [prio=2][active]
    \_ 0:0:0:0 sda 8:0
    [active][ready]
    \_ 1:0:0:0 sdi 8:128 [active][ready]
    \_ round-robin 0 [prio=0][enabled]
    \_ 0:0:1:0 sde 8:64 [active][ready]
    \_ 1:0:1:0 sdm 8:192 [active][ready]
  5. Una vez con los dispositivos /dev/mapper/mpathX generados, procederemos a particionarlos, usando para ello el comando fdisk /dev/mapper/mpathX
  6. Ya particionadas las unidades debemos solicitar al servidor a leer la nueva tabla de particiones, para ello podemos o reiniciar o forzar la lectura de la misma. En este caso nos ocuparemos de “forzar” al servidor, usando para ello la siguiente secuencia de comandos (para más información consulta la página del manual del comando):
    kpartx -a /dev/mapper/mpathX
    kpartx -l /dev/mapper/mpathX
  7. Después se deben formatear las particiones generadas con el sistema de archivos OCFS2, una configuración aceptable es la siguiente:
    mkfs.ocfs2 -T datafiles -N 8 -L “VOL_NAME” /dev/mapper/mpathXp1
    Sin embargo, les recomendamos leer la página del manual del comando y ajustarse de acuerdo a sus necesidades específicas.
  8. Ahora es cuando debemos apagar las máquinas virtuales que estén corriendo en el OVM-server
  9. Agregamos el storage de la SAN como repositorio, para ello hacemos uso del siguiente comando que esta ubicado en /opt/ovs-agent-2.3/utils/ :
    ./repos.py -n /dev/mapper/mpathXp1
    En caso de tener diferentes storages, agregamos cada uno de ellos, y una vez que se hayan agregado todos, los inicializamos ejecutando el siguiente comando:
    ./repos.py -n /dev/mapper/mpathXp1
  10. Agregados todos los repositorios solo basta inicializarlos con el comando: ./repos.py -i

  11. Finalmente solo resta mover las maquinas virtuales a su destino, en general la ruta de destino debe ser:
    /var/ovs/mount/$PAT_UUID/running_pool/
  12. Lo único que resta es encender lás maquinas virtuales, las cuales se pueden encender desde el OVM-manager, o para los desesperados directamente desde linea de comandos con:
    xm create $PATH_TO_VM/vm.cfg

Obviamente, con sus respectivas modificaciones, se puede lograr que estos pasos funcionen para un esquema iScsi, o inclusive solo para activar la SAN para cualquier sistema GNU/Linux sin necesidad de virtualización.

Dudas y/o comentarios son bienvenidos (y requeridos)!

Happy Hacking!

—–
Entrada generada por:
NataS::: The Lord of Chaos
Marcos Ricardo Schejtman Rubio <mschejtman@nekasys.com>

Anuncios

Las aplicaciones montadas con ADF proporcionan todo lo ideal para un desarrollador y las empresas en general. Son bonitas, muy interactivas, sencillas de desarrollar, altamente configurables y extremadamente poderosas. De igual forma, Weblogic proporciona la capa del servidor de aplicaciones para poder interactuar con cualquier recurso, dando la libertad de configurar cada uno de los elementos que tengamos.

Oracle Access Manager proporciona integración ante las aplicaciones desplegadas en este poderoso servidor, y además ofrece integración casi nativa con ADF security, y con las aplicaciones desarrolladas en weblogic. A pesar de que existen herramientas para automatizar ciertos procesos, cierto es que, lo mejor es aprender a realizar las cosas de forma manual.

Este post ofrece los pasos necesarios para hacer dichas integraciones. Antes que nada es preciso comentar que la integración entre las aplicaciones de Weblogic y Oracle Access Manager, se usa utilizando tanto un reverse proxy web (en el cual se monta el WebGate), como haciendo uso de un provider. Esto es para poder gestionar las peticiones y manejar de forma interna las sesiones. Ahora si, para poder autenticar aplicaciones usando Oracle Access Manager, debemos realizar lo siguiente:

  1. Antes que nada se debe crear la entrada del Access Gate que manejará las peticiones mediante el webProxy y el provider que se instala en WebLogic.
  2. Generar las políticas que se requieran, y mediante las mismas configurar los recursos y el método de autenticado que utilizarán
  3. Agregar y configurar el provider de Weblogic de OAM (OAM Identity Asserter), para Weblogic 11g en adelante, este provider ya esta instalado y solo es necesario configurarlo, en Weblogic 10 y previas, se requiere descargar desde la página de Oracle e instalarlo. Durante la configuración debemos asergurarnos de realizar lo siguiente:
    • Marcarlo como REQUIRED
    • Elegir ObSSOCookie como método de gestión de sesión
  4. Dependiendo la configuración de la aplicación, esta puede requerir además de un autenticado LDAP para obtener cierta información del usuario, de ser este el caso, el provider se debe configurar como SUFFICIENTE
  5. Todas las aplicaciones web, que se quieran integrar a Oracle Access Manager, deben modificar su archivo web.xml, para manejar como configuración de login la opción de CLIENT-CERT. El siguiente es un ejemplo de como se debe configurar esa sección:

    <login-config>
    <auth-method>CLIENT-CERT</auth-method>
    </login-config>
  6. Si vamos a integrarnos con ADF, debemos modificar la configuración del dominio de ADF security, la cual radica en el archivo jps-config.xml, es muy importante recalcar que la configuración que se debe modificar es la del dominio, no la que viene con cada una de las aplicaciones.
    Para realizar esta modificación haremos uso de WLST:

    • Ejecutar el archivo $BEA_DOMAIN/bin/setDomainEnv.sh
    • Desplazarnos hacia $WL_SERVER/common/bin y ejecutar el archivo wlst.sh
    • Una vez dentro, nos conectaremos hacia el Admin Node del dominio: connect(‘username’,’password’,’t3://servidor:puerto’);
    • Ya autenticados, agregaremos la configuración de oam, usando la siguiente sintaxis: addOAMSSOProvider(loginuri=”/${app.context}/adfAuthentication”,
      logouturi=”/oamsso/logout.html”);
  7. Debemos hacer que weblogic tome los cambios, para esto reiniciamos las maquinas asociadas al dominio que se configuro, en el caso de un clúster es preciso reiniciar el Admin y los Managed Servers
  8. Finalmente y/o a la par, se debe configurar la capa Web que gestionará las peticiones necesarias. Para ello, montamos un OHS (Oracle HTTP Server) o apache, con el módulo de weblogic (mod_wl_ohs o mod_wl_22) o en su defecto con la configuración del módulo de proxy para reenrutar todas las petciones hacia el servidor de aplicaciones

Con lo anterior, ya tenemos configurado Weblogic y las aplicaciones ADF en nuestro esquema de Oracle Access Manager.

¿Dudas, comentarios, aclaraciones? Estamos para apoyarlos.

Happy Hacking!

—–
Entrada generada por:
NataS::: The Lord of Chaos
Marcos Ricardo Schejtman Rubio <mschejtman@nekasys.com>

Debido a unos adaptadores que tuve que realizar para facilitar la tarea de gestionar tareas repetitivas sobre Oracle Identity Manager (AKA OIM), me hice la tarea de abrir Jdeveloper (version 11.1.1.3) que tenía instalada, cuando mi sorpresa es que ya no se veía nada excepto una fea pantalla gris.
Las características de mi entorno gráfico son:
Display: 1600*900
Driver: ATI propietario
Xserver ver. 7.5
Distribucion: Debian GNU/Linux Sid-Experimental

Temiendo que todo se debía al nuevo driver de ATI (y puesto que no lo iba a desisntalar) hice el upgrade a la última versión del JDeveloper. Los resultados fueron similares.

Buscando en foros, recomendaban exportar la siguiente variable:
AWT_TOOLKIT=MToolkit
La cual tampoco tuvo resultados exitosos.

El problema radica en la resolución de mi monitor, que por alguna razón no es soportada por el JDeveloper, por ello, la solución se reduce en instalar xserver-xephyr de forma que podamos generar un Xserver con una menor resolución sobre la cual se ejecute JDeveloper. Para ello después de instalar Xephyr, debes agregar las siguientes lineas en el archivo <JDEVELOPER_HOME>/jdev/bin/jdev, justo antes de la ultima línea:

Xephyr :2 -ac -screen 1280x768 &
metacity --display :2 &
export DISPLAY=:2

Recomiendo iniciar con metacity, puesto que icewm no gestiona adecuadamente los bordes del jdeveloper.

Happy Hacking!

————-
Entrada generada por:
NataS::: The Lord of Chaos
Marcos Ricardo Schejtman Rubio <mschejtman@nekasys.com>

En muchas ocasiones, las aplicaciones web que son protegidas con Oracle Access Manager (AKA OAM), permiten al usuario final de descarga de documentos diferentes a un .txt (TEXTO), ejemplos de estas aplicaciones pueden ser Siebel, OBIEE, etc. Cuando se genera la configuración por default del AccessGate que protege dichos recursos podemos obtener mensajes de error al descargar los documentos como los siguientes:

  • The file cannot be found on server
  • El archivo no se pudo encontrar en el servidor
  • The file doesnt exist
  • … Y similares

Esto debe a como se gestionan dos valores que aunque parezcan insignificantes no lo son:

  • CachePragmaHeader
  • CacheControlHeader

Para entender como afectan estos valores a OAM necesitamos entender la definición del protocolo HTTP definido por la w3c (RFC-2616), en específico necesitamos entender las definiciones de 2 Campos de Encabezado (Header Fields):

  • Cache-Control, Especifícan el comportamiento que impede al caché interferir negativamente con la solicitud o la respuesta. Estas directivas suelen reemplazar los algoritmos de caché por defecto y son unidireccionales, es decir que una directiva en una solicitud no implica que la misma directiva se dé en la respuesta.
    Las directivas de control de cache se pueden dividir en las siguientes categorias:

    • Restricciones de que es cacheable, las cuales solo pueden imponerse por el servidor que origina las respuestas. Los posibles valores a usar son:
      • no-cache
      • public
      • private
    • Restricciones de lo que se puede guardar en cache, este puede establecerse por el cliente o el servidor:
      • no-store
    • Modificaciones al mecanismo de expiración. Los posibles valores a usar son:
      • max-age
      • s-maxage
    • Controles sobre la recarga o revalidación del cache, solo pueden establecerse por el agente cliente y sus posibles valores son:
      • must-revalidate
      • proxy-revalidate
    • Controles sobre las entidades de transformación del cache
      • no-transform
    • Diferentes extensiones al manejo del cache
  • Pragma, se utiliza para incluir directivas específicas de la implementación que podrían aplicarse a cualquier destinatario a lo largo de las peticiones y/o respuestas. Tiene las mismas opciones que las directiva cache-control en la sección referente a lo que es cacheable

En base a lo anterior podemos darnos cuenta que existen tres diferentes valores que afectan directamente el comportamiento de la descarga de documentos para el OAM:

  • public, indica que las respuestas pueden ser cacheadas por cualquier cache, inclusive si normalmente no lo son, o son cacheadas únicamente con el control no-share de la directiva de Autorización
  • private, indica que todo o parte del mensaje de respuesta esta dirigido a un usuario y por lo tanto no debe ser cacheado por un caché compartido. El uso de este control solo afecta el cache por lo que no asegura la privacidad del mensaje.
  • no-cache, Indica que el cache no se debe usar en las respuestas para satisfacer subsecuentes peticiones sin una previa validación con el servidor de origen. Esto permite al servidor de origen prevenir el cache aún cuando este ya ha sido configurado para su envío al cliente.

Lo expuesto anteriormente nos permite identificar el porque del error en la descarga de documentos desde recursos protegidos por OAM. Es por ello que según la naturaleza de los archivos se deben usar los controles public o private en las opciones de configuración CacheControlHeader y CachePragmaHeader del AccessGate.

Para más información pueden remitirse al RFC-2616, en la sección 13 y 14 del mismo.

Happy Hacking!

————-
Entrada generada por:
NataS::: The Lord of Chaos
Marcos Ricardo Schejtman Rubio <mschejtman@nekasys.com>

Durante algunos días estuvimos batallando con la integración entre WCI ver. 10.3 (AKA ALUI) con OAM ver. 10.1.4.3 para poder hacer SSO desde la página principal del usuario una vez que este se autenticó contra el ALUI, siendo el repositorio de sincronización de usuarios para el mismo, un Active Directory ver. 2008.
Buscando entre foros, documentación y uno que otro blog por fin pudimos llegar a tan ansiada integración, por lo que a continuación detallamos los pasos necesarios para poder proteger el WCI con políticas de OAM…
A gran escala los siguientes son los pasos que uno debe contemplar para poder integrar WCI con OAM en un esquema de Authenticación por Formulario:

  1. Obviamente tener instalado WCI y OAM
  2. Configurar el SSO para el portal de WCI
  3. Instalar y configurar un OHS que funcione como proxy para el WL donde esta deployado ALUI
  4. Configurar OAM
  5. Reiniciar servicios

Como se puede observar son varios los pasos necesarios, los cuales serán explicados mas a detalle en los próximos puntos. Para ello asumiremos que se tiene conocimiento medio-avanzado en la administración de WCI, OAM, WL entre otras.

Configuración en el ALUI

  • Crear y configurar un Servidor Remoto de Autenticación AD.
    • Establecer un nombre a Autentication Source Category, este nombre se ocupará más adelante
    • En el link “Sincronization” del “Authentication Source”, de los soportes que ofrece el Autenticador elegir: “Sincronization with Authentication Partner
    • De los diferentes partners de Autenticado elegir “SSO Authentication Source”
  • Configurar el SSO para el WCI, para ello:
    • Abrir el archivo $BEA_HOME/alui/settings/configuration.xml y establecer las siguientes líneas:
    • <component name="portal:SystemProperties" type="http://www.plumtree.com/config/component/types/portal/systemproperties">
      <!-- ... -->
      <setting name="ServerName">
      <value xsi:type="xsd:string">proxy.server.webgate</value>
      </setting>
      <setting name="HTTPPort">
      <value xsi:type="xsd:integer">8080</value>
      </setting>
      <setting name="SSOVirtualDirectoryPath">
      <value xsi:type="xsd:string">/portal/</value>
      </setting>
      <!-- ... -->
      </component>

    • Abrir el archivo $BEA_HOME/alui/settings/portal/portalconfig.xml y establecer las siguientes líneas:

    • <!-- ... -->
      <!-- Se establece el valor de 3 para el Netpoint -->
      <setting name="SSOVendor">
      <value xsi:type="xsd:integer">3</value>
      </setting>

      <!-- El dominio de nuestra cookie, este debe coincidir con el que establezcamos en la configuración del WebGate  -->
      <setting name="CookieDomain">
      <value xsi:type="xsd:string">.mi.dominio.orgx</value>
      </setting>
      <setting name="CookiePath">
      <value xsi:type="xsd:string">/</value>
      </setting>

      <!-- Se establece a 1 si queremos que las cookies vayan via SSL, de otra forma lo mantenemos en 0 -->
      <setting name="SSOCookieIsSecure">
      <value xsi:type="xsd:integer">0</value>
      </setting>

      <!-- El siguiente determina si se debe enviar la información de autenticado a los diferentes portlets integrados en el WCI-->
      <setting name="CaptureBasicAuthenticationForPortlets">
      <value xsi:type="xsd:string">1</value>
      </setting>
      <!-- ... -->

Instalación y configuración del WebProxy

  • Descargamos las utilidades de WebTier11g para el SO y arquitectura que dispongamos
  • Durante el proceso de instalación únicamente elegiremos el OHS
  • Editar el archivo de configuración $BEA_HOME/instances/$INSTANCE/config/OHS/$OHS_INSTANCE/mod_wl_ohs.conf el cual maneja el módulo de weblogic para OHS y redireccionar las rutas de los portlets, así como las rutas de inicio hacia el host de weblogic (o clúster según sea el caso), Ej:
  • <Location /Natas>
    SetHandler weblogic-handler
    PathTrim /NataS
    PathPrepend /portal
    WebLogicHost alui.mi.dominio.org
    WebLogicPort 7010
    </Location>

  • Editar el archivo de configuración $BEA_HOME/instances/$INSTANCE/config/OHS/$OHS_INSTANCE/httpd.conf para habilitar y configurar el mod_proxy y redireccionar las rutas del IDC (UCM)
  • <IfModule mod_proxy.c>
    ProxyRequests Off
    ProxyPreserveHost On
    ProxyPass /imageserver http://alui.mi.dominio.org/imageserver
    ProxyPassReverse /imageserver http://alui.mi.dominio.org/imageserver

    ProxyPass /idc http://alui.mi.dominio.org/idc
    ProxyPassReverse /idc http://alui.mi.dominio.org/idc
    </IFModule>

Configuración de OAM

  • Generar el Host Identifier del WebProxy que instalamos anteriormente.
  • Crear la entrada del AccessGate sobre el AccessServer del OAM, como parámetros principales tenemos:
    • Access Management Service: On
    • Primary HTTP Cookie Domain: .mi.dominio.org
    • Preferred HTTP Host: SERVER_NAME
      Este se establece de esa forma si el WebGate esta sobre un servidor que usa VirtualHosts, de otra forma es necesario usar el valor establecido en el Host Identifier
    • Deny On Not Protected: Off
    • CachePragmaHeader: public
      Si el servidor permite descarga de archivos se deben marcar los headers como public.
    • CacheControlHeader: public
  • Generar el esquema de autenticado que usara el ALUI, uno es el “Anonymous” y el otro el que necesitemos
  • Instalar el WebGate en el servidor que se configuro de WebProxy
  • Generar la política de Dominio que protegerá el portal, a continuación se definen los pasos:
    • Establecer un nombre para la política
    • Establecer los recursos que protegerá la política, principalmente protegeremos:
      • /portal
      • /portal/server.pt
    • Generar una Authorization-Rule que permita el acceso a todos (si así es el caso)
    • Generar la Default-Rule para el portal, en esta se establecerá como esquema de Autenticado el Anónimo, ya que el portal es público por default.
      En la Authorization Expression de la Default Rule usaremos la creada en el paso anterior y como Action devolveremos la variable definida en el archivo del ALUI y de donde la obtendrá
    • Generamos una política con las siguientes características:
      • Name: Allow Access
      • Description: Allow Access to Portal
      • Resource Type: http
      • Resource Operation(s): GET,POST
      • Resource: all
      • URL Pattern: {SSOServlet[;!]*,SSOServlet/…/*,SSOServlet}
      • Host Identifiers: all
      • Authentication Rule -> General -> Authentication Scheme: El_Esquema_de_Protección
      • Authentication Rule -> Actions -> On Success: Regresa las variables seteadas con el valor necesitado
    • Activamos las políticas establecidas
    • Reiniciamos servicios del ALUI y WebProxy

    Con esto tenemos un WCI integrado a nuestro OAM.
    Happy Hacking.

    —–
    Entrada generada por:
    NataS::: The Lord of Chaos
    Marcos Ricardo Schejtman Rubio <mschejtman@nekasys.com>

No tiene mucho que salio el conector de OIM (Oracle Identity Manager) para conectarse con RSA ver. 7.1.
Entre las nuevas características, prevalece que ya no se necesita de un Remote Manager en el servidor de RSA para poder gestionar los comandos de aprovisionamiento, esto gracias a que a partir de la version 7.0 de RSA el esquema fue modificado de cliente-servidor a un esquema basado en servicios Web (bendito sea SOA).
Pues bien a continuación se despliegan los pasos necesarios para la integración, en parte porque la documentación esta incompleta, y en parte porque existen diferentes issues cuando se tiene desplegado el OIM en el Weblogic. Para empezar, un acercamiento a las versiones que se usarán en esta entrada:

  • OIM ver. 9.1.0.2 BP 11
  • WebLogic 10.3
  • Oracle Enterprise Linux ver. 5.4
  • RSA Connector: 9.1
  • RSA ver. 7.1
  1. Para empezar es necesario descargar el conector, sin embargo este conector no esta disponible desde la página de Oracle, sino como un parche que se obtiene desde Metalink, el Patch ID es el 9622543.
  2. Instalar el conector desde el la consola de administración web
  3. Seguir todos los pasos de la documentación para conectarse, las modificaciones vienen a continuación
  4. Como parte de los archivos a copiar, es necesario uno denominado wlfullclient.jar, este se genera, instalando el java SDK ver. 1.5 en el servidor de RSA y tecleando los siguientes comandos:
    cd RSA_AM_HOME/appserver/weblogic/server/lib/
    java -jar ../../../modules/com.bea.core.jarbuilder_1.0.0.0.jar -profile wlfullclient
  5. En general esos son los pasos necesarios para poder realizar la conexion con RSA, sin embargo cuando uno realiza una prueba, o inclusive cuando se comienza con la reconciliación de LookUp’s, salga un error de SSL HandShake a pesar de que el certificado de la CA fue dado de alta exitosamente, el error es:
    DEBUG,19 nov 2010 13:26:49,102,[OIMCP.RSAM],oracle.iam.connectors.rsaauthmgr.usermgmt.tasks.RSALookupRecon : init():: STARTED
    DEBUG,19 nov 2010 13:26:49,121,[OIMCP.RSAM],oracle.iam.connectors.common.vo.ITResource : ITResource:: STARTED
    DEBUG,19 nov 2010 13:26:49,146,[OIMCP.RSAM],oracle.iam.connectors.common.vo.ITResource : ITResource : IT Resource Key :4
    DEBUG,19 nov 2010 13:26:49,165,[OIMCP.RSAM],oracle.iam.connectors.common.vo.ITResource : ITResource:: FINISHED
    DEBUG,19 nov 2010 13:26:49,182,[OIMCP.RSAM],oracle.iam.connectors.common.dao.OIMUtil : OIMUtil():: STARTED
    DEBUG,19 nov 2010 13:26:49,264,[OIMCP.RSAM],oracle.iam.connectors.common.dao.OIMUtil : OIMUtil():: FINISHED
    DEBUG,19 nov 2010 13:26:49,266,[OIMCP.RSAM],oracle.iam.connectors.common.dao.OIMUtil : getLookUpMap():: STARTED
    DEBUG,19 nov 2010 13:26:49,266,[OIMCP.RSAM],oracle.iam.connectors.common.dao.OIMUtil : getLookUpMap() : LookUpName : Lookup.RSA.AuthManager.Configuration
    DEBUG,19 nov 2010 13:26:49,280,[OIMCP.RSAM],oracle.iam.connectors.common.dao.OIMUtil : getLookUpMap():: FINISHED
    DEBUG,19 nov 2010 13:26:49,280,[OIMCP.RSAM],oracle.iam.connectors.common.dao.OIMUtil : getLookUpMap():: STARTED
    DEBUG,19 nov 2010 13:26:49,280,[OIMCP.RSAM],oracle.iam.connectors.common.dao.OIMUtil : getLookUpMap() : LookUpName : Lookup.RSA.AuthManager.LookupReconMapping
    DEBUG,19 nov 2010 13:26:49,288,[OIMCP.RSAM],oracle.iam.connectors.common.dao.OIMUtil : getLookUpMap():: FINISHED
    DEBUG,19 nov 2010 13:26:49,288,[OIMCP.RSAM],oracle.iam.connectors.common.dao.OIMUtil : getLookUpMap():: STARTED
    DEBUG,19 nov 2010 13:26:49,288,[OIMCP.RSAM],oracle.iam.connectors.common.dao.OIMUtil : getLookUpMap() : LookUpName : Lookup.RSA.AuthManager.Constants
    DEBUG,19 nov 2010 13:26:49,296,[OIMCP.RSAM],oracle.iam.connectors.common.dao.OIMUtil : getLookUpMap():: FINISHED
    DEBUG,19 nov 2010 13:26:49,296,[OIMCP.RSAM],oracle.iam.connectors.common.dao.OIMUtil : getLookUpMap():: STARTED
    DEBUG,19 nov 2010 13:26:49,296,[OIMCP.RSAM],oracle.iam.connectors.common.dao.OIMUtil : getLookUpMap() : LookUpName : Lookup.RSA.AuthManager.ITResourceMapping
    DEBUG,19 nov 2010 13:26:49,303,[OIMCP.RSAM],oracle.iam.connectors.common.dao.OIMUtil : getLookUpMap():: FINISHED
    DEBUG,19 nov 2010 13:26:49,306,[OIMCP.RSAM],oracle.iam.connectors.common.vo.ScheduledTask : getScheduledTaskDetails():: STARTED
    DEBUG,19 nov 2010 13:26:49,315,[OIMCP.RSAM],oracle.iam.connectors.common.vo.ScheduledTask : getScheduleTaskKey():: STARTED
    DEBUG,19 nov 2010 13:26:49,322,[OIMCP.RSAM],oracle.iam.connectors.common.vo.ScheduledTask : getScheduleTaskKey():: FINISHED
    DEBUG,19 nov 2010 13:26:49,334,[OIMCP.RSAM],oracle.iam.connectors.common.vo.ScheduledTask : getScheduledTaskDetails():: FINISHED
    DEBUG,19 nov 2010 13:26:49,336,[OIMCP.RSAM],oracle.iam.connectors.common.vo.ScheduledTask : validateMandatoryTaskAttrs():: STARTED
    DEBUG,19 nov 2010 13:26:49,337,[OIMCP.RSAM],oracle.iam.connectors.common.vo.ScheduledTask : validateMandatoryTaskAttrs():: FINISHED
    DEBUG,19 nov 2010 13:26:49,338,[OIMCP.RSAM],oracle.iam.connectors.common.dao.OIMUtil : getITResourceKey():: STARTED
    DEBUG,19 nov 2010 13:26:49,338,[OIMCP.RSAM],oracle.iam.connectors.common.dao.OIMUtil : getITResourceKey() : ITResource Name = RSA Server Instance
    DEBUG,19 nov 2010 13:26:49,348,[OIMCP.RSAM],oracle.iam.connectors.common.dao.OIMUtil : getITResourceKey() : tcresultSet.getRowCount() = 1
    DEBUG,19 nov 2010 13:26:49,348,[OIMCP.RSAM],oracle.iam.connectors.common.dao.OIMUtil : getITResourceKey():: FINISHED
    DEBUG,19 nov 2010 13:26:50,521,[OIMCP.RSAM],oracle.iam.connectors.rsaauthmgr.common.connection.RSAConnection : createConnection() : CommandTarget initialized...
    ERROR,19 nov 2010 13:26:53,222,[OIMCP.RSAM],====================================================
    ERROR,19 nov 2010 13:26:53,222,[OIMCP.RSAM],oracle.iam.connectors.rsaauthmgr.common.connection.RSAConnection : createConnection() : javax.net.ssl.SSLException: Received fatal a
    lert: bad_record_mac
    ERROR,19 nov 2010 13:26:53,222,[OIMCP.RSAM],====================================================

    ERROR,19 nov 2010 13:26:53,224,[OIMCP.RSAM],================= Start Stack Trace =======================
    ERROR,19 nov 2010 13:26:53,224,[OIMCP.RSAM],oracle.iam.connectors.rsaauthmgr.common.connection.RSAConnection : createConnection()
    ERROR,19 nov 2010 13:26:53,224,[OIMCP.RSAM],javax.net.ssl.SSLException: Received fatal alert: bad_record_mac
    ERROR,19 nov 2010 13:26:53,224,[OIMCP.RSAM],Description : javax.net.ssl.SSLException: Received fatal alert: bad_record_mac
    ERROR,19 nov 2010 13:26:53,224,[OIMCP.RSAM],com.rsa.common.SystemException: javax.net.ssl.SSLException: Received fatal alert: bad_record_mac
    at com.rsa.webservice.SOAPCommandTarget.remoteMethod
    (SOAPCommandTarget.java:198)
    at com.rsa.webservice.SOAPCommandTarget.executeCommand
    (SOAPCommandTarget.java:136)
    at com.rsa.command.TargetableCommand.execute
    (TargetableCommand.java:237)
    at com.rsa.authn.LoginCommand.execute
    (LoginCommand.java:591)
    at com.rsa.command.ConnectionFactory$AuthenticatedTarget.login
    (ConnectionFactory.java:641)
    at com.rsa.command.ConnectionFactory$ConnectionImpl.connect
    (ConnectionFactory.java:827)
    at com.rsa.command.ConnectionFactory$ConnectionImpl.connect
    (ConnectionFactory.java:809)
    at oracle.iam.connectors.rsaauthmgr.common.connection.RSAConnection.createConnection
    (Unknown Source)
    at oracle.iam.connectors.rsaauthmgr.usermgmt.tasks.RSALookupRecon.execute
    (Unknown Source)
    at com.thortech.xl.scheduler.tasks.SchedulerBaseTask.run
    (Unknown Source)
    at com.thortech.xl.scheduler.core.quartz.QuartzWrapper$TaskExecutionAction.run
    (Unknown Source)
    at weblogic.security.acl.internal.AuthenticatedSubject.doAs
    (AuthenticatedSubject.java:321)
    at weblogic.security.service.SecurityManager.runAs
    (Unknown Source)
    at weblogic.security.Security.runAs
    (Security.java:41)
    at Thor.API.Security.LoginHandler.weblogicLoginSession.runAs
    (Unknown Source)
    at com.thortech.xl.scheduler.core.quartz.QuartzWrapper.execute
    (Unknown Source)
    at org.quartz.core.JobRunShell.run
    (JobRunShell.java:178)
    at org.quartz.simpl.SimpleThreadPool$WorkerThread.run
    (SimpleThreadPool.java:477)
    Caused by: javax.net.ssl.SSLException: Received fatal alert: bad_record_mac
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0
    (Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance
    (NativeConstructorAccessorImpl.java:39)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
    (DelegatingConstructorAccessorImpl.java:27)
    at java.lang.reflect.Constructor.newInstance
    (Constructor.java:513)
    at com.rsa.webservice.SOAPCommandTarget.remoteMethod
    (SOAPCommandTarget.java:182)
    ... 17 more

    ERROR,19 nov 2010 13:26:53,224,[OIMCP.RSAM],================= End Stack Trace =======================

  6. Para habilitar el debug de SSL y ver con mas detalle el error es necesario incluir la siguiente linea en el arranque del servidor que gestiona el nodo del OIM: -Djavax.net.debug=ssl
  7. El error se da puesto que el servidor de RSA reinicializa la conexión. Para solucionarlo debemos recordar un par de conceptos referentes a la JSSE y que tienen que ver con el apego al RFC-5746.
  8. La solución consiste en establecer el modo de comunicación del WebLogic hacia Legacy, para ello se deben settear los siguientes parametros en el arranque de WebLogic:

    -Dhttps.protocols=SSLv3,TLSv1
    -Dsun.security.ssl.allowLegacyHelloMessages=true
    -Dsun.security.ssl.allowUnsafeRenegotiation=true
  9. La desventaja de esta solución es que la comunicación entre ambos servidores es propensa a un ataque de MITM, pero de momento es la solución al error de bad_record_mac
  10. Finalmente solo es necesario reiniciar el servidor donde esta deployado el OIM

La solución de JSSE, es extensible hacia cualquier comunicación entre servidores que reinicialice las conexiones SSLv3 o TLSv1.

Dudas y/o comentarios son bienvenidos.

Happy Hacking!

—–
Entrada generada por:
NataS::: The Lord of Chaos
Marcos Ricardo Schejtman Rubio <mschejtman@nekasys.com>

Por razones que de momento no vienen al caso, tuvimos que ponernos a la tarea de revisar la última versión de Oracle Access Manager 10g (AKA OAM) para poder realizar una integración con RSA Secure ID.

Recordando un poco podemos notar que en sí, el OAM esta compuesto por tres bloques:

  • Identity System: Gestiona el control (creación, mantenimiento y eliminación) de grupos, usuarios (identidades), organizaciones y las relaciones entre estos. Determina mediante determinadas funciones y aplicaciones los cambios dinámicos en base a roles, grupos, etc para determinar quien tiene acceso a que componentes dentro de la organización. Este bloque esta compuesto por los siguientes componentes:
    • Oracle Identity Server (AKA OIS): Proporciona las aplicaciones a través de una interfaz Web para procesar todas las peticiones que tienen que ver con el manejo de usuarios, grupos y organizaciones. El OIS se comunica directamente con un servidor LDAP para guardar toda la información relativa a las identidades, sin embargo el usuario no interactúa directamente con el OIS, pasa a través de un WebPass.
    • Oracle WebPass: Es un plug-in para los servidores Web más comunes que funciona como puerta de acceso entre el usuario, el servidor web y el OIM.
  • Access System: Proporciona las funciones necesarias para centralizar la autenticación, autorización, permite gestionar la auditoría, el Single Sign-ON (AKA SSO) y el control de accesos a los recursos de la empresa. Los componentes de OAM que dan cabida a este bloque son:
    • Policy Manager: Proporciona una interfaz web desde la cual se pueden manejar y crear políticas de acceso. Se comunica con el servidor de LDAP para la escritura de las políticas de acceso y con el Access Server mediante el Oracle Access Protocol (AKA OAP) para actualizarlo cuando las políticas lo indican.
    • Oracle Access Server (AKA. OAS): Es el componente clave durante los siguientes procesos:
      • Autenticación: Determina que método es requerido para cual recurso y obtiene las credenciales desde el servidor LDAP regresando una respuesta HTTP al cliente (WebGate o AccessGate).
      • Autorización: Involucra obtener información y validar el acceso basado en las políticas establecidas por el Policy Manager y en la identidad del usuario según el LDAP.
    • Oracle WebGate: Es un plug-in que se instala en los servidores Web y que intercepta todas las peticiones HTTP que mandan los usuarios y las reenvías hacia el OAS para que realice el proceso de autenticación y autorización.
  • Servicios de Integración: Mediante el uso de API’s y de clientes como AccessGate permite extender las funcionalidades de OAM hacia aplicativos no basados en Web, como aplicaciones de terceros y “Made in Home”.

Dentro de la media que es posible descargar del sitio de Oracle, podemos notar que el instalador de WebPass viene preparado para Apache 2.0 pero no para Apache 2.2 que es la versión que viene preparada para instalar con los CD’s o DVD’s de OEL ver. 5.x

Debido a lo anterior existen dos opciones… instalar una versión soportada de apache para OEL ver. 5.x o instalar con los siguientes pasos sobre Apache 2.2:

  1. Instalaremos de forma normal el Identity Server. El método de comunicación se deja a criterio, pero se debe considerar que si los servicios radicará en diferentes servidores, la comunicación no se debe dejar abierta. De igual forma si se piensa instalar en un entorno H-A, no se pueden mezclar diferentes transportes por lo que se debe pensar en un método con cifrado.
  2. Debido al kernel que usa el OEL 5.4, es necesario comentar la linea donde se establece el valor de la variable LD_ASSUME_KERNEL, dentro del script de arranque del OIS, el cual esta ubicado en: $OIS_HOME/identity/oblix/apps/common/bin/start_ois_server. o ejecutar el script con terminación nptl
  3. Arrancar el OIS con el script anterior y detendremos el Apache con el script /etc/init.d/httpd.
  4. En el servidor donde esta instalado el Apache, instalaremos el WebPass para  Apache2.0. y así como en el punto de instalación del OIS, elegiremos el método de comunicación con el OIS (recordemos que deben ser el mismo). En la parte de configuración automática del servidor web elegiremos que sí.
  5. Debemos descargar el OAM BP03 (Patch ID: 9402573) desde la página de Metalink y detener el OIS con el script $OIS_HOME/identity/oblix/apps/common/bin/stop_ois_server.
  6. Descomprimiremos el archivo y dentro los parches referentes al Identity Server y al WebPass  (Oracle_Access_Manager10_1_4_3_0_BP03_Patch_linux_Identity_Server.zip, Oracle_Access_Manager10_1_4_3_0_BP03_Patch_linux_APACHE22_WebPass.zip).
  7. Entraremos a la carpeta $PATCH_HOME/Oracle_Access_Manager10_1_4_3_0_BP03_Patch_linux_Identity_Server
    _binary_parameter
    y ejecutaremos el script patchinst, el cual nos solicitara como único parámetro la ruta de instalación del OIS ($OIS_HOME/identity).
  8. Ahora viene lo interesante, cuando uno intenta ejecutar los pasos anteriores para el WebPass, salta un error referente a que ese no fue el Servidor con el cual se instaló originalmente el WebPass. Así que para solventarlo entraremos a la carpeta $PATCH_HOME/Oracle_Access_Manager10_1_4_3_0_BP03_Patch_linux_APACHE22
    _WebPass_binary_parameter
    y descomprimiremos (usando el comando tar xf) los siguientes archivos: createorig.tar, Oracle10.1.4.3.0.03_linux_WebPass_0.tar y Oracle10.1.4.3.0.03_linux_WebPass_1.tar.
  9. Lo anterior crea la carpeta oblix, lo que haremos será copiar cada una de las carpetas que están dentro hacia $WEBPASS_HOME/identity/oblix: cp -rf  $PATCH_HOME/Oracle_Access_Manager10_1_4_3_0_BP03_Patch_linux_APACHE22
    _WebPass_binary_parameter/oblix/
    [^.]* $WEBPASS_HOME/identity/oblix.
    En caso que pida confirmación usar unalias o \cp.
  10. Una vez copiados ejecutaremos el script patchinst que radica en la carpeta $PATCH_HOME/Oracle_Access_Manager10_1_4_3_0_BP03_Patch_linux_APACHE22
    _WebPass_binary_parameter
    , el cual nos solicitará la ruita de instalación del WebPass: $WEBPASS_HOME/identity/oblix.
  11. Finalmente iniciar todos los servicios (OIS y Apache)

Con dichos pasos serán capaces de tener WebPass + Apache2.2 + OEL5.4 y comenzar con la configuración relativa al servidor LDAP, atributos, administradores etc.

—–
Entrada generada por:
NataS::: The Lord of Chaos
Marcos Ricardo Schejtman Rubio <mschejtman@nekasys.com>