Recomendacionessobrelaadopcióndeunmodelode interoperabilidadparaelestadodechile RosaA.Alarcón DoctorenCienciasdelaIngeniería 06deAgostode2014
1. Títulodelproyecto Recomendaciones+ sobre+ la+ adopción+ de+ un+ modelo+ de+ interoperabilidad+para+el+estado+de+chile+ 3. Autor(es) Dr.RosaA.AlarcónChoque 2. Cuerpodelinforme hojas(incluyeportada) 4. Fechadelinforme 04/07/2014 5. AntecedentesdelaInstituciónMandante Nombre Dirección : Subsecretaria de Economía y Empresas de MenorTamaño : Av. Libertador Bernardo O'Higgins 1449, Torre II,SantiagodeChile. Teléfono : +56224733400 7. Resumen 6. Contrapartetécnica AndrésArellanoRecabarren DirectorGobiernoDigital EncoordinaciónconelEncargadode la División de Empresas de Menor Tamaño Estedocumentopresentaunresumendeconsideracionestécnicasquesirvendebaseaunconjuntode recomendaciones para la adopción de un modelo de interoperabilidad basado en el modelo arquitectónicorestparaelestadodechile. Dr.RosaA.AlarcónChoque
NormasGenerales 1 ElpresentedocumentopresentaelInformedelestudio Recomendaciones+sobre+la+ adopción+de+un+modelo+de+interoperabilidad+para+el+estado+de+chile desarrollado porencargodelaunidaddemodernizaciónygobiernodigital,ministeriosecretaria GeneraldelaPresidencia. 2 Los alcances de este infome están definidos explícitamente en la Sección 2 del presentedocumento. 3 Para el desarrollo de este infome se utilizó la información individualizada en la SecciónReferenciasquefueronaportadasporRosaA.Alarcón. 4 La información contenida en el presente informe no podrá ser reproducida total o parcialmente,parafinespublicitarios,sinlaautorizaciónpreviayporescritoderosa A.AlarcónmedianteunContratodeUsodeMarca. 5 LaUnidaddeModernizaciónyGobiernoDigitalpodrámanifestarydejarconstancia verbalyescrita,frenteaterceros,seanestosautoridadesjudicialesoextrajudiciales, que el trabajo fue preparado por la Dr. Rosa A. Alarcón, y si decide entregar el conocimiento del presente informe a cualquier tercero, deberá hacerlo en forma completaeíntegra,ynopartesdelmismo.
Contenido 1. Objetivos...5 2. Alcances...5 3. Metodología...5 4. Marcoconceptual...5 4.1 ServiciosWebTradicionales(WSDL,SOAPyWSb*)...5 4.2 ServiciosWebREST...6 4.3 Composición/WorkflowsdeserviciosREST...8 4.3.1 Modelodecomponentes...8 4.3.2 Modelodeaccesoadatos...8 4.3.3 Modelodeseleccióndeservicio...8 4.3.4 Modelodeorquestación(workflow)...9 4.4 RefinacióndelacomposicióndeserviciosconQoS...10 4.4.1 Composicióndeserviciosqueconsideraseguridad...10 4.4.1.1 ClavesdeAPI(APIkeys)...12 4.4.1.2 Nombredeusuarioycontraseña...12 4.4.1.3 HTTPBasicAuthentication...12 4.4.1.4 HTTPDigestAuthentication...12 4.4.1.5 OpenID...13 4.4.1.6 OAuth...13 4.5 ComposicióndeserviciosRESTconsiderandoseguridad...13 4.6 MonitoreoyAuditoriadeserviciosREST...14 5. RecomendacionesparalaadopcióndeunmodelodeinteroperabilidadREST...15 5.1 Modelodeaccesoadatos:APIREST...16 5.2 Consideracionesdediseñoarquitectónico...19 5.3 Modelodeorquestación...20 5.4 Seguridad...21 5.5 MonitoreoyAuditoria...22 6. Referencias...23 7. Anexo1:EspecificaciónRAML...28
1. Objetivos Definir un conjunto de recomendaciones para el diseño y adopción de un modelo de interoperabilidad para el Estado de Chile, particularmente considerando tecnologías WebligerastalescomoaquellasbasadasenREST. 2. Alcances ElalcancedeestedocumentoincluyeunarevisióndelosconceptosprincipalesdeREST pues estos van a justificar y dar detalles de los impactos de las recomendaciones propuestas.elalcancedeestedocumentoselimitaapresentarunmodelogeneralde servicios REST que comprende la composición de servicios (o workflow), aspectos de seguridad, monitoreo, auditoria y algunos detalles de diseño arquitectónico fundamentales. Las recomendaciones a realizarse buscan dar origen a políticas de estadoenlaimplantacióndedichomodelo. 3. Metodología Se hará una revisión de la literatura relevante y reciente así como de los productos, tecnologíasyestándaresquepuedanestarrelacionadosconelobjetivodeesteinforme. Estoselementosseránseñaladosenunaseccióndereferencias. 4. Marcoconceptual 4.1 ServiciosWebTradicionales(WSDL,SOAPyWSX*) Los Servicios Web tradicionales exponen datos y funcionalidad que puede ser consumida por otros servicios. Tradicionalmente, los servicios web proporcionan un documentowsdl(webservicedescriptionlanguage)[1]quedescribesuinterfazylas condiciones para ser consumidos(por ejemplo, con anotaciones WSbPolicyAttachment [2]).EstosserviciostípicamentesebasanenelestándardelaWebSOAP(SimpleObject Access Protocol) que también ha sido enriquecido para soportar características de seguridad, transparencia de ubicación, manipulación del despacho del mensaje, confiabilidad, etc. Estas características se implementan mediante una serie de estándares que apuntan a las propiedades no funcionales o de calidad (Quality( of( Service,( QoS) y en conjunto se denominan WSb* y han sido fuertemente por su complejidad y su dependencia de middleware (y altos costos) para poder ser manejables.( Las arquitecturas SOA típicamente explotan éste tipo de servicios para constituirse en un middleware que permite propiedades fundamentales tales como visibilidad,descubrimiento,consumoymonitoreodeservicios.estatecnología,expone en una dirección Web (URL) un punto único de entrada (endpoint)( a un conjunto de operacionessobreentidadesdedatosqueseocultanalcliente.(
Las operaciones se describen en un documento WSDL estándar; la semántica del servicionoesexplícitayporlogeneralrequierededocumentosadicionalesdestinadaa ingenieros que implementan los clientes del servicio, con el fin de comprender el alcance,efectos,condicionespreviasysuposicioneshechaspordiseñadoresdeservicio. Losclientesinteractúanconlosservidoressiguiendoladescripción;siéstacambia,los clientes fallan.los clientes no pueden recibir notificaciones sobre los cambios a la descripciónylasemánticadefallaysurecuperaciónsonadbhoc. Elprocesodecombinarlafuncionalidaddedosomásservicios(componentes)enuno nuevo(servicio compuesto) que proporciona valor agregado, se llama composición de servicios. En este informe se van a usar los conceptos workflow y composición de servicios refiriéndose a la idea de componer servicios. La selección de componentes adecuadospuedesermanualoautomática(esdecir,determinadaporunalgoritmo);el comportamientodelserviciocompuesto(esdecir,elordendeinvocacióndeserviciosy latransformacióndedatos)conformanunworkflowquesepuededeterminartambién deformamanualoautomática,yaseaentiempodediseño(composiciónestática)oen tiempodeejecución(composicióndinámica)[3]. La información que se produce durante la interacción entre un cliente particular y el servidor, es decir el estado de la aplicación, se mantiene en el lado del servidor (ej. Cookie( de( sesión,( la( instancia( o( thread( de( ejecución( de( un( workflow)( y por tanto se denomina Stateful, lo que repercute negativamente en la escalabilidad del servidor(y porendedelservicio)yaumentalacomplejidaddelastransaccionesdegranolargo(ej. Workflowsquetomanvariosdíasy/oinvolucranavariasentidades). EnresumenelSOAtradicional(basadoenWSDL,SOAPyWSb*)secaracterizaporuna altacomplejidad,unaescalabilidaddifícilycostosadeimplementar,altoacoplamiento, una difícil evolución de los servicios, y mecanismos sofisticados de seguridad, lo que requiereunmiddlewaresofisticadoyunafuertedependenciadeproveedores[4]. 4.2 ServiciosWebREST La Transferencia de Estado basada en Representaciones(REST, Representational State Transfer)eselnombredelestiloarquitectónicoenquesebasalaWebysecaracteriza porpermitirunaaltaescalabilidad,rendimientoycapacidaddeevolución,propiedades quetambiénsondeseablesparalosserviciosweb. Enestecontexto,elestiloarquitectónicoRESTpuedeentendersecomounsubconjunto restringido de SOA [1]. A diferencia de las operaciones WSDL, en REST los elementos centrales son los recursos, que son entidades abstractas identificados por URIs y que pueden ser manipuladas a través de una interfaz uniforme, es decir, un conjunto reducido de operaciones estándar cuya semántica es bien conocida de antemano por todos los componentes arquitectónicos (browsers, servidores, proxies, DNSs, caches, etc.), ejemplos de esta interfaz son el protocolo de transporte hipertextual, HTTP; el protocolodepublicaciónatom,atompub,etc.
En REST, el estado de la aplicación se modela explícitamente mediante recursos cuyo estado se transfiere a/de los clientes como consecuencia de la ejecución de las operaciones estándar. El estado se muestra a los clientes por medio de representaciones, que son documentos serializados según los tipos de medios específicos (por ejemplo, XML), y contiene enlaces a recursos relacionados (links) y controlesquepermitenalosclientesrealizaroperacionesquecambianelestadodelos recursos(porejemplo<link=urirel="service.post">,<form...>,etc.).nohaygarantía de que las operaciones, los recursos o incluso la red permanecen disponibles o sin cambios, sin embargo, debido a que existe una interfaz de falla uniforme (ej., los códigos de error del protocolo HTTP) con una semántica bien conocida, los clientes puedenrecuperarse. En un servicio REST no existen endpoints, sino entrypoints( a una red de recursos interconectados con un modelo hipermedial subyacente que determina no sólo las relacionesentrelosrecursos,sinotambiénlaposiblereddetransicionesdeestadode los recursos. Losclientes REST (ej. Browsers controlados por humanos) descubreny deciden que links/controles seguir/ejecutar dinámicamente. Esta restricción se conoce como HATEOAS (hipermedia como el motor del Estado aplicación) o simplemente hipermedia. LosserviciosRESTfulestáncobrandoimpulsoenlaindustriadebidoalasimplezadelas herramientas necesarias para implementarlos (a diferencia del middleware generalmente caro y complejo de SOA), su alta capacidad para proveer una mejora importanteencuantoadisponibilidad,escalabilidadyperformance(graciasaloscachés y statelesness, principalmente).((con el objetivo de garantizar una alta capacidad de evoluciónindependiente(yanárquica)ymantenerunacoplamientobajo,enrestnose considera necesaria la existencia de un documento de descripción de recursos. Los servicios REST aparecen con posterioridad a la definición de REST como un estilo destinadoalmanejoderecursosporpartedepersonas.enelmundosoa,sinembargo, una de las principales tareas es la integración, donde los clientes pueden ser otros servicios Web. En este entorno, la falta de esta una descripción de servicios limita la capacidad de consumir el servicio por parte de clientes de máquina (otros servicios) genéricos y en la práctica las llamadas Web APIs que cumplen el rol de servicios REST proveen amplia documentación, nuevamente destinada a los implementadores de clientes. Las diferencias arquitecturales entre los servicios WSDL/SOAP y REST (es decir, centralizado Vs. distribuido, centrado en operaciones Vs. centrado en recursos, fuertemente acoplado Vs. débilmente acoplado [5]), hacen difícil vislumbrar cómo aplicarlosresultadosdetecnologíasymetodologíasqueconsideransoawsdl/soapa los servicios REST. De acuerdo a Pautasso [6] se necesitan menos decisiones arquitectónicas al elegirse los servicios REST (son más simples), también se permite mayor flexibilidad y control por parte de los desarrolladores, independencia de los proveedores de soluciones envasadas, pero requiere experiencia técnica en cuanto a diseño, desarrollo y mantención, además no existen soluciones de middleware
especializado que ofrezcan características típicas del middleware WSDL/SOAP tales comotransacciones,confiabilidad,seguridadaniveldelmensajeenlugardelcontenido. 4.3 Composición/WorkflowsdeserviciosREST La composición de servicios incluye seis dimensiones: un modelo de componentes, un modelo de acceso a datos, un modelo de selección de servicio, un modelo de orquestación,unmodelotransacciones,yunmodelodecontroldeexcepciones[3,7]. 4.3.1 Modelodecomponentes EnWSDL/SOAP los servicios son los componentes principales de la arquitectura, en tantoqueenrestlosonlosrecursosylascoleccionesdelosrecursos[8,9].eldiseño de los componentes WSD/SOAP consideran supuestos a nivel de dominio (ej. Las operaciones), en tanto que en REST los supuestos se hacen a nivel de aplicación (ej. Mediatypes)ysonpocos,estandarizados,ybienconocidos.Esdecir,losrecursosdeben identificarse con una URI (Universal Resource Identifier); el estado de los recursos deben obtenerse mediante representaciones codificadas en algún estándar conocido (ej. HTML) o acordado con el cliente (ad hoc); los recursos deben ser manipulados a través de links( y controles (por ejemplo, un formulario HTML) incrustados en las representacionesdelrecurso;lasrepresentacionesdeterminanentiempodeejecución elconjuntodetransicionesdeestadodelosrecursosdisponiblesparalosconsumidores (hipermediacomoelmotordeestadodelaaplicación[10]). 4.3.2 Modelodeaccesoadatos Elmodelodeaccesoadatosdefinecómoseespecificayseintercambianlosdatosentre los componentes [11]. A diferencia de los servicios basados en WSDL, el modelo de datos consiste en representaciones estandarizadas que no se refieren a información específica de dominio (ej. Un esquema XML para pagar impuestos), sino que son modelosgenéricos,otiposdemedios(ej.text/html,etc),paraserinterpretadospor clientesgenéricos(ej.navegadoresweb).lainformaciónintercambiadaentreclientesy servidoressiguelasreglasdealgúnprotocolodered(ej.http,atompub,etc.),donde los mensajes deben incluir toda la información requerida por los servidores para procesarlos.esdecir,no(se(guarda(información(del(estadode(la(aplicación(en(el(servidor( (ej.cookiesdesesión),sinoelcliente(ej.caché). 4.3.3 Modelodeseleccióndeservicio Elmodelodeseleccióndeserviciodeterminacómoseeligeuncomponentedeservicio para ser parte de una composición, ya sea de forma estática(en tiempo de diseño) o dinámica (en tiempo de ejecución). En WSDL/SOAP la selección estática ocurre con ayuda de herramientas como buscadores en repositorios de servicios; la selección
dinámicaserestringealcampodelainvestigación.enrest,losclientesinspeccionanlas representaciones para encontrar los links y controles que marcan las transiciones posibles para un recurso y descubrir los URI delos componentes de servicio, así, el cliente encapsula la lógica de selección de servicio. La restricción de hipermedia desacopla clientes de servidores y permite a los servidores evolucionar de forma independiente(es decir, cambiar el nombre de host o la estructura URI en tiempo de ejecución),sinromperalosclientes.paratiposdemedioslimitados(ej.representación deoctetos),loscontrolessepuedenincrustarenlascabecerashttp(weblinking[12]). 4.3.4 Modelodeorquestación(workflow) El modelo de orquestación define el orden y las condiciones de invocación de los componentes de servicio. Cuando se centraliza el control de la invocación, el estilo se llama orquestación [13], y de lo contrario se llama coreografía. En un modelo de orquestaciónexisteuncomponentecentral(orquestador)quecoordinalainvocaciónde los componentes. Para WSDL/SOAP, las orquestaciones se pueden especificar en lenguajescomowsbbpel[14]ointerfacesgráficasparaesbsyejecutarsepormotores de orquestación. Para REST, debido a que no existe una descripción estándar del servicio, tampoco existen herramientas genéricas que faciliten la definición de orquestaciones. El estilo basado en navegaciones de REST permite naturalmente workflows implementados mediante recursos y transiciones (embebidas en representaciones). Sin embargo, la interacción es descentralizada, los componentes estándébilmenteacopladosypuedenmutarencualquiermomento.estacaracterística, llamada evolución, plantea un desafío a la composición de servicios ya que los componentes (recursos) pueden cambiar inesperadamente. Por lo tanto, los clientes deben hacer pocos supuestos sobre los recursos y retrasar la debreferencia con los recursosrealeshastaelmomentodelainvocación(enlacedinámicotardío)[8]. LainvestigacióneimplementacionesdeindustriaenWSDL/SOAPyRESTsecentranenla orquestación, siendo JOpera [8] el framework (de investigación) más maduro para el caso de REST. En JOpera, el control y flujo de datos se modelan visualmente mientras queunmotorejecutaelserviciocompuestoresultante.en[15],elcontrolylosdatosse modela e implementan usando una Red de Petri mientras que la interacción y comunicación con los recursos mismos se modela en una descripción de servicio denominadarell[16].en[17],elflujodecontrolseespecificaensparqlylosservicios invocadospodríanserendpoints(wsdl/soaposerviciosrest(esdecir,recursos);desde la perspectiva orquestador, los servicios se describen como grafos. En [18] las descripciones de grafo de los recursos están disponibles públicamente (puede ser descubiertas usando HTTP OPTIONS). Un conjunto de restricciones regula cuándo ciertos controles se pueden ejecutar en los recursos (por ejemplo, obtener cierto estado),demaneraqueunmotororquestadorpodríarealizarunacomposición,perono seindicacómoexpresaresasrestricciones.losdosprimerosenfoquespermitenenlace dinámicotardíoylarestriccióndehipermedia.en[19]seproponendiversasestrategias para implementar el orquestador en REST: un recurso dedicado a llevar registro del
estadodeunhilodecomposición(unainstanciadelworkflow),unconjuntoderecursos donde cada estado de la composición se modela explícitamente. Ambas alternativas permitenmonitoreoyloggingdelasactividadesrealizadasdurantelaejecucióndeuna instanciadeunworkflowporloquepuedenfacilitarlaauditoriadeservicios. 4.4 RefinacióndelacomposicióndeserviciosconQoS Las propiedades no funcionales, normalmente llamadas QoS (Quality of Service) [20] incluyencategoríasindependientesdeldominio,comoelrendimiento,laconfiabilidad, la seguridad, la integridad de transacciones, la red, la infraestructura y los costos de invocacióndeservicio,entreotros.lasqosseusanparadeterminarlaconvenienciao nodeinvocarunserviciocomponenteenlugardeotro.lamayoríadelosesfuerzosde estandarizaciónsobrecomposicióndeserviciossecentranenlosservicioswsdl/soap. En estos servicios, losdescriptores del servicio (WSDL) hacen posible especificar las propiedades funcionales de las operaciones, así como de las variables de entrada y salida; las propiedades no funcionales se especifican mediante una familia de estándares WSb* de industria (ej. WSbSecurity [21], WSbPolicy [22], etc) junto con técnicasbienconocidasavecesimplementadasdemodoadbhoc(ej.lafirma)[23]. WSb*hasidofuertementecriticadaporsucomplejidad,loquerequieredeunconjunto deherramientaseinfraestructurademiddlewaresofisticadoparapoderserpuestasen práctica.estetipodeapisesestándaryricoperoessumamentecomplejo,sinembargo alserestándarsepuedeleerpormáquinas(i.e.software)loquefacilitalacomposición deserviciosylaexistenciadeherramientasdeapoyo. 4.4.1 Composicióndeserviciosqueconsideraseguridad Lanecesidaddemantenerlasinteraccionessegurasesfundamentalparalosserviciosy con mayor razón para los servicios compuestos en la web y por lo tanto se hace importantelacapacidaddedescribirlascapacidadesyrequerimientosdeseguridadde losservicios[24,25].eldominiodelaseguridadnopuedesermodeladoporunaúnica métricayaqueabordavariasdimensiones,porejemplo: Confidencialidad:Serefierealosmecanismos(estándaroadbhoc)quepermitenla comunicación confidencial, como la codificación(ej. MD5, SHA1, SHA256). Cuando dosserviciosintercambianmensajesdemodoqueunterceractorinterceptandoel mensajenopuedeentenderlo,entonceslainteraccióngarantizaconfidencialidad. Integridad:Demanerasimilaralaconfidencialidad,seutilizanmecanismosdefirma digital para asegurar la integridad del mensaje. Muchos servicios implementan su propiomecanismodefirma(ej.ordenarlosdatos,aplicarunalgoritmodecifrado,y concatenar la clave resultante con el contenido original). Si un tercero no pudo alterar el mensaje enviado o se identifica correctamente que fue alterado y por tantosedeberechazar,lainteraccióngarantizalaintegridaddelmensaje. Autenticación:Serefierealosprotocolosutilizadosparacomprobarlaidentidadde
losactoresenunainteracción.sielreceptordeunmensajepuedecomprobarqueel remitenteesrealmentequiendiceser,lainteraccióngarantizaautenticación.siun remitente autenticado no es rechazado sin razón alguna, entonces se provee Non( Repudiation.(Estos incluyen autenticación básica HTTP y autenticación cifrada[26], OpenID[19],nombredeusuarioycontraseña,tokendeaplicación,etc.Todosellos se basan en tokens simples(ej. Strings) o complejos(ej. Certificados digitales) que representanlaidentidaddelcliente. Autorización: Se refiere a los mecanismos utilizados para conceder derechos( de( acceso( sobre algunos recursos, como el protocolo OAuth [27]. Estos mecanismos puedensertansimplescomounalistadecontroldeaccesootancomplejoscomo algoritmosdeautorizaciónquerequierenunasecuenciadepasos,coninformación parcialymecanismosdeseguridadencadapaso(ej.kerberos). Estasdimensionestípicamentesecombinan,loquehacecomplejomodelareldominio deseguridadparaunservicio.losrequerimientosdeseguridadpuedendeterminarsede formaestática(ej.losdatosdebenserencriptados),perotambiénpuedenimplicarun comportamientodinámico(ej.protocolosdeautenticación)proporcionadoatravésde coreografías en la Web (ej. el protocolo de autorización de OAuth [27] que involucra redireccionesdelcliente). En[29]sereconocelanecesidaddelapuestaenprácticayverificacióndepolíticasde seguridadygestióndeseguridaddistribuidasparaservicioswsdl/soap,yunasolución basada en dominios jerárquicos y atributos transversales a las distintas entidades de seguridad es propuesto. Las políticas se aplican por medio de monitores distribuidos que filtran y controlan el flujo de información entre los servicios. Un enfoque más limitado es presentada por[30], donde un mecanismo de control de acceso se lleva a cabo sobre la base de un modelo de cálculo de eventos y monitores compatibles que garantizanlaejecucióndeunapolíticadeseguridad. NoexisteunesfuerzodeestandarizaciónsimilarenelcampodelosserviciosREST;por ejemplo, la seguridad Web ha evolucionado orgánicamente para hacer frente a las necesidadestecnológicasydeusuarioquehanidoapareciendo,dandolugaraenfoques ligeros,descentralizadosycomplementarioscapacesdeescalarconlademanda,riesgos de seguridad y bajas garantías de la Web. En Maleshkova et al. [31] se presenta una revisióndelaswebapisrestquehasidoautodeclaradasasí(incluyendowsdl,rest, basadoenxml,apiweb,etc.)enelsitioprogrammablewebencuantoasuapoyode mecanismosdeseguridad.seanalizaron222serviciosdelacategoríadeserviciosrest (18%), que abarca 51 categorías de servicios (ej. búsqueda, geolocalización, etc). Los mecanismos de seguridad encontrados incluyen una variada gama de prácticas desde lasmássencillas(lamayoría),alosestándaresdelw3cenmateriadeseguridadenla Web.Porejemplo,38%utilizaclavesdeAPI(APIkeys)conelfinúnicofindecontarlos accesosdeclientesautenticados(noautorización),mientrasqueelprotocolooauthes utilizadoporel6%delservicioinformado.hayquetenerencuenta,sinembargo,que los principales proveedores de servicios REST (ej. Facebook, Twitter, Google, etc)
permiten y requieren autenticación OAuth debido a casos de fraude y robo de identidad.acontinuaciónsepresentanestosmecanismos. 4.4.1.1 ClavesdeAPI(APIkeys) Es una estrategia de autenticación simple donde las credenciales de los consumidores para recuperar un recurso restringido pasan directamente al proveedor dentro de la solicitud.enestecaso,lacredencialeslaapi(keyqueidentificaalclienteynotienepor quéestarcifradaofirmada;estaestrategianoproveeniconfidencialidad,niintegridad, niautorización[33]. 4.4.1.2 Nombredeusuarioycontraseña Este es otro ejemplo de estrategia de autenticación simple donde las credenciales se envíandirectamentedesdeelconsumidoralproveedor,peroenestecasoserequiere tanto credenciales de identificación( y contraseña. Las credenciales no tienen por que estarcifradasofirmadasyelmensajetienelaspropiedaddeautenticaciónúnicamente, aunque debido a que es más fuerte que la API key, puede usarse con mecanismos complementarios(ej.acl)paragarantizarautorización. 4.4.1.3 HTTPBasicAuthentication Este es un protocolo más complejo para la autenticación. Este es un estándar compatible con la mayoría de los navegadores web [19]; su objetivo es proporcionar másseguridadalenvíodeinformacióndeautenticaciónentextoplano.esteprotocolo requierecompartirlascredencialesdelosclientesenunacadenaopacaenviadaatravés del cliente Web en el encabezado de una solicitud HTTP, siguiendo un mecanismo de cifradoconocidocomocodificaciónbase64yunalgoritmosimpledefirma.igualquela autenticaciónporusuarioycontraseña,estaestrategiaaseguraautenticación,ypuede serusadoparaautorización. 4.4.1.4 HTTPDigestAuthentication LaAutenticaciónBásicaporHTTPnoesunprotocolomuyseguroparalaautenticación de usuarios, porque la entidad codificada se transmite como texto que se puede decodificarfácilmente.elestándarwebhttpdigestproporcionaunapoyomásfuerte, ycomplejoalaconfidencialidadylaintegridad.elnombredeusuarioylacontraseñade las credenciales deben ser firmados con ciertos atributos, proporcionados por el servidorseguro,mediantemecanismostalescomomd5.esteprotocoloseimplementa endosfasescuyosresultadosintermediosvancifradosydebenconcatenarse.eneste caso se asegura autenticación, confidencialidad e integridad, y puede ser usado para autorización[26].
4.4.1.5 OpenID Este protocolo de autenticación es significativamente diferente de los demás, ya que requiereunainteracciónconunterceroquevalidalapruebadeidentidad.estetercero es el proveedor de OpenID; un consumidor (usuario) puede autenticarse contra un serviciomediantelapresentacióndeuntoken(generadoporunproveedordeidentidad conelqueelconsumidorseharegistradoanteriormenteyenelqueconfíaelservicio [19]. 4.4.1.6 OAuth OAuth [27] es un protocolo de autorización abierto que permite a una aplicación de terceros(unservicio)accederalosrecursosproporcionadosporunservicio(servidorde recursos) que son propiedad de un usuario reconocido por el servidor de recursos.el usuariotienequeautorizaralaaplicacióndetercerosparaaccederalosrecursos,sin necesidad de que el usuario exponga sus credenciales de autenticación a la aplicación deterceros.laautorizaciónserepresentacomountokentemporalopermanente. 4.5 ComposicióndeserviciosRESTconsiderandoseguridad EnREST,lainvestigaciónsobrecomposicióndeserviciosesbastanterecienteyelinterés enlaspropiedadesdecalidaddeserviciosehancentradoprincipalmenteenseguridad. Porejemplo,en[34]unserviciobasadoenAPIsRESTsedefineparaapoyaracuerdosde nivel de servicio basados en el estándar WSbAgreement [35]. Los acuerdos (y sus plantillas) se modelan como recursos REST codificados en el tipo de medio application/xml,cuyociclodevidayestadosemanejapormediodeverboshttp.graf etal.[36]presentanunmarcodecontroldeacceso,autorizaciónenelladodelservidor basado en reglas que limitan el acceso a los recursos servidos de acuerdo a las operacioneshttp[36].en[37]unmarcodeobligacionesdelladodelservidorpermitea los diseñadores de servicios extender un núcleo de políticas existentes con reglas que regulan el acceso a la información de los usuarios. Las reglas pueden desencadenar transacciones adicionales (ej. el envío de un correo electrónico de confirmación, el registro del intento de acceso a la información para futuras auditorias) o incluso modificar el contenido de la respuesta o el protocolo de comunicación(ej. Cambiar a HTTPS).Allam[23]buscahomologarlosserviciosyRESTyWSDL/SOAPconsiderándolos cajas negras, donde la interacción ocurre como un simple paso de mensajes entre clientesyservidores.laspolíticasdeseguridadsepuedencolocaralrecibiroalenviar un mensaje, así como a nivel local, es decir, en el lado del servidor o del cliente. Esta visiónsinembargonotieneencuentalainteraccióncomplejaqueinvolucraaterceros (ej.oauth),olaheterogeneidaddelainterfazdelservicio[38],dondelosestándaresde la industria se aplican de diversas maneras (ej. firmas que usan SHA256, pero la modificanasugusto).
4.6 MonitoreoyAuditoriadeserviciosREST En el área de los servicios Web tradicionales, organizaciones como la Organización de InteroperabilidaddeWebServices(WSbI)promuevenlainteroperabilidadentrediversas plataformaseimplementacionesguiandolaelecciónycombinacióndeestándareswsb* yfomentandolapuestaenmarchadebuenasprácticasatravésdeunaseriedeperfiles. Conelfindeasegurarlaconformidaddeunaimplementaciónparticularaalgúnperfil específico,seplanteaelusodeherramientasdemonitoreo,registro(logger)yanálisis, que se conocen en conjunto como WSJI( Testing( Tools( [39]. El WSbI Monitor es un componenteintermediarioqueactúainterceptandolosmensajessoapintercambiados entre un Web service y un cliente, generando registros de los eventos es un formato quepuedeseranalizadoposteriormenteparadeterminarlaconformidaddelaconducta del Web services y los formatos de mensajes (ej. Schemas) con algún Perfil WSbI. La mayoríadelosproveedoresdemiddlewaredeinfraestructura(jaxbwsdesun/oracle, Metro de Sun/Oracle, WCF WSb* de Microsoft, AXIS2 de Apache, etc.) afirman ser compatiblesalmenosconelperfilbásicodewsbi. En[40],elmonitoreoestáestrechamenterelacionadoconelworkflowuorquestación puessonlosmodelosespecíficosdeesteúltimolosquedeterminancómoyhastacierto puntoquémonitorear.zurmuehlen[41]clasificalastécnicasdemonitoreoycontrolde procesosdentrodelasorganizacionesdesdecuatroperspectivas:laperspectivadelos datos, la perspectiva del uso, la perspectiva de la herramienta y la perspectiva del método. La perspectiva de los datos se refiere a la recogida, almacenamiento y representación de la información para auditoría. La perspectiva de uso se refiere a la forma en que se aborda la gestión de control de procesos (por ejemplo, manejo de excepciones,gestiónglobaldelosprocesos,etc.).laperspectivadelaherramientatiene que ver con la arquitectura y las herramientas que se han desarrollado para el monitoreo y control, y la perspectiva del método esta relacionada con los enfoques conceptualesdemonitoreodeprocesosycontrol. La importancia del monitoreo aumenta cuando aumenta la dimensión de la infraestructura o servicios provistos, por ejemplo, en una plataforma de Cloud Computing, el monitoreo puede llegar a proveerse como un modelo adicional de servicio(monitoringbasbabservice,maas)[42].enestecaso,elmonitoreoincluyetareas tales como medición de consumo, aprovisionamiento, supervisión, facturación, planificacióndelacapacidad,conformidadconlaspolíticasdeseguridadacordadascon losclientes,gestióndelosnivelesdeservicio(slas)einformesparadartransparencia tantoparaelproveedorcomoparaelconsumidordelservicioutilizado[41]. EnelcasodeREST,alnoexistirinfraestructuraqueimplementeworkflows(exceptode investigación, tal como JOpera) el monitoreo se hace con base en los mensajes intercambiados entre cliente y servidor. Estas técnicas conocidas como Web( traffic(
analysis,puedenbasarseenweb(logs 1 (quesonregistrosdelosmensajesrecibidospor el servidor, incluyendo HTTP( headers y el código de respuesta que se envía al cliente. Los Web logs son archivos de texto plano que pueden llegar a ser extremadamente voluminosos pues el registro no discrimina el tipo de recurso solicitado, por lo tanto solicitudesdearchivosmediales(ej.fotos,iconos,etc.),deestiloydescriptingtambién son considerados. Los Web logs son posteriormente analizados para encontrar información relevante tal como tiempo de respuesta de las solicitudes de recursos, eficacia del almacenamiento en caché e intermediarios (ej. firewalls, analizadores de seguridad y sistemas de gestión y logging) [43], escalabilidad, planificación de la capacidadyrespuestaaataquesdedenegacióndeservicio[44],amenazasdeseguridad [45],opatronesdenavegación(consumo)[46],entreotros.Muchasvecesesteanálisis estediosopuesrequiereprocesamientodetextoplano,paraevitarestatareaalgunos permiten un registro en base de datos en paralelo, de todos los eventos que se consideren relevantes (no únicamente trafico de mensajes). En cualquier caso, es importantedeterminarquémonitorearpuesestosarchivospuedencrecerrápidamente y convertirse en un cuello de botella si la estrategia de escritura no está apropiadamenteimplementada. Elmonitoreoylaauditoriaestánfuertementerelacionados,peromásalládehablarde auditoria, quizás es conveniente hablar de responsabilidad (accountability [47]), entendida como la obligación última de actuar como administrador responsable en la protección y uso apropiado de la información personal de terceros. Desde esa perspectivaseconsideraunframeworkpreventivo,dedetecciónydecorreccióntantoa nivel de los usuarios(políticas de acceso, violación de estas y corrección de acciones), proveedores (políticas y análisis de riesgo, detección de intrusos y atribución de responsabilidades)comodelasautoridades(políticasdeprivacidad,auditoriayreportes de violaciones de políticas, evidencias y solución de disputas). En todos estos casos únicamentesepuedenejerceraccionesdeauditoriayatribuciónderesponsabilidadessi los mecanismos de monitoreo recolectan toda la información necesaria, en muchos casos sin embargo, esto no es posible y es necesario realizar una tarea tediosa de análisisdelosdiferenteslogsquemantienenlossistemas. 5. RecomendacionesparalaadopcióndeunmodelodeinteroperabilidadREST En la sección 4.2 se describen las características de los servicios REST así como se presenta una breve discusión de sus ventajas y desventajas frente a los servicios WSDL/SOAP. En la sección 4.3 se plantean las características que deben tener los servicios compuestos, orquestaciones o workflows (en este informe estos tres conceptosseplanteanenlasacepcionesqueloshacensinónimos)rest.enestasección sepresentanalgunasrecomendacionesparaponerenprácticaestosconceptos. 1 http://httpd.apache.org/docs/1.3/logs.html
5.1 Modelodeaccesoadatos:APIREST DeacuerdoaFielding,autordeREST,una APIRESTdeberíadedicarlamayoríadesus esfuerzos descriptivos en definir los tipos de medios a utilizar para representar los recursos y avanzar el estado de la aplicación (i.e. incluir links y controles), o en la definiciónderelacionesextendidas,y/oenmarcashipertextualesparatiposdemedios estándar. Las APIs REST actuales mantienen tipos de medios conocidos(por ejemplo JSONoXML)ydedicansusesfuerzosendescribircómo(parámetros,URIs,etc.)deben ser consumidos los recursos y cuáles son las respuestas posibles, generando una enormevariaciónencuantoanotaciones(porejemplodocumentoshtmldescribiendo enlenguajenaturallaapi,documentosenjsondescribiendounejemplodelaapi,etc.) yestilosdelaapi.algunospocosesfuerzossehandedicadoadefiniryregistrartiposde medios(porejemplo,application/vnd.msbexcel)enregistrospúblicostalescomoiana 2. Estetipodeenfoqueesposibledebidoaquecorrespondenaunúnicoproveedorque hacelosesfuerzosposiblesparadefiniralgunaspocasestructurasderecursosgenéricas (por ejemplo entre 4 o 6) sobre las cuales se opera. En un escenario de diferentes actores (i.e. las entidades del estado) con diferentes servicios a proveer resulta casi imposible pensar en la definición de tipos de medios generales que puedan ser reutilizadosentodaslasentidades(porejemplo,application/vnd.rutbgov). Unasoluciónqueconjugalaflexibilidadnecesariaporlosproveedoresdeservicioscon la necesidad de estandarizar la provisión misma del servicio lo constituyen las descripciones de interfaces de servicio tales como WSDL. En REST se han propuesto algunoslenguajesdedescripcióntalescomowsdl2.0,wadl,wrdl,wdl,hal,rell, etc.peroningunohageneradolamasacríticanecesariaparaserprobadoenlaindustria y demostrar sus ventajas. Los primeros 4 han sido criticados por lo engorroso de su descripción,porserinnecesariamenteverbososypornorespetarlascaracterísticasde REST, los dos últimos en cambio respetan las características de REST, pero son propuestasdeinvestigaciónquenohanatraídoatenciónporpartedelaindustria. Recientemente algunas propuestas de documentación REST tales como Swagger 3, Blueprint 4 yraml 5 estánganandotracciónenlaindustriapuessonpropuestassimples yprácticas.lasdosprimerascubrenelciclodevidadedesarrollodeserviciosrestcasi completamenteperosonempresasdedicadasatemasnorelacionadosconintegración. EnelcasodeRAML,éstaesunapropuestabasadaenYAML 6 yjson 7,quesecentra únicamente en la descripción de APIs REST dejando a los desarrolladores la 2 http://www.iana.org/assignments/media8types/media8types.xhtml 3 https://helloreverb.com/developers/swagger 4 http://apiary.io/blueprint 5 http://raml.org/ 6 http://www.yaml.org/ 7 http://json.org/
responsabilidad y libertad de su implementación. RAML considera los aspectos prácticosderestdejandoaldesarrolladorlapropiedaddehipermedia;ramlpresenta ademásunacargagramaticalbaja,loquefacilitasuaprendizaje.ramlesunapropuesta de MuleSoft 8, que es una empresa de integración con 8 años de experiencia con inversiones de SalesForce, Cisco y SAP Ventures entre otros y que suma 150.000 usuariosyclientestalescomoaccenture,equifax,nestlé,mastercard,etc.enlafigura1 sepresentaunadescripciónramldeejemployenelanexo1suespecificación. 1. #%RAML 0.8 2. title: World Music API 3. baseuri: http://example.api.com/{version} 4. version: v1 5. traits: 6. - paged: 7. queryparameters: 8. pages: 9. description: The number of pages to return 10. type: number 11. - secured: include http://raml-example.com/secured.yml 12. /songs: #% 13. is: [ paged, secured ] 14. get: 15. queryparameters: 16. genre: 17. description: filter the songs by genre 18. post: 19. /{songid}: 20. get: 21. responses: 22. 200: 23. body: 24. application/json: 25. schema: 26. { "$schema": "http://json-schema.org/schema", 27. "type": "object", 28. "description": "A canonical song", 29. "properties": { 30. "title": { "type": "string" }, 31. "artist": { "type": "string" } 32. }, 33. "required": [ "title", "artist" ] 34. } 35. application/xml: 36. delete: 37. description: 38. This method will *delete* an **individual song** Figura1.EjemplodeunaAPIRESTespecificadaenRAML Como se ve en la figura 1 el desarrollador tiene la libertad de especificar el servicio según sus necesidades, si bien esta flexibilidad es positiva en ese sentido, también constituye un riesgo pues diferentes desarrolladores pueden seguir diferentes 8 http://www.mulesoft.com/
estrategias y realizar malas prácticas. Es importante que los supuestos fundamentales de las APIs sean claros y explícitos [48]. Adicionalmente, en la Figura 1, línea 25 se especificaunesquemadedatosparticularparalascanciones(quesondefinidascomo objetos enelesquema http://json-schema.org/schema ),esdecir,ramltambién permitedefinirestructurasdedatosconsemánticasclarasquepuedenserreusadasen workflowsuotrosservicios,usadascomoreferenciasparaotrosdesarrolladores,usadas paravalidacióndelasllamadasdelservicioyqueporclaridadpuedenserdefinidasen documentosexternosalasapisrestrequiriendoportantorevisionesdecalidadyun repositorio.porestarazónseintroducenlassiguientesrecomendaciones: Recomendación 1: Definir un comité de gobernanza de SOAbREST, que contemple el ciclo de vida de los servicios, es decir el registro de servicios, la versión de servicios, la propiedad del servicio, modelación de servicios, composición de servicios, estrategias de descubrimiento y acceso a servicios, despliegue de servicios atómicos y workflows, seguridad de servicios, acuerdos deniveldeserviciosygestióndeservicios[49],ciclodevidadelosesquemasde datosycontroldecalidaddelosmismos. Recomendación 2: Adherir a algún estándar de descripción de interfaz de servicios(apisrest),enparticularserecomiendaraml. Recomendación3:CrearymantenerunrepositoriodeesquemasdedatosyAPIs RESTdemaneraquesefomenteelreusodeesquemasyservicios,secontribuya adifundirbuenasprácticasenlaconstruccióndeesquemasyapis,conelfinde facilitarlainteroperabilidadentrelosorganismosdelestado. En la Web existen diversos registros (IANA, IETF, ICANN, etc.) que facilitan la interoperabilidadentrelosdiferentescomponentesdelared.encuantoaapisresthan surgidodiferentesregistrosinformales(programmableweb 9,Mashape 10 )quehansido utilizadosporlacomunidadparadifundirinterfacesdeservicios(restono)paraotros desarrolladores. El registro debe conceptualizarse y diseñarse (su interfaz) como una herramientaparalabúsquedadeserviciosconloscualesinteroperaryparalabúsqueda deinterfacesqueresuelventareassimilares(yaseadelobjetivofinaldelservicioodela tecnología utilizada o desde el diseño de la interfaz) y que pueden servir a los desarrolladores como insumos del diseño de un workflow o como ejemplos para el diseñodesuspropiasinterfaces. Recomendación 4 : El comité de gobernanza debe aprobar y registrar los esquemas y APIs REST velando fundamentalmente por la existencia de buenas prácticas en el uso de los conceptos REST, HTTP, en el reuso de esquemas de datos,recursos,estrategiasdeseguridad,etc. 9 http://www.programmableweb.com/ 10 http://www.mashape.com/
Estaactividadesparticularmenteimportanteyesunapracticaseguidaporejemplopor IANA para el registro de tipos de medios, donde ingenieros expertos validan si el tipo propuesto ya existe y la propuesta es únicamente una variación del mismo o se diferencia en el uso del tipo o se están violando las reglas gramaticales o semánticas paraladefinicióndetipos.delamismamaneraelcomitédegobernanzadeberávigilar la sintaxis, semántica e intención del servicio propuesto así como los requisitos no funcionalesasociados. Recomendación5:Elcomitédegobernanzadebevigilareldiseñoarquitectónico delserviciopropuestoconelfindedetectarmalasprácticasdediseño. 5.2 Consideracionesdediseñoarquitectónico No solo es importante cómo la interfaz es diseñada sino que también es importante cómo el servicio (simple o workflow) es diseñado. Por ejemplo en los servicios Web tradicionales(wsdl/soap)elmétodohttppostseutilizacomountúnelparaenviar mensajes y se utiliza mal la semántica del método. Algunos desarrolladores podrían generar APIs REST para encapsular la llamada a servicios tradicionales violando el protocolo HTTP (estrategia seguida por WSDL 2.0). Debido a que el middleware tradicionalescasiimposibledemodificardemaneraqueaquellosserviciosdeconsulta utilicengetenlugardepost,estaviolaciónalprotocolodebeserpermitidaenlaapi REST,perodebeinformarselacausademaneraquenointroduzcaerroresfuturos. OtroproblematípicoestárelacionadoconlaimplementacióndelapropiedadStateless, esdecir,queelservidornodebeguardarmemoriadelasconversacionespreviasentre el cliente y servidor. Un ejemplo típico lo son las cookies de memoria que guardan el hecho de que el cliente se ha autenticado previamente (Statefull). Una solución para mantenerautenticacióndeserviciosinestadoloconsisteoauthqueutilizaauntercero parageneraruntokendeseguridadqueespasadoalcliente,demaneraquetodaslas transaccionesdebenenviarcomounparámetroeltokenquedemuestraqueelcliente estáautenticado. FinalmenteunasituaciónquerequiereexperienciadediseñoeselmanejodeCachés,el objetivo de los Cachés es permitir la replicación de los recursos, aún más acercar las réplicas al cliente final. Claramente esto tiene sentido si el recurso puede mantener múltiples copias consistentes durante algún tiempo, un ejemplo de ésta situación lo constituyen los recursos mediales (fotografías, iconos, imágenes de fondo, javascript, CSS, etc.), que toman ventaja de la existencia de los intermediarios Web (proxies, gateways,proxiesinversos,etc.)ydelprotocolohttpmediantelosheadersdemanejo de caché. En el caso de las transacciones, éstas no necesitan (por lo general) estar cacheadasporloquenotomanventajadelusodelainfraestructurahttpconestefiny
pueden utilizar otro tipo de infraestructura (por ejemplo un ESB) que otorgaría potencialmenteventajastalescomoseguridadyconfiabilidad. 5.3 Modelodeorquestación Respecto del modelo de orquestación, recordemos que en REST un servicio es un conjuntoderecursos(porejemplomedialestalescomoíconos,scripts,etc.)algunosde los cuales pueden ser recursos que representen instancias de un workflow(ver Figura 2). Teniendo como meta la escalabilidad, tiempo de respuesta, disponibilidad, flexibilidad, capacidad de ser monitoreado y auditado, se hace la siguiente recomendación. Recomendación 6: DebecapacitarsealosdesarrolladoresdeaplicacionesREST en los aspectos arquitectónicos del estilo y en sus consecuencias en cuanto a requisitosnofuncionales. Recomendación 7: Debendefinirsepatronesdediseñoparalaimplementación de workflows REST. Particularmente se propone el patrón de orquestación centralizada,sinestado,queseapreciaenlafigura2. Cliente <<resource>> Workflow <<servicio>> Servicio1 <<resource>> Workflow/{id} <<resource>> Log/{id} <<service>> Servicio2 <<resource>> Productos (1) (2) (3) (4) (5) (6) (7) POST /Workflow 303 (See Other) Location: /Workflow/{id} GET /Workflow/{id} Crea instancia 200 (OK) Actualiza estado de instancia GET /productos 200 (ok) lista de productos (8) (9) (10) POST /Log/{id} evento sincrono 200 (ok) Figura2.EjemplodeunaOrquestacióncentralizada,sinestado. Esdecir,unWorkflowpuedesermodeladocomounrecursoqueencapsulalalógica del mismo (un orquestador), y cada instancia (invocación o ejecución) del mismo se modelacomounrecursoadicional(porejemploworkflow/{id}),generadoapartir delainvocacióndelworkflow,comoseapreciaenlafigura2,mensajes1y2.eneste enfoque, el cliente conoce la URL del Workflow y requiere una instancia del mismo