Oracle WebLogic Server 11g: Manejo de Usuarios y Grupos

Transcripción

1 Newsletter Noviembre 2012 Oracle WebLogic Server 11g: Manejo de Usuarios y Grupos Contenido Por Ing. Iván García igarcia@datum.com.gt Página: El manejo de seguridad en los ambientes Web es uno de los puntos más importantes y esenciales para un correcto despliegue de aplicaciones en el entorno de Internet/Intranet. El aspecto de la seguridad en los sistemas informáticos abarca 1 Oracle WebLogic Server muchas aristas, desde el acceso físico a los servidores hasta el cifrado de los 11g: Manejo de Usuarios y canales de comunicación; en esta ocasión centraremos la atención al manejo de usuarios y grupos para el acceso a las aplicaciones. Grupos Oracle WebLogic Server es el servidor de aplicaciones que Oracle utiliza como pilar fundamental para Oracle Fusion Middleware (OFM), el OFM es la plataforma sobre 4 Es Ágil su Empresa? la cual se encapsulan todas las herramientas que nos permiten prestar distintos Evalúela Usted Mismo! servicios y ejecutar aplicaciones empresariales. Oracle WebLogic Server será la plataforma sobre la cual se ejecutarán todas las aplicaciones Java que nuestra organización necesite. 7 Consumiendo un Webservice Desde Código Como plataforma de ejecución de aplicaciones Java, WebLogic provee de fábrica 5a. Ave Zona14,Edificio Euro Plaza Torre un II, Nivel repositorio 12 para el manejo de usuarios y grupos; es en este repositorio donde PL/SQL Teléfono: (502) Fax: (502) está creado el usuario administrador del Dominio de WebLogic. Así como el .info@datum.com.gt usuario administrador reside en este repositorio, es aquí donde Pagina se crean 1/10 los usuarios y grupos a los cuales les daremos acceso a las aplicaciones. Editores Generales WebLogic utiliza el concepto de Dominio de Seguridad para identificar el conjunto Deiby Mauricio Gómez de mecanismos que permitan proteger los recursos de WebLogic, entre estos están Alejandro Lau las aplicaciones, los datasources, etc. Dentro de estos mecanismos podemos Debbie Morán encontrar los llamados Proveedores (Providers), estos no brindan servicios como la Autenticación, Autorización, Auditoría, Validación de Contraseñas, etc. En este caso en particular nos centraremos en los Proveedores de Autenticación. Autores Contribuyentes Iván García Deiby Gómez Jonathan Morales Página 1

2 Proveedores de Autenticación El Proveedor de Autenticación es el encargado de proveer protección a los recursos mediante la validación de un usuario; es decir, permiten acceder a un almacén de datos para verificar las credenciales del usuario y así permitir o denegar el acceso a la aplicación. Al momento de instalar WebLogic crea y utiliza un proveedor default llamado DefaultAuthenticator, este proveedor almacena los usuarios y grupos en un LDAP 1 embebido en el AdminServer. De tal manera que desde la Consola de Administración podemos crear usuarios y grupos para proteger las aplicaciones. Ahora bien, esta administración de usuarios y grupos es básica pero suficiente para ambientes de pocos usuarios, es importante recalcar que permite un manejo de políticas de contraseña limitado. La ventaja de utilizar este proveedor default es que está listo out-of-the-box. WebLogic nos permite hacer uso de más de un Proveedor de Autenticación, es decir, podemos tener varios almacenes de usuarios y esto es útil para cuando tenemos ya un repositorio de usuarios en la organización, por ejemplo Active Directory, Oracle Internet Directory, etc. Crear un Proveedor de Autenticación La forma en que utiliza los proveedores de autenticación WebLogic es bastante simple; cuando se presentan las credenciales del usuario WebLogic verifica con todos los proveedores de seguridad si los datos son válidos. Esta verificación la hace en orden, según la prioridad de los proveedores; y dependiendo de la "condición de control" especificada. La "condición de control" especifica si el usuario debe existir en ese proveedor "REQUIRED", si basta con que el usuario exista en un proveedor "SUFFICIENT" o si el usuario puede o no existir "OPTIONAL". WebLogic nos ofrece gran cantidad de Proveedores de Autenticación, permitiendo utilizar diversos repositorios de usuarios, los más comunes son ActiveDirectoryAuthenticator, OracleInternetDirectoryAuthenticator, LDAPAuthenticator y SQLAuthenticator. Al utilizar estos 1 Lightweight Directory Access Protocol Página 2

