Archivos de la categoría ‘IDM’

Hace ya algún tiempo, el cliente con el que estábamos realizó su instalación de Service Pack de RSA AM 7.1, en específico instalaron el SP2. Pues bien, inmediatamente comenzó a salir un error, el cual era parte de la API de integración de RSA (el famoso commandClient), a grandes rasgos el error era:

com.rsa.common.UnexpectedDataStoreException: unable to select user from IMS_PRINCIPAL java.sql.SQLException: ORA-00904: "IMS_PRINCIPAL"."EXUID": invalid identifier

Este es un bug de RSA debido a que con el upgrade modifican la tabla IMS_PRINCIPAL lo que provoca el error antes mencionado (pueden validarlo entrando directamente a la base de datos de RSA).
La solución es muy sencilla, consiste en:

  1. Actualizar a un nuevo Service Pack (si mal no recuerdo al día de hoy el último existente es el SP-4)
  2. Debido a la actualización del service pack necesitamos actualizar unos cuantos archivos en el dominio del OIM, esto para que tome los nuevos cambios y no nos marque errores. Los archivos recordemos debemos copiarlos a $DOMAIN_HOME/lib y $WLS_HOME/server/lib:
    am-client.jar am-server.jar ims-client.jar iScreen-ognl-1-1-0rsa-2.jar
    ims-server.jar iScreen-1-1-0rsa-2.jar ims-server-0.jar
  3. Reiniciamos el dominio del OIM

Con esos sencillos pasos tenemos funcional nuestro conector de OIM hacia RSA 7.1 una vez mas.

Dudas, comentarios, sugerencias y/o quejas son siempre bien recibidas!

Happy Hacking!

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

Anuncios

