jueves, 30 de abril de 2015

6.3 Seguridad e interoperabilidad



Seguridad

Siguiendo el modelo W3C, vamos a realizar un pequeño estudio sobre los requisitos de seguridad que se encuentran enumerados dentro de la arquitectura de referencia de los servicios web y señalando las diferentes tentativas de ataque que también aparecen dentro de la especificación. Se ofrecerán soluciones para las mismas.

Servicios de seguridad básicos

La seguridad es un concepto considerado clave dentro de los que comprenden el aseguramiento de calidad dentro del servicio Web. Si se realiza una catalogación básica de los servicios de seguridad son la confidencialidad, integridad, autenticidad de origen, no repudio y control de acceso. A continuación se explica brevemente cada uno de ellos:
  • Autenticación de los participantes. Los servicios Web por definición tienen mucha heterogeneidad, lo que provoca que los sistema de autenticación tengan que ser flexibles. Si imaginamos un servicio Web que necesita comunicarse con otro servicio, este podría solicitar al demandante credenciales junto a una demostración de que es el propietario de las mismas. Resulta necesario conseguir un estandarización de los protocolos y en los formatos a utilizar. Otro problema remanente es definir un modelo de autenticación Single Sign-On de forma que un servicio que necesita comunicarse con otros servicios Web,no tenga la necesidad de estar continuamente autenticándose y logre completar el proceso de negocio en un tiempo de respuesta aceptable.

  • Autorización. Con frecuencia , es necesario aplicar unos criterios que permitan controlar el acceso a los diferentes recursos. Es necesario definir los usuarios que pueden realizar diversas acciones sobre los diferentes recursos. En combinación con la autenticación, permite a las identidades conocidas realizar las acciones para las que tienen permisos. Con frecuencia se definen políticas de acceso en base a jerarquías.

  • Confidencialidad. Es necesario asegurar que el contenido incluido en los mensajes que se intercambian se mantiene como información confidencial. Es muy habitual emplear técnicas de cifrado, ya muy extendidas. Obviamente, la confidencialidad del mensaje va más allá que el canal por el que es transmitido.

  • Integridad. Esta propiedad garantiza que la información que se ha recibido , es exactamente la misma que se envió desde el cliente.

  • No repudio. En una comunicación que se realizan transacciones, es necesario registrar que las mismas se han producido y registrar el autor que lo ejecutó. En el caso de los servicios Web, trasladamos esta política la uso del servicio. Se comprueba que cierto cliente hizo uso de un servicio a pesar de que éste lo niegue (no repudio del solicitante) así como probar la ejecución se llevó a cabo (no repudio del receptor).

  • Disponibilidad. Uno de los ataques mas frecuentes a las aplicaciones se basa en la denegación de servicios. Se lanzan múltiples solicitudes falsas para inundar el servicio y provocar su caída. Es necesario contemplar la disponibilidad, como punto muy importante en el diseño de servicio web, ya que permiten cierta redundancia de los sistemas.

  • Auditabilidad. El registro de las acciones en los servicios Web permite mantener una traza de las mismas de manera que se puedan realizar análisis posteriores de los datos.

  • Seguridad extremo-a-extremo. Cuando se ejecuta un servicio es necesario garantizar la seguridad durante todo el recorrido que efectúan los mensajes. Dado que normalmente existen routers como intermediarios de la comunicación, esto provoca un aumento de la política de seguridad que garantice que se realiza el transporte de forma segura y confirme la seguridad de los intermediarios. Es importante disponer de un contexto de seguridad único y que incluya el canal de comunicación. Para conseguirlo, es necesario aplicar diversas operaciones de carácter criptográfico sobre la información en el origen. De esta manera se evita una dependencia con la seguridad que se configure por debajo de la capa de aplicación y se garantiza los servicios de seguridad

Requisitos de Seguridad

Si realizamos una abstracción sobre la problemática, el objetivo principal es conseguir un entorno para las transacciones y los procesos que sea seguro para todo el canal de comunicación. Obviamente, es necesario garantizar la seguridad durante el tránsito de la comunicación, ya sea con intermediarios o sin ellos durante la misma. Pro otra parte, se necesita asegurar la seguridad de la información en los procesos de almacenamiento: A continuación se ofrece una revisión breve de los principales requisitos para asegurar la seguridad en la comunicación.
Mecanismos de autenticación
La autenticación es obligatoria para mantener control y verificar la identidad de solicitantes y proveedores. En algunas ocasiones, resultará necesario realizar una autenticación tanto del solicitante como del proveedor, ya que puede producirse que los participantes no estén en conexión directa. Pueden existir intermediarios que retransmitan la comunicación
En función de la política de seguridad que se adopte, será necesario autenticar tanto al proveedor como al solicitante o simplemente a alguno de ellos. Se pueden emplear métodos basados en contraseñas, certificados , etc.. para formalizar la autenticación. Si se basan en contraseñas, es necesario aplicar una política que aporte robustez a las mismas.
  • Se pueden emplear mecanismos basados en protocolos de transporte como el Http Autentication y SSL/TLS X509 Certificate. Estos mecanismos sólo son válidos cuando existe una conexión directa entre el consumidor y el proveedor de servicio, ya que si un mensaje SOAP viaja entre varios endpoints antes de llegar a su destino, las credenciales del consumidor original se pierden en el primer endpoint.
  • También se pueden emplear mecanismos basados en tokens que se incluye dentro del mensaje. El estándar WS-Security incorpora un gran número de tokens que pueden ser empleados en este caso; Username Token, X509 Certificate, SAML assertions, etc. Este mecanismo de autenticación no tiene los problemas de los mecanismos basados en el transporte, ya que las credenciales pueden viajar entre los distintos endpoints hasta llegar a su destino. Si usamos este mecanismo, es necesario que estos sean transmitidos de forma segura para evitar ataques de replay. Esto puede se consigue mediante la firma del token dentro del mensaje SOAP, junto a un TimeStamp o IDMessage, por lo que se recomienda incluir en la firma la cabecera de WS-Addressing. En entornos cerrados también se puede emplear SSL para transmitir los mensajes con Tokens de forma segura, aunque esta aproximación es menos segura que la anterior.