3 proveedores podemos hacer uso de las herramientas de administración propias de cada uno de ellos para manejar los usuarios y grupos; además, podemos utilizar las políticas de contraseña que nos brinden el repositorio de usuarios y tener una mejor visión del estado de las cuentas. Otra ventaja adicional es que, por ejemplo, al utilizar Active Directory como repositorio de credenciales para WebLogic, podemos usar los mismos usuarios y grupos del dominio para acceder a las aplicaciones. Dependiendo del tipo de proveedor que se utilice así se deberá de ingresar los datos de conexión para validar los usuarios. En la siguiente imagen se pueden apreciar los datos esenciales para crear un Proveedor de Autenticación tipo ActiveDirectoryAuthenticator. En primera instancia se deben ingresar los datos de conexión: nombre del servidor de AD, puerto, un usuario administrador y su contraseña; además la ruta en el árbol de AD donde residen los usuarios y grupos (comúnmente será abajo del dominio). Por último hay que recordarse de colocar la "condición de control", tanto del proveedor default como del nuevo en "SUFFICIENT". Es importante recalcar que gracias al manejo de los Proveedores de Autenticación, WebLogic incluso nos permite utilizar la Autenticación Nativa de Windows, o utilizar Oracle Single Sign-On y compartir la sesión con aplicaciones del Oracle Fusion Middleware como Forms, Reports, etc., simplificando así el manejo de usuarios y grupos en el aseguramiento de la plataforma Web de la organización. Página 3

4 Es Ágil su Empresa? Evalúela Usted Mismo! Por Ing. Deiby Gómez Se ha preguntado alguna vez qué tan ágil es su empresa? Qué tan rápido se adapta a los cambios del mercado? Qué tan rápido crea un nuevo producto o servicio? IT tiene la capacidad de soportar la innovación que exigen las personas de negocio? Usted puede evaluar el estado actual de su empresa con la ayuda de la Matriz de Madurez OSIMM (Open Group Service Integration Maturity Model), la cual le ayudará a crear un mapa para la transformación incremental hacia un nivel más maduro de integración de servicios, para que los beneficios de su empresa se incrementen por medio de la agilidad. OSIMM es usada para determinar características de la organización y determinar si existen problemas en el nivel actual; cómo solventarlos y así poder evolucionar al siguiente nivel de madurez. OSIMM se enfoca en el análisis de siete dimensiones críticas de una organización o empresa: Negocio Organización Métodos y procesos Aplicaciones Arquitectura Información Infraestructura Y para cada dimensión existen siete niveles de madurez. A continuación se dan a conocer los niveles, desde el nivel menos maduro (1) hasta el nivel más maduro (7): 1. Silo 2. Integrado 3. Por componentes 4. Servicios 5. Servicios Compuestos 6. Servicios Virtualizados 7. Servicios Dinámicamente Reconfigurables DIMENSIONES: A continuación se describe el concepto de cada una de las dimensiones para así tener claro qué características de la organización son tomadas en cada una de ellas: Negocio: Está enfocada en las actuales prácticas y políticas de la organización. Cómo son ejecutados y diseñados los procesos de negocio. Cómo están estructurados, implementados y monitoreados. Qué costo tiene la modificación o creación de procesos. Qué tan flexible es IT para soportar las solicitudes de las personas de negocio. Estrategias y tácticas de la organización. Organización: Está enfocada en la estructuración y diseño de la organización y su efectividad. Qué capacidad, experiencia y conocimientos poseen sus empleados para aprovechar una empresa ágil, existencia de gobernanza en sus procesos, alineación entre el negocio e IT. Cómo está manejado IT y qué tanto presupuesto se le asigna. Métodos y Procesos: Está enfocada en los métodos y procesos empleados por la organización para su crecimiento y su madurez alrededor del ciclo de vida del desarrollo del software, tales Página 4