Los cambios introducidos en la arquitectura de IDM11g nos llevan a atacar de otra forma los diferentes problemas que se pueden tener. De igual forma, el corto tiempo que lleva la versión en el mercado y su dependencia con otras herramientas, hacen difícil para quienes van empezando, que puedan detectar por donde atacar los problemas. Es por ello que en esta entrada, analizaremos diferentes errores en el arranque de nuestro dominio de IDM, las causas y su solución.

  1. Error en la inicialización de MDS
    Mensaje de Error:
    oracle.mds.config.MDSConfigurationException: MDS-01330: no se ha podido cargar el documento de configuración de MDS
    MDS-01329: no se ha podido cargar el elemento "persistence-config"
    MDS-01370: Configuración de almacén de datos para metadata-store-usage "ApmRoot" no válida.
    ORA-06550: línea 1, columna 12:
    PLS-00201: identifier 'MDS_INTERNAL_SHREDDED.GETREPOSITORYVERSION' must be declared
    ORA-06550: línea 1, columna 7:

    Causa: Posible mala configuración en el datasource que conecta a la base de datos, en específico del username.
    Solucion: Modificar el archivo $IDM_DOMAIN/config/jdbc/apm-server-mds-jdbc.xml, en específico la propiedad “user”, de forma que quede algo como:
    <property>
    <name>user</name>
    <value>DEV_MDS</value>
    </property>
  2. Error en la inicialización del clúster coherence
    Mensaje de Error:
    ####<20/04/2011 12:24:32 AM CDT> <Error> <Coherence> <alien-natas> <AdminServer> <Logger@251282735 3.5.3/465p2> <<anonymous>> <> <> <1303277072116> <BEA-000000> <2011-04-20 00:24:32.116/300.434 Oracle Coherence GE 3.5.3/465p2 <Error> (thread=Cluster, member=n/a): Node /192.168.58.1:9095 is not allowed to create a new cluster; WKA list: [alien-natas.nekasys.com/127.0.0.1:9095]>
    ####<20/04/2011 12:24:32 AM CDT> <Error> <Coherence> <alien-natas> <AdminServer> <Logger@251282735 3.5.3/465p2> <<anonymous>> <> <> <1303277072156> <BEA-000000> <2011-04-20 00:24:32.155/300.473 Oracle Coherence GE 3.5.3/465p2 <Error> (thread=[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)', member=n/a): Error while starting cluster: java.lang.RuntimeException: Failed to start Service "Cluster" (ServiceState=SERVICE_STOPPED, STATE_ANNOUNCE)

    Causa: OAM 11g utiliza Coherence para mantener las sesiones. Coherence a su vez utiliza dos métodos para inicializar el clúster cache: Multicast Unicast. La libreria de coherence sobre OAM11g usa unicast para establecer el clúster, y únicamente permite a la propia maquina iniciarlo (hostname y localhost). Este problema se puede por tanto presentar en dos casos:

    1. OAM en H-A
    2. Maquina con múltiples direcciones IP

    Solucion: Editar la lista de WKA para OAM, por ello es necesario:

    1. Copiar a alguna ruta temporal la libreria de coherence para OAM, $IDM_DOMAIN/config/fmwconfig/mbeans/oam/coherence.jar
    2. Descomprimir el jar que copiamos: jar xf coherence.jar, una vez descomprimido eliminarlo
    3. Abrir el archivo tangosol-coherence.xml
    4. Editar el archivo donde esta la configuración de la WKA, acorde al número de nodos, interfaces o direcciones IPs que queramos permitir, el siguiente es un ejemplo:
      <well-known-addresses>
      <socket-address id="1">
      <address system-property="tangosol.coherence.wka"></address>
      <port system-property="tangosol.coherence.wka.port">9095</port>
      </socket-address>
      <socket-address id="2">
      <address system-property="tangosol.coherence.wka2"></address>
      <port system-property="tangosol.coherence.wka2.port">9095</port>
      </socket-address>
      <socket-address id="3">
      <address system-property="tangosol.coherence.wka3"></address>
      <port system-property="tangosol.coherence.wka3.port">9095</port>
      </socket-address>
      <socket-address id="4">
      <address system-property="tangosol.coherence.wka4"></address>
      <port system-property="tangosol.coherence.wka4.port">9095</port>
      </socket-address>
      <socket-address id="5">
      <address system-property="tangosol.coherence.wka5"></address>
      <port system-property="tangosol.coherence.wka5.port">9095</port>
      </socket-address>
      </well-known-addresses>
    5. Generar el jar, con el archivo ya modificado.
    6. Copiar y sobreescribir el jar en las siguientes rutas:
      $IDM_DOMAIN/config/fmwconfig/mbeans/oam/
      $IDM_DOMAIN/servers/AdminServer/tmp/_WL_user/oam_admin_11.1.1.3.0/g5iha/APP-INF/lib (Aqui el nombre depende de la aleatoriedad asi que deben validarlo en su instalacion).
    7. Por último debemos agregar las siguientes opciones a la variable EXTRA_JAVA_PROPERTIES en el archivo $IDM_DOMAIN/bin/setDomainEnv.sh (como sugerencia, que este en la misma línea donde el instalador hizo las modificaciones para agregar la configuración de coherence):
      -Dtangosol.coherence.wka=home.nekasys.com -Dtangosol.coherence.wka2=clon.nekasys.com -Dtangosol.coherence.wka3=vmnet1.nekasys.com -Dtangosol.coherence.wka4=vmnet8.nekasys.com -Dtangosol.coherence.wka5=ipad.nekasys.com -Dtangosol.coherence.wka.port=9095 -Dtangosol.coherence.wka2.port=9095 -Dtangosol.coherence.wka3.port=9095 -Dtangosol.coherence.wka4.port=9095 -Dtangosol.coherence.wka5.port=9095

      En el ejemplo previo se puede notar que se agregaron seis interfaces, la configuración variara según el numero de interfaces de la máquina o nodos que se agreguen en el clúster. A modo de ejemplo, la variable quedaría definida como:
      EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Dsoa.archives.dir=${SOA_ORACLE_HOME}/soa -Dsoa.oracle.home=${SOA_ORACLE_HOME} -Dsoa.instance.home=${DOMAIN_HOME} -Dtangosol.coherence.clusteraddress=227.7.7.9 -Dtangosol.coherence.clusterport=9778 -Dtangosol.coherence.log=jdk -Dtangosol.coherence.wka=home.nekasys.com -Dtangosol.coherence.wka2=clon.nekasys.com -Dtangosol.coherence.wka3=vmnet1.nekasys.com -Dtangosol.coherence.wka4=vmnet8.nekasys.com -Dtangosol.coherence.wka5=ipad.nekasys.com -Dtangosol.coherence.wka.port=9095 -Dtangosol.coherence.wka2.port=9095 -Dtangosol.coherence.wka3.port=9095 -Dtangosol.coherence.wka4.port=9095 -Dtangosol.coherence.wka5.port=9095 -Djavax.xml.soap.MessageFactory=oracle.j2ee.ws.saaj.soap.MessageFactoryImpl -Djava.protocol.handler.pkgs=${PROTOCOL_HANDLERS} -Dweblogic.transaction.blocking.commit=true -Dweblogic.transaction.blocking.rollback=true -Djavax.net.ssl.trustStore=${WL_HOME}/server/lib/Nekasys.jks"
    8. Listo, pueden iniciar normalmente su dominio sin excepciones de coherence ni en el OAM
  3. Error en el refresh de sockets al iniciar Coherence
    Mensaje de Error:
    ####<21/04/2011 09:18:23 PM CDT> <Error> <Coherence> <alien-natas> <AdminServer> <Logger@9267279 3.5.3/465p2> <<anonymous>> <> <> <1303438703399> <BEA-000000> <2011-04-21 21:18:23.398/274.616 Oracle Coherence GE 3.5.3/465p2 <Error> (thread=PacketSpeaker, member=1): Stopping cluster due to unhandled exception: com.tangosol.net.messaging.ConnectionException: Unable to refresh sockets: [UnicastUdpSocket{State=STATE_OPEN, address:port=192.168.2.251:9095}, TcpSocketAccepter{State=STATE_OPEN, ServerSocket=192.168.2.251:9095}]; last failed socket: UnicastUdpSocket{State=STATE_OPEN, address:port=192.168.2.251:9095}

    Causa: Una de las interfaces de red del equipo esta activa, sin embargo no tiene asociada una dirección IP.
    Solucion: Asignar una dirección IP a la interfaz, o desactivar la misma.