Autorización
La autorización resulta necesaria para efectuar un control sobre el acceso a los recursos. Una vez se ha realizado la autenticación sobre el participante y se conoce su identidad, se utilizarán los mecanismos de autorización para realizar las comprobaciones pertinentes y asegurar el acceso adecuado al recurso por parte del participante.
Se crean políticas que determinan los privilegios de los participantes. Mediante la gestión de la confianza, se permite la interacción entre un solicitante y un proveedor sin referencias previas pero que atendiendo a las credenciales que se intercambian determinen un nivel de confianza asumible por ambos. De esta manera se permite un proceso de autenticación sin que haya existido la necesidad de desvelar las identidades de los participantes en el proceso
Integridad y confidencialidad de los datos
El proceso que mantiene la integridad de los datos, garantiza que la información que se ha enviada no ha sufrido ninguna transformación sin que se haya detectado. La confidencialidad, asegura los principios de intimidad de la información. Es decir solo se permite el acceso a la información a aquellos participantes con permisos para hacerlo. Con frecuencia, se usan técnicas de cifrado para conceptos de confidencialidad y la firma digital para temas de integridad.
No repudio
El objeto de las técnicas de no repudio ya se han comentado anteriormente, es registrar la participación y el grado de la misma de los diferentes interlocutores en una transacción para protegerlo de una posible denegación, posiblemente por parte de algún interlocutor de la misma, negando de que la transacción ocurrió o de su participación en la misma.
Las técnicas de no repudio permiten proporcionar evidencias sobre lo sucedido en la transacción, de manera que una tercera parte resuelve el desacuerdo producido.
Para garantizar el no repudio dentro de las comunicaciones por Servicios Webs, los mensajes SOAPs intercambiados deberán ser identificados de forma única mediante el uso de la especificación WS-Addressing. Los mensajes SOAP junto a sus cabeceras "relevantes", deberán ser firmadas según los procedimientos recogidos en la especificación WS-Security. Por último, los mensajes deberán ser almacenados en ficheros de logs, para su posterior consulta.
Rastreabilidad
Es necesario ajustar trazas que aseguren poder conocer información del acceso una vez se haya producido este, y comprobar el comportamiento que ha tenido el usuario que ha realizado el acceso. Son de especial importancia para verificar la integridad del sistema. Normalmente las trazas las generen los determinados "agentes de auditoria" que pueden realizar monitoreo, observar recursos y el comportamiento de otros agentes, y validar el cumplimiento de las políticas establecidas. Con frecuencia , no es posible prevenir la violación de las diferentes obligaciones pero si un agente de auditoria detecta una brecha podría activar un plan de repulsa o determinar otro tipo de actividades.
Aplicación distribuida de las políticas de seguridad
Si se han definido arquitecturas que están basadas en Servicios Web, están deben permitir la definición de políticas de seguridad y comprobar su cumplimiento en las diversas plataformas y con las diversas variaciones de acceso al servicio.

Uso de políticas