5 como el uso de manejo de requerimientos, técnicas de estimación, manejo de proyectos, calidad de los procesos, uso de metodologías y herramientas certificadas. Aplicación: Se enfoca en el estilo de las aplicaciones, su estructura y funcionalidad, reusabilidad, flexibilidad, confiabilidad, seguridad y escalabilidad. Si existen aplicaciones con la misma función, aunque sirvan a áreas distintas del negocio, entonces hay funcionalidad duplicada. Arquitectura: Está enfocada en la topología, tipos de los datos, modelo de información del negocio, técnicas de integración, estándares y políticas. Información: Se enfoca en aspectos del modelado de la información; acceso, abstracción y transformación de los datos; definición de procesos y servicios, manejo de identidad y credenciales de seguridad. Infraestructura: Se enfoca en la capacidad de la infraestructura de la organización, manejo de los servicios, capacidad de transaccionalidad, operaciones de IT, manejo y administración de IT. Creación de SLAs, monitoreo, plataformas de integración. NIVELES DE MADUREZ: Para las dimensiones anteriores, se debe ubicar cada una en alguno de los siguientes niveles: Silo: Partes individuales de la organización están desarrollando software de manera independiente, sin integración de datos, sin procesos ni estándares. Esto limita la capacidad de la organización para implementar procesos de negocio que requieran cooperación entre las diferentes partes, y los sistemas IT no pueden ser integrados sin intervención manual, reconfiguración o recodificación. Integrado: Se ha logrado la comunicación entre las islas de aplicaciones. Se hace posible la construcción de un sistema IT que integra datos a través de diferentes aplicaciones de la organización. Sin embargo, la integración no está basada en estándares. Cada conexión entre dos sistemas puede requerir código y adaptadores a la medida, provocando muchas veces proliferación de código. Esto hace más complejo y costoso el mantenimiento y nuevos desarrollos. Por componentes: Los sistemas IT en islas han sido clasificados en componentes. Aunque los componentes interactúan entre sí a través de interfaces bien definidas, no existe un Bajo Acoplamiento. Esto limita la interoperabilidad entre sistemas en diferentes partes de la organización o incluso con otras organizaciones, siendo una limitante para el crecimiento de la empresa (adaptarse al mercado rápidamente). Servicios: Ahora las aplicaciones compuestas pueden ser construidas con Bajo Acoplamiento. La manera en que los servicios pueden ser invocados se basa en estándares. Los servicios son independientes de la tecnología y están ejecutándose en una infraestructura que soporta protocolos adecuados, mecanismos de seguridad, transformación de datos y monitoreo. Los servicios además pueden interactuar fácilmente con otras partes de la organización o incluso con organizaciones externas. Además, pueden ser creados SLAs para partes relevantes del negocio. El nombre de cada servicio indica implícitamente la operación que realiza, permitiendo la creación de un Catálogo de Servicios. Sin embargo, el flujo de control dentro de un servicio compuesto esta todavía definido por programación a la medida, en lugar de utilizar un lenguaje declarativo. Servicios Compuestos: Ahora es posible construir procesos de negocio por medio de un conjunto de servicios interactuando entre sí. Ya no se realiza código a la medida, sino que se hace uso de un lenguaje declarativo como BPEL. Esto permite ensamblar servicios simples o complejos con mucha facilidad y rapidez, ya que no se necesitará escribir ni una línea de código y los cambios Página 5

6 pueden ser entendidos por cualquier persona de negocio. Esto provoca que el diseño de servicios sea ágil y que puedan ser desarrollados tanto por las personas técnicas como las no-técnicas. Servicios Virtualizados: Los servicios IT están ahora siendo accedidos por una fachada. Los consumidores de servicios no invocan un servicio directamente, sino que invocan un Servicio Virtual. La infraestructura realiza el trabajo de convertir la invocación virtual en una invocación física al servicio real y puede realizar cambios en los datos, ruteo, la red, el protocolo, entre otros. Los servicios virtuales también favorecen el Bajo Acoplamiento, ya que se elimina la reconfiguración de todos los servicios dependientes cada vez que un servicio independiente cambie. Servicios Dinámicamente Reconfigurables: En el nivel anterior, los ensamblados de servicios, aunque son ágiles, son realizados en tiempo de diseño usando herramientas adecuadas. Ahora en este nuevo nivel, los cambios en el ensamblaje de los servicios compuestos son realizados en Tiempo de Ejecución; y con ello la organización se convierte en una organización totalmente ágil. Una vez explicada cada una de las dimensiones y cada uno de los niveles de madurez, se presenta la matriz de madurez OSIMM: EVALÚE SU EMPRESA! Página 6