Esos fueron algunos de los issues con los que nos hemos topado, y las soluciones a los mismos.
De igual forma si tienen alguna duda y/o comentario no duden en escribirnos.

Happy Hacking!

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

Soy un amante a utilizar eficientemente los recursos de las computadoras. En general nunca instalalo cosas que puedan ocupar mas RAM de lo debido solo porque se ven “bonitas”, por ejemplo, el reproductor de audio que tiene la Laptop del trabajo es vía comandos y funciona por un demonio (MPD), mi entorno gráfico usa IceWM y en general para cada aplicación trato de usar lo necesario y solo eso. Dicho eso pasemos al tema en cuestion.

Si bien las máquinas virtuales nos permiten portar de un lado a otro todo un ambiente, también es cierto que implican un desperdicio en recursos, más aun cuando estamos hablando de que se montan en computadoras con “moderados” recursos. Citado lo anterior y puesto que me disponía a realizar toda una demo de lo que es Oracle IDM11g, sus características e integración en un todo (para más información visita aquí), me ví en la tarea de realizar la instalación sobre mi sistema Operativo (AKA Debian GNU/Linux). Las siguientes son las características del entorno y de lo que instale:

  • Procesador: 2 Intel i7
  • RAM: 8GB
  • Sistema Operativo: Debian GNU/Linux sid-experimental
  • Base de datos: Oracle Database 11.2.0.1.0
  • Weblogic: Weblogic 10.3.3
  • SOA Suite: Ver. 11.1.1.3
  • IDM: Ver. 11.1.1.3
  • IAM: Ver. 11.1.1.3