Los mensajes que se envían en la comunicación de los servicios Web atraviesan los cortafuegos y pueden ser modificados a través de los diferentes puertos y protocolos existentes. Es necesario, para asegurar la calidad de seguridad en los servicios Web, crear políticas corporativas para integrarse con las diversas políticas de los proveedores y con la gestión de la confianza planificada.
Políticas distribuidas
Con frecuencia, se asocian las políticas de seguridad a los proveedores o a los clientes o a un mecanismo de descubrimiento. Se utilizan para controlar y definir la metodología de acceso de las peticiones y las respuestas a las mismas, dadas por los involucrados en la comunicación. Estas políticas son validadas en ejecución dentro del contexto de la comunicación. Cada parte involucrada debe realizar la validación de sus políticas.
Políticas de confianza
Defiendo de manera simple una política de confianza como una política distribuida que asegura a dos entidades que afrontan una interacción sin conocerse previamente. Mediante el uso de credenciales, asumen el nivel de seguridad que pueden soportar. En ocasiones, la definición de estas políticas implica a terceras entidades de forma recursiva, que influyen en la decisión. Un ejemplo, "yo confió en esta entidad, si mis dos compañeros confían en ti y tu confías en mis dos compañeros"
Mecanismo de Descubrimiento Seguro
El mecanismo de descubrimiento seguro controla las publicaciones y apariciones de un servicio. Cuando aparece un servicio, es necesario realizar una evaluación de las políticas de publicación del servicio, exceptuando las situaciones que supongan un servicio de descubrimiento entre nodos. Si el descubrimiento lo realiza un cliente, puede dotar de identidad o no dársela al servicio. En esta segunda situación hablamos de un descubrimiento anónimo.
Confianza y Descubrimiento
Si imaginamos una situación donde un cliente descubre que existe un servicio Web muy necesario para él, y el proveedor del mismo, es una entidad desconocida hay que preguntarse que nivel de confianza puede otorgar el solicitante a ese servicio. Esta situación es especialmente importante en el caso que se este manejando información muy sensible, ya que se esta corrigiendo un riesgo grave.
Privacidad
La privacidad se expresa mediante las diferentes políticas definidas por los diferentes propietarios de los datos. Con frecuencia, los propietarios son los usuarios de los servicios Web. Es necesario asegurar que los privilegios y derechos de los usuarios son respetados
Fiabilidad de los servicios Web
La aparición de errores es inevitable, especialmente si consideramos que el contexto engloba a multitud de servicios interconectados por una red global que pertenecen a todo tipo de personas y entidades. La eliminación de errores no puede ser completa, así que el objetivo principal es reducir la tasa de errores que aparecen al nivel máximo posible.
Si hablamos de fiabilidad dentro de los servicios Web, podemos realizar una clasificación en función de la predecibilidad y la fiabilidad de:
  • Los servicios de la infraestructura, como un mecanismo de transporte de los mensajes o un servicio de descubrimiento.
  • Las interacciones entre los servicios.
  • El comportamiento individual del solicitante y del proveedor.

Amenazas de seguridad

Si analizamos el concepto de amenaza de seguridad, tendemos a asumir que existirá un intento de acceso y mal uso de los servicios. Por lo tanto hay que realizar un esfuerzo para controlar los accesos no permitidos. Si realizamos una clasificación de las principales amenazas, tenemos lo siguiente:
  • Acceso no permitido llevado a cabo por entidades sin identificar. Es necesario poder identificar de forma confiable la identidad de proveedores, servicios, etc...

  • Alteración de la información en el canal de comunicación. Es necesario garantizar la integridad de la información que se envía.

  • Debe asegurarse el acceso a la información. Solo pueden acceder las partes deseadas. Debe de mantenerse una certeza del contenido y de que la comunicación tuvo lugar.
  • El acceso inapropiado a los recursos. Debería ser posible garantizar que los recursos y las acciones no son accesibles por aquellas partes que no están autorizadas. De nuevo, este hecho se podría extender al mero conocimiento de que cierto recurso existe, es decir, de alguna forma se debería poder impedir que personas no autorizadas no puedan conocer la existencia de ciertos recursos o ciertos servicios.

  • Denegación de servicio. No debería ser posible que los clientes de los servicios no puedan acceder a él.

Tipos de ataques

Los tipos de ataques que se listan a continuación están extraídos de la especificación W3C.
Alteración de los mensajes
Es un tipo de ataque centrado sobre la integridad de los mensajes. Se busca modificar el contenido del mensaje (ya sea parcialmente o totalmente). En el caso que el atacante tuviera controlado un canal de comunicaciones entre servicios podría modificar los mismos, eliminarlos, capturarlos y reenviarlos.
La integridad de los mensajes se proporciona mediante la firma digital del fichero XML junto con tokens de seguridad para asegurar que el mensaje es transmitido sin modificaciones. El mecanismo de integridad está diseñado para soportar múltiples firmas por diferentes actores y se puede extender para soportar nuevos mecanismo de firma. Integrando XMLSignature, según lo establecido por la especificación WS-Security se minimiza la repercusión de estos ataques.
Ataques a la confidencialidad
Centrados en la captación de la información contenida dentro de los mensajes. En ocasiones puede existir información muy sensible (datos médicos, datos económicos, etc...)
Hombre en el medio o ‘man- in-the-middle.
Es la infiltración por parte de un atacante entre los participantes de una comunicación. Normalmente, intercepta la comunicación y suplanta a los participantes de manera que estos creen que se comunican entre si cuando lo hacen con el atacante.
La posibilidad de un ataque de intermediario sigue siendo un problema potencial de seguridad serio, incluso para muchos sistemas criptográficos basados en clave pública. Existen varios tipos de defensa contra estos ataques que emplean técnicas de autenticación basadas en:
  • Claves públicas
  • Autenticación mutua fuerte
  • Claves secretas (secretos con alta entropía)
  • Passwords (secretos con baja entropía)
  • Otros criterios, como el reconocimiento de voz u otras características biométricas