7 Consumiendo un Webservice Desde Código PL/SQL Por Ing. Jonathan Morales En diversas ocasiones nos encontramos con la necesidad de obtener datos de un sitio externo a través de un webservice servicio web- y además, se desea realizar la llamada directamente desde la base de datos. Para ello, la base de datos Oracle tiene el paquete UTL_HTTP, el cual permite realizar solicitudes a través del protocolo HTTP, que es el mecanismo utilizado para consumir un webservice como se mostrará más adelante. Independientemente de las operaciones que se deseen realizar con los datos del servicio, se debe seguir una serie de pasos para consumir con éxito el webservice y obtener la respuesta en formato XML (SOAP Response). Verificaciones previas para poder consumir el webservice desde PL/SQL Acceso al webservice desde la instancia del servidor de base de datos Oracle. Para ello verificar que la base de datos tenga comunicación a la red en donde esté publicado el webservice (o directamente a Internet, de ser ese el caso). Si se utiliza Oracle 11g, es necesario verificar que el paquete UTL_HTTP tenga permisos para interactuar con el servidor remoto (donde está el webservice) por medio de listas de control de acceso (ACL) de la base de datos. Una vez se tiene la certeza que existe comunicación entre la base de datos y el webservice, el desarrollo de un procedimiento en PL/SQL consiste básicamente en realizar los siguientes pasos: 1. Definir la solicitud (request) hacia el webservice. 2. Construir el mensaje SOAP con los parámetros del método (acción) del webservice. 3. Invocar al webservice. 4. Obtener la respuesta. 5. Manejo de la respuesta (estructura XML). Qué datos son necesarios para consumir el webservice? 1. La URL donde está publicado el servicio, y particularmente conocer la definición del webservice por medio del WSDL (Web Services Description Language). Por ejemplo: url varchar2(2000):=' 2. El nombre de cada uno de los parámetros que recibe la operación que se desea consumir. Para ello se utiliza una estructura XML de acuerdo al protocolo de intercambio de mensajes para webservices (SOAP REQUEST), la cual está definida en el mismo webservice. Página 7

8 SOAP REQUEST DEL WEBSERVICE DE EJEMPLO <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:xsi=" xmlns:xsd=" xmlns:soap=" <soap:body> <GetQuote xmlns=" <symbol>string</symbol> </GetQuote> </soap:body> </soap:envelope> CONSTRUCCIÓN DEL PROCEDIMIENTO PL/SQL CREATE OR REPLACE PROCEDURE PROC_WS (symbol IN VARCHAR2) AS env varchar2(32767); http_req utl_http.req; http_resp utl_http.resp; resp sys.xmltype; url varchar2(2000):=' BEGIN -- MENSAJE SOAP CON EL PARÁMETRO env:= '<?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:xsi=" xmlns:xsd=" xmlns:soap=" <soap:body> <GetQuote xmlns=" <symbol>' symbol '</symbol> </GetQuote> </soap:body> </soap:envelope>'; --DEFINIR LA SOLICITUD (REQUEST) http_req := utl_http.begin_request(url, 'POST','HTTP/1.1'); utl_http.set_body_charset(http_req, 'UTF-8'); utl_http.set_header(http_req, 'Content-Type', 'text/xml'); utl_http.set_header(http_req, 'Content-Length', length(env)); Página 8

9 utl_http.set_header(http_req,'soapaction', ' -- INVOCAR EL SERVICIO utl_http.write_text(http_req, env); --OBTENER LA RESPUESTA http_resp := utl_http.get_response(http_req); utl_http.read_text(http_resp, env); utl_http.end_response(http_resp); END PROC_WS; --MANEJO DE LA RESPUESTA Y EXTRACCIÓN DE ELEMENTOS resp := xmltype.createxml(env); resp:= resp.extract('//getquoteresult/text()','xmlns:soap=" xmlsoap.org/soap/envelope/"'); dbms_output.put_line(substr(env, 1, 245)); Es importante resaltar que la respuesta obtenida del webservice es un XML con la estructura correspondiente al SOAP Response, por lo que para extraer los elementos deseados pueden utilizarse funciones para el manejo de estructuras XML, tal como se muestra en el ejemplo. Tip técnico del día: Campos de datos basadas en función: En Oracle 11g se tiene la nueva función campos virtuales de tablas, los cuales son campos que su valor se basa en una función que involucra los valores de los otros campos. A continuación un ejemplo: Create table t1( c1 number, c2 number, c3 as (c1+c2) virtual); Por Ing. Deiby Gómez dgomez@datum.com.gt Página 9