0% encontró este documento útil (0 votos)
42 vistas27 páginas

Arquitectura y Seguridad de Web Services

Cargado por

Milton Delgado
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
42 vistas27 páginas

Arquitectura y Seguridad de Web Services

Cargado por

Milton Delgado
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd

Universidad Nacional de Jujuy

Facultad de Ingeniería – Programación y Servicios Web


▪ Según W3C son sistemas software diseñados
para soportar una interacción maquina a
maquina sobre una red.
▪ Los Servicios Web pueden ser accedidas dentro de
una red (principalmente Internet). Las aplicaciones
proveen sus Web Service mediante una API, para
que otras aplicaciones clientes puedan usar sus
funcionalidades.
“La arquitectura de software es el diseño de más alto
nivel de la estructura de un sistema” [Wikipedia].
Indican la estructura e interacción entre las partes del
software”.
En lo que respecta a la arquitectura de software basado
en WebSerivce, las arquitecturas mas conocidas son:
SOAP (Simple Object Acces Protocol)
• Se tiene un servicio FarmaciaService con métodos getAll(), getById()
• Gran capacidad pero mucha complejidad.
REST (Representation State Transfer)
• Basado en RECURSO, es la alternativa en auge a SOAP.
• Propone transferencia sencilla de datos.
▪ (REpresentation State Transfer – Transferencia de
representación de estado).
▪ Los Servicios Web basados
en REST intentan emular al
protocolo HTTP mediante la
restricción de establecer la
interfaz a un conjunto
conocido de operaciones
(GET, POST, ...)[3]
▪ El resultado a las llamadas
son datos en formato JSON,
XML.
- En REST la clave son los RECURSOS (sustantivos)
accesibles e identificados mediante URIs
(identificador único de recurso).

[Link] (GET recupera recurso)

- Sobre esos recursos podemos realizar acciones,


generalmente diferenciadas a través de verbos,
en sincronía con los métodos del protocolo HTTP.
Los métodos de HTTP son utilizados por
desarrolladores estableciendo relaciones con las
operaciones (CRUD) de Create, Reed, Update,
Delete sobre el RECURSO:
[Link] (GET recupera recurso)

[Link] (POST agrega/modifica )

[Link] (DELETE borra el recurso)

[Link] (PUT modifica el recurso )

[Link] (GET recupera recursos)