La integridad de las claves públicas debe asegurarse de alguna manera, pero éstas no exigen ser secretas, mientras que los passwords y las claves de secreto compartido tienen el requerimiento adicional de la confidencialidad. Las claves públicas pueden ser verificadas por una autoridad de certificación (CA), cuya clave pública sea distribuida a través de un canal seguro (por ejemplo, integrada en el navegador web o en la instalación del sistema operativo).
Suplantación de identidad (Spoofing)
Es un ataque orientado a los niveles de confianza que se establecen en la comunicación. El atacante suplanta la identidad de uno de los participantes en una relación de confianza, usualmente trata de comprometer al destinatario de la comunicación. Es muy útil utilizar una robusta autenticación para fortalecer el servicio ante estos ataques.
Para evitar ataques de spoofing exitosos contra nuestros sistemas podemos tomar diferentes medidas preventivas; en primer lugar, parece evidente que una gran ayuda es reforzar la secuencia de predicción de números de secuencia TCP. Otra medida sencilla es eliminar las relaciones de confianza basadas en la dirección IP o el nombre de las máquinas, sustituyéndolas por relaciones basadas en claves criptográficas; el cifrado y el filtrado de las conexiones que pueden aceptar nuestras máquinas también son unas medidas de seguridad importantes de cara a evitar el spoofing.
Denegación de servicio
El objetivo es mantener un servicio activo para que los usuarios legítimos puedan acceder a él. Los ataques se centran en destruir la disponibilidad de un servicio. Su objetivo es interrumpir las operaciones de un servicio dejándolo desconectado.
Es necesario adaptar la configuración del servidor a las necesidades de autenticación, seguir recomendaciones con respecto al tamaño de mensajes aceptadas, controlar la distribución de mensajes para minimizar este tipo de ataques.
Ataque de repetición
En este caso un atacante es capaz de interceptar un mensaje válido pudiendo reenviarlo más tarde todas las veces que quiera al servicio para el que era destinatario. Para poder solventar este problema se deben utilizar técnicas de autenticación apropiadas conjuntamente con técnicas de sellado de tiempos y números de secuencia.

Interoperabilidad

La interoperabilidad entre los servicio web de ASP.NET y los servicio web de Windows Communication Foundation (WCF) se puede lograr asegurando que los servicios implementados usen ambas tecnologías de acuerdo con la especificación WS-I Basic Profile 1.1. Los servicio web de ASP.NET que cumplen con WS-I Basic Profile 1.1 son interoperables con clientes de WCF mediante el uso de enlace proporcionado por el sistema de WCF, BasicHttpBinding.
 
Utilice la opción de ASP.NET 2.0 de agregar los atributos WebService y WebMethodAttribute a una interfaz en lugar de a una clase y escribir una clase para implementar la interfaz, como se muestra en el siguiente código de ejemplo.

[WebService]
public interface IEcho
{
    [WebMethod]
    string Echo(string input);
}

public class Service : IEcho
{

   public string Echo(string input)
   {
        return input;
    }
}


El uso de esta opción es preferible, porque la interfaz con el atributo WebService constituye un contrato para las operaciones realizadas por el servicio, que puede reutilizarse con diferentes clases que podrían implementar ese mismo contrato de distintas maneras.
Evite usar el atributo SoapDocumentServiceAttribute para que los mensajes se enruten a métodos en función del nombre completo del elemento de cuerpo del mensaje SOAP en lugar del encabezado HTTP SOAPAction.WCF usa el encabezado HTTP SOAPAction para enrutar mensajes.

El XML en el que XmlSerializer serializa de forma predeterminada un tipo es semánticamente idéntico al XML en el que DataContractSerializer serializa un tipo, dando por hecho que el espacio de nombres para el XML se define explícitamente.Cuando defina un tipo de datos para su uso con los servicios web de ASP.NETy en previsión de que se adoptará WCF, haga lo siguiente:
  • Defina el tipo mediante las clases de .NET Framework en lugar de mediante el Esquema XML. 
  • Agregue solo SerializableAttribute y XmlRootAttribute a la clase, utilizando el último para definir explícitamente el espacio de nombres del tipo.No agregue atributos adicionales del espacio de nombres System.Xml.Serialization para controlar cómo se traducirá la clase de .NET Framework a XML.
  • Mediante el uso de este enfoque, debería ser capaz de convertir más adelante las clases .NET en contratos de datos agregando DataContractAttribute y DataMemberAttribute sin modificar significativamente el XML en el que las clases se serializan para la transmisión.Los tipos utilizados en los mensajes por los servicios web de ASP.NET se pueden procesar como contratos de datos a través de aplicaciones WCF, lo que produce, entre otras ventajas, un mejor rendimiento en las aplicaciones WCF.
Evite usar las opciones de autenticación proporcionadas por Internet Information Services (IIS).Los clientes de WCF no las admiten.Si es necesario proteger un servicio, utilice las opciones proporcionadas por WCF, porque estas opciones son robustas y se basan en protocolos estándar.


Repercusión en el rendimiento de la carga de ServiceModel HttpModule


En .NET Framework 3.0, se instaló el HttpModule de WCF en el archivo raíz Web.config, de modo que cada aplicación ASP.NET sea compatible con WCF. Esto puede afectar al rendimiento, por lo que es posible quitar ServiceModel del archivo Web.config, como se muestra en el siguiente ejemplo.
 






<httpModules>
    <remove name=”ServiceModel” />
<httpModules/> 
 
 
 
 

 Fuente de informacion:  http://www.desarrolloweb.com/articulos/1640.php 

http://www.cyta.com.ar/ta1002/v10n2a3.htm

6.2 Estandares

Estándares de servicio Web


Uno de los atributos clave de estándares de Internet es que se centran en protocolos y no en implementaciones. Internet se compone de tecnologías heterogéneas que operan conjuntamente de modo satisfactorio mediante protocolos compartidos. Esto impide que los proveedores individuales impongan un estándar en Internet. El desarrollo del software de código fuente abierto desempeña un rol fundamental para proteger la interoperatividad de implementaciones de estándares del proveedor.

