HAL 9K

We can recall that the only real boss of the architect is requirements . The architect may not listen to us, to developers, to customers, to anyone. But the requirements are the indisputable boss. So, there is not mystery neither magic over the decision making process, it must be ruled by the requirements. But, what was this project about? In fact, it was about consuming a SOAP service provided by a third part, to allow our internal business side to update the customer case-file or unique digital profile. As part of this project, the number of request from our platform to the provider side must be under certain control or below a number we can consider acceptable for our consuming rate. Also, for both services, our own service and the one from the provider, working with bio-metric data is a must, it involves fingerprints and face recognition. So let’s start looking deeper into this project.

Suele pasar en este mundo de la tecnología que, cada cierto tiempo, tenemos a todo el mundo hablando y usando determinada solución, producto o herramienta, sin ninguna otra razón de peso  mas que la moda, o que el "main stream" de turno dice que es la forma correcta de hacer las cosas. Entre esas tecnologías o soluciones de moda nos encontramos con los ya harto renombrados, microservicios . Todo el mundo habla de ellos, todo el mundo migra hacia ellos, ... pero, y siempre hay un pero, ¿son en verdad tan beneficiosos los microservicios ? ¿Cuanto hay de mito y cuanto de, ¿fea?, realidad?

Video donde revisamos algunos conceptos y modo de funcionamiento de OAUTH 2.0.

Siguiendo con la onda de seguridad, autenticación y autorización, hoy vamos a hablar de uno de los elementos que ya hemos mencionado como parte de estos mecanismos, los ya famosos Json Web Token o JWT , el cual es un String  que cumple con el estándar RFC 7519 para transmitir información con la identidad y claims de un usuario de forma segura entre un cliente/servidor. Dicha información puede ser verificada y confiable porque está firmada digitalmente.

En nuestro capítulo anterior   vimos cómo implementar Proof Of Key en el lado del servidor usando OAUTH 2.0 con SpringBoot . Hoy corresponde enfocarnos en ese concepto del lado del cliente. En esta oportunidad vamos a desarrollar una aplicación que interactúe con el servidor o proveedor de OAUTH  tras demostrar que está en posesión de la clave privada relacionada con la clave pública que se nos provee en el JWT correspondiente. Al igual que la anterior, esta publicación va a hacer uso de Java 8 , Maven , Spring Web , Spring Security  y Nimbus JOSE + JWT .

Hace rato que OAUTH 2.0 viene estando presente en el escenario de seguridad en IT . El post que hoy nos ocupa tiene como propósito mostrar un ejemplo funcional del esquema Prueba de posesión de clave, del ingles Proof Of Possession (POP) of key usando Spring Boot . Este ejemplo usa como base el código presentado en el maravilloso libro, OAUTH 2.0 Cookbook, la diferencia es que este SI FUNCIONA!!! ;)

Es mucho el artículo, publicación y blogs de , ¿supuestos?, entendidos en el tema que hablan sobre, o exponen el problema con, el uso o más bien ABUSO de los Getters y Setters en la programación orientada a objetos (OOP). Es este un tema recurrente y para nada nuevo, no señor, de hecho viene dando vueltas en el entorno de desarrollos OOP desde hace un buen rato. Pero.... ¿Cuál es el gran problema con usar getters y setters?