REPOSITORIO ([Link]

Code Sniped: Código en


diferentes lenguajes ejecutado
para consumir el Webservice.
Tambien parámetros.
Result: vemos el resultado del
WebService.
export class TranslateService {
constructor(private _http:HttpClient) { }
public getLanguajes():Observable<any>{
const httpOptions = {
headers: new HttpHeaders({
'X-RapidAPI-Host': '[Link]',
'X-RapidAPI-Key': '5a891b3bfemshbe636412126e564p1450a6jsne66d35508b88'
}),
}
return this._http.get("[Link] httpOptions);
}
public translateText(source:string, target:string, text:string):Observable<any>{
const httpOptions = {
headers: new HttpHeaders({
'content-type': 'application/x-www-form-urlencoded',
'X-RapidAPI-Host': '[Link]',
'X-RapidAPI-Key': '5a891b3bfemshbe636412126e564p1450a6jsne66d35508b88',
}),
}
const body = new HttpParams()
.set('q’, text)
.set('target’, target)
.set('source’, source);
return this._http.post("[Link] httpOptions);
}
}
Las respuestas se pueden hacer en lenguaje como:
JSON (application/json) XML (application/xml)

JSON: Menos indicadores, Menor tamaño, nativo de javascript.


Lista de Métodos Aceptados:
▪ Es importante para un servicio restringir
adecuadamente cuales métodos serán
aceptados (GET, POST, PUT o DELETE), para
que sólo aquellos que sean aceptados
funcionen,
▪ Mientras que los demás métodos retornen un
código de error (por ejemplo un error “403
Forbidden”).
/** CODIGO DE UNA API EN SYMFONY
* @Route("/farmacia")
*/
class FarmaciaController extends AbstractController
{ [Link]
/**
* @Route("/", name="farmacia_index", methods={"GET"})
*/
public function index(Request $request): Response {
..... }
[Link]
/**
* @Route("/new", name="farmacia_new", methods={"POST"})
*/
public function new(Request $request): Response {
..... }
Consulta de un articulo publicado: debes conocer el item_id
asociado al producto y, como es público, puedes obtenerlo.

DOCs de la
API de
MercadoLibre

Ej Articulo => [Link]


Lenguaje de descripción de aplicaciones web.
Según la W3C la descripción de servicios juega un
papel importante en el acceso a un servicio.
La descripción ser realiza en archivo basado en
XML que proporciona una descripción legible por
máquinas de aplicaciones web basadas en HTTP,
como “WebService REST”.
▪ permite la creación automática de esqueletos de
código
▪ búsquedas más fáciles y la clasificación de
servicios.
Es el acto o proceso que “se encarga de validar si el
cliente que entra (log in) a un sistema software es la
entidad que dice ser” [2].
Actualmente, casi todos los servicios web requieren algún
tipo de autenticación previa.
Excepciones de APIs que no requieren autenticación:
▪ Site: ([Link]
▪ [Link]
APIs que sí requieren autenticación:
▪ Site: ([Link]

▪ [Link]
REST se basa en HTTP, por ende “no se puede
llamar a un servicio REST pasandole unos datos (p.
ej. usuario y contraseña) y esperar que nos
recuerde en la siguiente petición. De ahí el
nombre de protocolo “sin estado”, es el cliente
quien debe pasar el estado (quien soy) en cada
llamada”. Una técnica es el uso de cookies.
Soy xxx dame listado de productos
Toma el listado de productos

dame listado de ventas de hoy


ERROR – quien eres?
Los WebService REST debido al uso intrínseco de
HTTP se vuelve más vulnerable en la red frente a
intercepción de mensajes. El uso de REST sobre
HTTPS puede ser una solución.

(HTTP) Información legible

(HTTPS) Información encriptada


En vez de loguearse del modo que lo hacen otros
protocolos (SSH, FTP) HTTP envía la información de
autenticación en cada mensaje [3]. Soluciones:
▪ Uso de un protocolo de usuario-contraseña,
▪ Uso de una API Key como un argumento en el
cuerpo del mensaje HTML.
▪ Uso de un Token de sesión (OAuth 2) vía POST,
▪ Se aplica Basic HTTP Authentication con HTTPS, pues
no necesita la ayuda de APIs o frameworks
adicionales. El nombre de usuario y una contraseña
ingresado se codificarán en Base64.
[Link]
Un API Key es un identificador que sirve como el medio de
autenticación de un cliente para el uso de los servicios. Es
la primer medida elegida por muchos desarrolladores.
▪ La Obtención es desde un archivo de configuración, o
▪ Para APIs de uso masivo los usuarios las generan.
Por lo general, una clave API da acceso completo a cada
operación que puede realizar una API.
Se debería pasar en el encabezado de Autorización de una
petición HTTP.
Authorization: Apikey 1234567890abcdef
Permite autorización segura de una API de modo estandar
para aplicaciones web, moviles, etc, basado en tokens.
▪ OAuth 1.0: mediante firma digital se obtiene el token
▪ OAuth 2. Elimina la firma digital por lo que necesita https
para encargarse de la encriptación, menos seguro.
OAuth propone el uso de uno o ambos de estos tokens:
▪ Acces token: similar a las API-KEY, los token pueden caducar.
▪ Refresh token: recuperan un Access token nuevo si ha caducado.
▪ [1]Rafael Navarro Marset. ELP-DSIC-UPV Modelado, Diseño e
Implementación de Servicios Web 2006-07
▪ [2] Durán Macías, Á. Securización de REST.
▪ [3] Navarro Marset, R. (2006). Modelado, Diseño e
Implementación de Servicios Web. RES T vs Web Services.

También podría gustarte