Los estándares siguientes desempeñan roles clave en servicios Web: UDDI (Universal Description, Discovery and Integration), WSDL (Web Services Description Language), WSIL (Web Services Inspection Language), SOAP y WS-I (Web Services Interoperability). La relación entre estos estándares se describe en la Figura 2. La especificación UDDI define estándares abiertos independientes de la plataforma que permiten a las empresas compartir información en un registro de empresa global, encontrar servicios en el registro y definir cómo actúan conjuntamente en Internet.

WSIL es una especificación abierta basada en XML que define un método de descubrimiento de servicios distribuidos que suministra referencias a descripciones de servicio en el punto de ofertas del proveedor de servicios, especificando cómo comprobar si hay servicios Web disponibles en un sitio Web. Un documento WSIL define las ubicaciones en un sitio Web donde se pueden buscar descripciones del servicio Web. Dado que WSIL se centra en el descubrimiento de servicios distribuidos, la especificación WSIL complementa UDDI facilitando el descubrimiento de servicios que están disponibles en sitios Web que quizá no se enumeren aún en un registro UDDI. En un tema aparte de esta documentación se describe la Relación entre UDDI y WSIL.
WSDL es una especificación abierta basada en XML que describe las interfaces y las instancias de servicios Web en la red. Es ampliable, de modo que se pueden describir los puntos finales independientemente de los formatos de mensaje o de los protocolos de red que se utilicen para comunicarse. Las empresas pueden poner a disposición de sus servicios Web los documentos WSDL mediante UDDI, WSIL o divulgando los URL a su WSDL mediante correo electrónico o sitios Web. WSDL se describe en un tema aparte de esta documentación.
SOAP es un estándar basado en XML para la transmisión de mensajes en HTTP y otros protocolos de Internet. Es un protocolo ligero para el intercambio de información en un entorno descentralizado y distribuido. Se basa en XML y consta de tres partes:
  • Un sobre que define una infraestructura para describir el contenido del mensaje y cómo procesarlo.
  • Un conjunto de normas de codificación para expresar instancias de tipos de datos definidos por la aplicación.
  • Una convención para representar llamadas y respuestas a procedimiento remoto.
SOAP permite el enlace y la utilización de servicios Web encontrados definiendo una ruta de mensaje para el direccionamiento de mensajes. Se puede utilizar SOAP para consultar UDDI para servicios Web.

Figura 2. Relaciones entre SOAP, UDDI, WSIL y WSDL.


Un proveedor de servicios aloja un servicio Web y lo hace accesible con protocolos como SOAP/HTTP o SOAP/JMS. El servicio Web se describe mediante un documento WSDL que se almacena en el servidor del proveedor o en un depósito especial. UDDI Business Registry y sus documentos WSDL pueden hacer referencia al documento WSDL. Estos contienen punteros a los archivos WSDL del servicio Web.
Los perfiles WS-I Simple SOAP Binding Profile y WS-I Attachments Profile son esquemas de requisitos que el tráfico de WSDL y de protocolo de servicio Web (SOAP/HTTP) deben cumplir para afirmar la conformidad WS-I. Las herramientas de validación WS-I de servicios Web admiten actualmente WS-I Simple SOAP Binding Profile 1.0 y Attachment Profile 1.0.

Productos de Rational Developer también admiten varios estándares nuevos de servicios Web. Éstas son:


JAX-RPC
JAX-RPC son las siglas de Java API for XML-based RPC (API de Java para RPC basado en XML), también conocido como JSR 101. Es una especificación que describe las interfaces de programación de aplicaciones (API) de Java y las convenciones para crear servicios Web y clientes de servicio Web que utilizan RPC (llamadas a procedimiento remoto) y XML. Estandariza las correlaciones de Java con WSDL y de WSDL con Java, asimismo proporciona las API principales para el desarrollo de servicios Web y clientes de servicio Web en la plataforma Java. 
JSR-109 y JSR-921
JSR-109 y JSR-921 (implementación de Enterprise Web Services) definen el modelo de programación y la arquitectura de ejecución para desplegar y buscar servicios Web en el entorno J2EE; más específicamente, en los contenedores Web, EJB y de aplicaciones cliente. Uno de los objetivos principales es asegurar que las implementaciones operen conjuntamente.
WS-S
Estas herramientas admiten el estándar OASIS Web Services Security 1.0. 
Las herramientas de servicios Web admiten las siguientes especificaciones:





 

6.1 Conceptos generales


Un servicio web (en inglés, Web services) es una tecnología que utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos entre
aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de computadoras como Internet. La
interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la arquitectura y
reglamentación de los servicios Web. Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WS-I,
encargado de desarrollar diversos perfiles para definir de manera más exhaustiva estos estándares. Es una máquina que atiende las peticiones de los clientes web y les envía los recursos solicitados.

Ventajas de los servicios web

Aportan interoperabilidad entre aplicaciones de software independientemente de sus propiedades o
de las plataformas sobre las que se instalen.
Los servicios Web fomentan los estándares y protocolos basados en texto, que hacen más fácil
acceder a su contenido y entender su funcionamiento.
Permiten que servicios y software de diferentes compañías ubicadas en diferentes lugares
geográficos puedan ser combinados fácilmente para proveer servicios integrados
.