Sin más preámbulos vamos a los pasos necesarios:

  1. Preparación del Entorno, debemos hacer algunas configuraciones previas en nuestro sistema para albergar la instalación, las siguientes son los comandos y/o modificaciones que se deben realizar:
    • Crear el archivo que marca el release de Redhat en el que estamos (estaríamos):
      echo "Red Hat Enterprise Linux Server release 5.4 (Tikanga)" > /etc/redhat-release
    • Ejecutar el siguiente comando para instalar las dependencias necesarias:
      aptitude install pdksh odbcinst1debian2 unixodbc-dev unixodbc unixodbc-bin libaio1 libaio-dev sysstat isag elfutils libelf1 binutils-dev binutils libstdc++5 cpp-4.1 gcc-4.1 gcc-4.1-multilib
    • Agregar las siguientes líneas en el archivo de configuración de /etc/sysctl.conf (o generar algún archivo dentro de /etc/sysctl.d):
      ###############################3
      # Oracle Parameters
      kernel.shmall = 2097152
      kernel.shmmax = 2147483648
      kernel.shmmni = 4096
      kernel.sem = 250 32000 100 128
      fs.file-max = 6815744
      net.ipv4.ip_local_port_range = 9000 65500
      net.core.rmem_default = 4194304
      net.core.rmem_max = 4194304
      net.core.wmem_default = 262144
      net.core.wmem_max = 1048576
      fs.aio-max-nr = 1048576

      Finalmente para que el sistema tome los cambios ejecutamos: sysctl -p
    • Crear los grupos de sistema necesarios para la base de datos:
      addgroup --system oinstall
      addgroup --system dba
    • Obviamente debemos agregar a nuestro usuario a los grupos generados:
      usermod -a -G dba,oinstall $USER
    • Ejecutar los siguientes comandos para generar los enlaces necesarios por el instalador de Oracle:
      ln -s /usr/bin/awk /bin/awk
      ln -s /usr/bin/rpm /bin/rpm
      ln -s /usr/bin/basename /bin/basename
    • Agregar las siguientes líneas al archivo /etc/security/limits.conf:
      @dba soft nproc 2047
      @dba hard nproc 16384
      @dba soft nofile 1024
      @dba hard nofile 65536
    • Asegurarnos de usar (de preferencia) el compilador de C (AKA gcc4.1)
    • Reiniciar sesión con el usuario para que tome los cambios.
  2. Instalación de la base de datos. Notaremos que saltarán varios errores respecto a las dependencias de paquetes, podemos omitirlos y seleccionar las opciones de instalación de la base de datos.
  3. Crearemos una base de datos que tenga una distribución asignada de 2.5GB (SGA), ademas de ampliar a 500 el numero de procesos y cursores abiertos.
  4. Utilizamos el RCU para crear los esquemas que necesitemos. En este caso se ocuparon todos los de Identity Management, lo que en automático instalo algunos otros como el de SOA.
  5. Instalamos el servidor de weblogic (debe ser exactamente la versión 10.3.3).
  6. Instalamos la SOA Suite 11.1.1.2, esto creará el home $SOA_HOME
  7. Instalamos el Patch-Set 11.1.1.3 de SOA Suite
  8. Instalamos IDM 11.1.1.2, esto creara el home $IDM_HOME
  9. Instalamos el Patch-Set de IDM 11.1.1.3
  10. Instalamos la IAM 11.1.13, esto creará el home $IAM_HOME
  11. Configuramos las opciones de Identity Management según las necesitemos, para ello usamos el script $IDM_HOME/bin/config.sh, cabe destacar que debemos seleccionar la opción de crear un nuevo dominio, puesto que no lo hemos creado hasta este momento.
    El script creará y extenderá el dominio, además de configurar una instancia de OID, OVD, ODSM y OIF.
  12. Ahora es el turno de configurar el IAM, para ello ejecutaremos el script $IAM_HOME/common/bin/config.sh, y puesto que queremos instalar todo sobre el mismo dominio, solo es necesario extenderlo.
    Finalizado el script, deberemos reiniciar todo el Weblogic (osea el dominio generado en el paso anterior), para que tome los cambios.

Les recomiendo generar el archivo boot.properties para no depender de introducir manualmente el password y el usuario del administrador de weblogic (esto claro excepto la primer vez que es obligatorio para que se generen los directorios de los servidores nuevos). Como se pueden dar cuenta, los pasos estan explicados a grandes rasgos, esto es porque prácticamente la instalación en un escenario donde se usarán todos los productos en un solo dominio, sin H-A, etc, sigue un esquema siguiente-siguiente y no es necesario deternos a explicar algún paso intermedio.

Finalmente, para arrancar los servicios, pueden usar cualquiera de las siguientes opciones:

  1. Método usando Enterprise Manager:
    #Arrancar el listener de la base de datos
    lsnrctl start
    sqlplus "/as sysdba" < ../servers/$ADMINSVR_NAME/logs/consoleAdmin.log 2>&1 &

    #Arrancar el nodeManager:
    cd $WLS_HOME/server/bin
    nohup ./startNodeManager.sh > $DOMAIN_HOME/logs/nodeManager.log 2>&1 &

    #Iniciar los diferentes ManagedServers desde el EM
    http://$HOST:$PORT/em

    #Si instalaron todo IDM, notarán que deben levantar los siguientes: oaam_admin_server1, oaam_server_server1, oam_server1, oim_server1, soa_server1, wls_ods1, wls_oif1.

  2. Método usando linea de comandos:
    #Arrancar el listener de la base de datos
    lsnrctl start
    sqlplus "/as sysdba" < ../servers/$ADMINSVR_NAME/logs/consoleAdmin.log 2>&1 &

    #Arrancar los managed Servers, si instalaron todo IDM, notarán que deben levantar los siguientes: oaam_admin_server1, oaam_server_server1, oam_server1, oim_server1, soa_server1, wls_ods1, wls_oif1.:
    cd $WLS_HOME/server/bin
    nohup ./startManagedWebLogic.sh $SERVER_NAME http://$HOST:$PORT > ../servers/$SERVER_NAME/logs/console.log 2>&1 &

Y listo, tenemos todo #IDM11g instalado y configurado en nuestro flamante Debian GNU/Linux. Consumiendo solo los recursos necesarios para ello.
Dudas, quejas y/o aclaraciones son bien recibidas.

Happy Hacking!

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

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>

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>