Inconvenientes de los servicios Web

Para realizar transacciones no pueden compararse en su grado de desarrollo con los estándares abiertos de computación distribuida como CORBA (Common Object Request Broker Architecture). Su rendimiento es bajo si se compara con otros modelos de computación distribuida, tales como RMI (Remote Method Invocation), CORBA o DCOM (Distributed Component Object Model). Es uno de los inconvenientes derivados de adoptar un formato basado en texto. Y es que entre los objetivos de XML no se encuentra la concisión ni la eficacia de procesamiento. Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas en firewall cuyas reglas tratan de bloquear o auditar la comunicación entre programas a ambos lados de la barrera.

Razones para crear servicios Web

La principal razón para usar servicios Web es que se pueden utilizar con HTTP sobre TCP
(Transmission Control Protocol) en el puerto 80. Dado que las organizaciones protegen sus redes mediante firewalls -que filtran y bloquean gran parte del tráfico de Internet-, cierran casi todos los puertos TCP salvo el 80, que es, precisamente, el que usan los navegadores. Los servicios Web utilizan este puerto, por la simple razón de que no resultan bloqueados. Es importante señalar que los servicios web se pueden utilizar sobre cualquier protocolo, sin embargo, TCP es el más común.
Otra razón es que, antes de que existiera SOAP, no había buenas interfaces para acceder a las funcionalidades de otros ordenadores en red. Las que había eran ad hoc y poco conocidas, tales como EDI (Electronic Data Interchange), RPC (Remote Procedure Call), u otras APIs.
Una tercera razón por la que los servicios Web son muy prácticos es que pueden aportar gran independencia entre la aplicación que usa el servicio Web y el propio servicio. De esta forma, los cambios a lo largo del tiempo en uno no deben afectar al otro. Esta flexibilidad será cada vez más importante, dado que la tendencia a construir grandes aplicaciones a partir de componentes distribuidos más pequeños es cada día más utilizada.
Se espera que para los próximos años mejoren la calidad y cantidad de servicios ofrecidos basados en los nuevos estándares.


Plataformas

Servidores de aplicaciones para servicios Web:

• Oracle Fusion Middleware
• Axis y el servidor Jakarta Tomcat (de Apache)
• ColdFusion MX de [[Macromedia]httpd ]
• Java Web Services Development Pack (JWSDP) de Sun Microsystems (basado en Jakarta Tomcat)
• JOnAS (parte de ObjectWeb una iniciativa de código abierto)
• Microsoft .NET
• Novell exteNd (basado en la plataforma J2EE)
• WebLogic
• WebSphere
• JAX-WS con GlassFish
• Zope es un servidor de aplicaciones Web orientado a objetos desarrollado en el lenguaje de programación Python
• VERASTREAM de AttachmateWRQ para modernizar o integrar aplicaciones host IBM y VT
• PHP









Unidad 6 Servicios WEB

6.1 Conceptos generales
6.2 Estandares
6.3 Seguridad e interoperabilidad

miércoles, 22 de abril de 2015

5.3 Aplicacion



Un servidor web o servidor HTTP es un programa informático que procesa una aplicación del lado del servidor, realizando conexiones bidireccionales y/o unidireccionales y síncronas o asíncronas con el cliente y generando o cediendo una respuesta en cualquier lenguaje o Aplicación del lado del cliente. El código recibido por el cliente suele ser compilado y ejecutado por un navegador web. Para la transmisión de todos estos datos suele utilizarse algún protocolo. Generalmente se usa el protocolo HTTP para estas comunicaciones, perteneciente a la capa de aplicación del modelo OSI. El término también se emplea para referirse al ordenador que ejecuta el programa.


Combox Dinámicos

 El correspodiente diagrama entidad relación se presenta a continuación:

index.php

 

<head>
  <meta charset='utf-8'/>
  <title>Combox Dependientes</title>
  <link href='../../../css/estilo.css' rel='stylesheet' />
  <script src='js/jquery-1.10.1.min.js'></script>
  <script src='js/js.js'></script>
</head>
<body>
  <p><label>Estado</label>
  <select class='styled-select' id='estado'></select></p>
  <p><label>Municipio</label>
  <select class='styled-select' id='municipio'></select></p>
  <div id='colonias'>
  </div>
</body>
</html>
 

conexion.php

 

<?php 
  $ruta    = 'localhost';
  $usuario = 'Usuario';
  $key     = 'Password';
  $db      = 'Tu base de datos';
  $conexion  = mysql_connect( $ruta, $usuario, $key) or die(mysql_error());
  mysql_select_db( $db, $conexion ) or die(mysql_error()); 
  mysql_query("SET NAMES 'utf8'");
?>

comboEstado.php

<?php
 $query = 'SELECT idEstado, estado 
           FROM estado ORDER BY estado';
 include('conexion.php');
 $estados = mysql_query($query, $conexion) 
            or die(mysql_error()); 
 mysql_close($conexion);
 $html = '';
 while ($estado = mysql_fetch_assoc($estados)) {
  $html.= '<option value="'.$estado['idEstado'].'">';
  $html.= $estado['estado'].'</option>';     
 }
 echo $html; 
?>

comboMunicipio.php

<?php
 $idEstado = $_GET['idEstado'];
 $query = 'SELECT idMunicipio, municipio FROM municipio ';
 $query.= 'WHERE idEstado ='.$idEstado; 
 $query.= ' ORDER BY municipio';
 include('conexion.php');
 $municipios = mysql_query($query, $conexion) 
               or die(mysql_error()); 
 mysql_close($conexion);
 $html = '';
 while ($municipio = mysql_fetch_assoc($municipios)) {
  $html.= '<option value="'.$municipio['idMunicipio'].'">';
  $html.= $municipio['municipio'].'</option>';     
 }
 echo $html; 
?>

colonias.php

<?php
 $idMunicipio = $_GET['idMunicipio'];
 $query = 'SELECT T.tipo, C.colonia, C.codigoPostal, Z.zona 
          FROM colonia C, tipo T, zona Z ';
 $query.= "WHERE C.idMunicipio = $idMunicipio ";
 $query.= 'AND C.idTipo = T.idTipo AND C.idZona = Z.idZona ';
 $query.= 'ORDER BY C.colonia';
 include('conexion.php');
 $colonias = mysql_query($query, $conexion) 
             or die(mysql_error()); 
 mysql_close($conexion);
 $n = mysql_num_rows($colonias);  
 if( $n > 0 ) {
   $html = '<table>';
   $html.= '<thead>';
   $html.= '<tr>'; 
   $html.= '<th>Asentamiento</th>';
   $html.= '<th>Nombre</th>';
   $html.= '<th>C.P.</th>';
   $html.= '<th>Zona</th>';
   $html.= '</tr>';
   $html.= '</thead>';
   $html.= '<tbody';
   while ($colonia = mysql_fetch_assoc($colonias)) {
     $html.= '<tr>'; 
     $html.= '<td>'.$colonia['tipo'].'</td>';
     $html.= '<td>'.$colonia['colonia'].'</td>';
     $html.= '<td>'.$colonia['codigoPostal'].'</td>';
     $html.= '<td>'.$colonia['zona'].'</td>';
     $html.= '</tr>';
   }
   $html.= '</tbody>';
   $html.= '</table>';
 } else {
    $html = '<p align="center">';
    $html = '<img alt="" src="../../../images/negacion.gif">';
 $html.= '</p>';
 }
 echo $html; 
?>
Los datos se cargan dinámicamente mediante AJAX con jQuery
$(document).ready(function() {
  $('#estado').load('comboEstado.php', function() {
  var idEstado =  $('#estado').val();
  var url = 'comboMunicipio.php?idEstado='+idEstado;
  $('#municipio').load(url, function() {
    var idMunicipio = $('#municipio').val();
    var url = 'colonias.php?idMunicipio='+idMunicipio;
    $('#colonias').load(url);
  }); 
  });
  $('#estado').change(function(event){
  var idEstado = $('#estado').val();
  var url = 'comboMunicipio.php?idEstado='+idEstado;
  $('#municipio').load(url, function() {
    var idMunicipio = $('#municipio').val();
    var url = 'colonias.php?idMunicipio='+idMunicipio;
    $('#colonias').load(url);
  });
  });
  $('#municipio').change(function(event){
  var idMunicipio = $('#municipio').val();
  var url = 'colonias.php?idMunicipio='+idMunicipio;
  $('#colonias').load(url);
  }); 
});
 
 
Fuente de informacion: https://helpx.adobe.com/es/dreamweaver/using/web-applications.html 
 

5.2 Elementos de programacion

Cualquier lenguaje de programación trabaja con tres elementos:información, operaciones e instrucciones.
La información.

Esta se refiere a los datos con los cuales trabajarán los programas. Los datos suelen ser de dos tipos: numéricos y alfanuméricos (ó caracteres). Los datos se pueden agrupar formando estructuras, las estructuras pueden ser muy simples como las constantes (28) y las variables (x) o muy complejas como las matrices y registros. La figura nº 1.1 representa distintos tipos y estructuras de datos.

Estructura_de_datos.png


Las operaciones.
Se refieren a las operaciones que el ordenador es capaz de realizar con los diversos tipos de datos. Por ejemplo, la suma de dos números se puede realizar por un ordenador directamente; pero para realizar la suma de dos matrices habría que hacer un programa (existen algunos lenguajes de programación que permiten directamente realizar sumas de matrices).

Las operaciones pueden ser realizadas mediante operadores y funciones predefinidas que se aplican a un tipo de datos determinado. Por ejemplo, para los datos de tipo numérico se permiten los operadores suma, resta, división y producto, cuya operación se representaría:

a=5*3
c=6*b


Las funciones que dispone el lenguaje de programación para realizar operaciones se denominan predefinidas, ya que vienen definidas de antemano. Su utilización es como sigue:

a=sqrt(10)
b=log(b)


Normalmente para definir las operaciones con operadores y funciones se utiliza el término expresiones, que pueden ser operaciones con operadores, con funciones o con ambas, un ejemplo sería:

a=b*log(b)+sqrt(i)
​ Evidentemente existen expresiones tanto numéricas como de caracteres y estas expresiones pueden trabajar con distintas estructuras de datos.


Las instrucciones.
Las instrucciones (también denominadas sentencias) son el conjunto de órdenes que se le pueden dar al ordenador. En función del tipo de orden que indique al ordenador, las instrucciones se clasifican en los siguientes tipos:

-Instrucciones de entrada y salida (E/S).



Entrada_y_salida.png

​ También denominadas de lectura/escritura (L/S) ó input/output (I/O). Estas instrucciones se encargan de la información que necesita un programa para realizar su tarea y de la información que genera el programa. Son instrucciones del tipo: Almacena en la variable "nom" el nombre del usuario ó escribe el contenido de la variable "nom". Normalmente la entrada y la salida se realiza desde un fichero ya creado (información almacenada en un dispositivo magnético) o es el usuario quien suministra o recibe la información a través del teclado y pantalla del ordenador. A continuación se describen los dispositivos de entrada y salida más comúnmente utilizados por los ordenadores. Para cada uno de ellos existirían instrucciones de entrada y salida.

Dispositivos de entrada.

Son los utilizados para introducir la información en un ordenador. Los dispositivos de entrada más comunes son: ratón, escáner, sistemas ocr, módem, sistemas de audio, etc
​Existen además otros muchos dispositivos conectables al ordenador (que envían información a los dispositivos de procesamiento). Realmente se puede conectar cualquier dispositivo que generará alguna señal o información (osciloscopios, medidores de presión, alarmas, etc.).



Dispositivos de salida.
Operan con la información en sentido inverso al de los dispositivos de entrada; es decir, reciben la información del ordenador. Normalmente estos dispositivos muestran el estado de la información que contiene el ordenador.
Los dispositivos de salida más utilizados son la pantalla, la impresora, los plotters o el módem.


​ En general se puede conectar al ordenador cualquier dispositivo que para funcionar necesite un control mediante información. Podría ser un robot, una escalera mecánica, un reloj, etc.


-Instrucciones de control.

​ Son instrucciones que sirven para dirigir la ejecución de un programa. Normalmente un programa está compuesto por un conjunto de instrucciones que se ejecutan una tras otra. Las instrucciones de control permiten cambiar la secuencia de ejecución.

Son instrucciones del tipo: Si ocurre tal condición ejecuta determinadas instrucciones, de lo contrario ejecuta otras; ó cuando llegues a esta instrucción vete a la primera. La figura nº 1.5 muestra el control de la ejecución para este tipo de sentencias.


Instrucciones_de_control.png


-Instrucciones iterativas.

​Son instrucciones que permiten repetir un número determinado de veces un conjunto de instrucciones. Por ejemplo, si deseo realizar un programa que escriba los números enteros del 1 al 10.987.654 se puede realizar de dos formas: escribiendo diez millones novecientas ochenta y siete mil seiscientas cincuenta y cuatro instrucciones de salida o un sencillo bucle con cuatro sentencias. La figura nº 1.6 muestra la situación citada.

Instrucciones_iterativas.png

Elementos de los algoritmos.

Los algoritmos están muy ligados a los lenguajes de programación, de hecho, por cada elemento de los lenguajes de programación existe un elemento equivalente en algoritmia, la principal diferencia es su representación.

​ Mientras que para un lenguaje de programación los elementos se representan mediante una sentencia, los elementos de los algoritmos se pueden representan gráficamente. La representación gráfica de un algoritmo se denomina organigrama.
Un algoritmo indica una secuencia de pasos (parecido a una receta de cocina), la representación del mismo se puede hacer textualmente o gráficamente. En esta wiki utilizaremos principalmente la representación gráfica; así pues cuando se utilice la palabra organigrama nos estaremos refiriendo a la representación de los algoritmos. Además en los algoritmos también se indica el flujo de las órdenes; es decir la secuencia de ejecución, por tanto en los organigramas también se debe presentar este flujo. A continuación se describen los elementos de los organigramas:


- Información.
La información se representa mediante un conjunto de celdas y en cada celda se tiene un dato elemental. A lo largo del curso se describirán y representarán los distintos tipos y estructuras de datos.

- Expresiones.
​ En su representación no se distingue el tipo de expresión. Todas las expresiones se representan por un rectángulo y dentro del rectángulo se indica la expresión concreta. La figura nº 1.7 representa el símbolo de expresión, así como varios ejemplos de expresiones.


Expresiones.png


- Instrucciones.
En algoritmia cada tipo de instrucción tiene una representación gráfica distinta. Como siempre existen dos elementos: el símbolo gráfico que indica qué tipo de instrucción es y el texto que está dentro del símbolo, que indica la instrucción concreta. A continuación se describen brevemente los símbolos para cada tipo de instrucción más comúnmente utilizados. Los diferentes símbolos utilizados para realizar organigramas se describirán a medida que se analicen las distintas instrucciones que representan.



Instrucciones.png

-Flujo de instrucciones.

​El flujo de instrucciones en los organigramas se representa mediante flechas que indican la secuencia de ejecución. Es muy importante saber qué función se ejecuta primero y cual después, ya que de esta secuencia depende el correcto funcionamiento del programa.

​ En el ejemplo del niño que intenta cruzar la calle es muy importante que se guarde el orden indicado (primero mirar y después cruzar); ya se imaginará el lector qué ocurriría si se cambiara el orden (primero cruzar y después mirar).

​ El flujo secuencial se representa por la unión de los símbolos gráficos a través de una flecha, no obstante mediante las instrucciones de control esta secuencia se puede cambiar. La figura nº 1.10 muestra las dos situaciones.


Flujo_de_instrucciones.png