Por qué JWT es la clave para proteger su aplicación empresarial y por qué KumuluzEE podría ser su nuevo mejor amigo

Hoy en día, nos preocupamos cada vez más por el rendimiento y, al mismo tiempo, queremos saber cómo los sistemas pueden comunicarse de forma rápida y fiable. Muchas veces queremos enviar información y mantenerla lo más confidencial y segura posible. A veces, los datos confidenciales también deben moverse a través de la web de forma pública y desencadenar acciones en el otro extremo del cable. En la mayoría de los casos, queremos generar acciones que provoquen mutaciones de datos. En estos casos, no solo buscamos proteger nuestros datos. Queremos asegurarnos de que las acciones desencadenadas por el envío de nuestros datos sean confiables. Podemos proteger nuestros datos de varias formas. Lo más habitual es que enviemos los datos a través de una conexión segura (Transport Layer Security). Eso garantizará que nuestros datos se encripten a través del cable. Usamos certificados para crear relaciones de confianza entre dos partes y lograr esto. En este artículo, quiero analizar el estándar y ver más a fondo cómo podemos integrar en una aplicación común. En este caso, echaremos un vistazo a . Echemos un vistazo a algunos conceptos básicos. o JSON Web Token, o mejor aún, JavaScript Object Notation Web Token, es un estándar definido en . Este estándar ha sido, como todos los estándares (Request For Comments), definido, escrito y publicado por el (Internet Engineering Task Force). Puede definirse de múltiples formas. En general, podemos decir que es una forma compacta y segura de transmitir reclamaciones entre dos partes. Una forma de simplificar lo que es una reclamación es, básicamente, describirla como un par nombre/valor que contiene información. Necesitamos esta información para garantizar algunos aspectos importantes de nuestra comunicación por Internet. Necesitamos asegurarnos de que la información que recibimos esté validada y sea confiable en primera instancia. Luego, necesitamos validarla. Básicamente, esto es todo. Para implementar este estándar, podemos usar varios marcos que pueden ayudarnos a implementar una aplicación empresarial Java. Spring Boot se usa ampliamente. Muchas veces también se envuelve bajo otro nombre en software propietario de ciertas organizaciones como bancos y otras organizaciones financieras. Para nuestro ejemplo, decidí hacer algo diferente. En lugar de Spring Boot, vamos a echar un vistazo a un ejemplo con . El objetivo es identificar exactamente qué es y cómo se ve. Las aplicaciones empresariales de Java son básicamente aplicaciones que se pueden implementar en un servidor de aplicaciones o simplemente ejecutarse por sí solas mediante el uso de un servidor integrado. Como ejemplo, las aplicaciones Spring Boot se ejecutan en un servidor Tomcat integrado. En este artículo, nos centraremos en . Al igual que Spring Boot, también contiene un servidor integrado. Excepto que en este caso se llama Jetty. Esto se usa en combinación con Weld para proporcionar CDI (inyección de dependencia de contexto). Todos los estándares de tecnología Java y son compatibles con este . TLS JWT JWT Enterprise KumuluzEE JWT RFC7519 RFC IETF JWT KumuluzEE JWT KumuluzEE EE Jakarta EE framework 2. Ejemplo de caso Para ejemplificar cómo funciona en su forma básica, tuve que pensar en una forma de presentarlo. Los ejemplos clásicos en los que la seguridad es una preocupación son los bancos. Sin embargo, crear una aplicación bancaria completa para mostrar cómo funciona sería una pérdida de tiempo y tal vez se involucrarían demasiados conceptos. En cambio, lo que hice es un sistema bancario muy simple. Nuestra principal preocupación es mostrar cómo fluyen los datos a través de la red y cómo los usuarios obtienen acceso a ciertas áreas de nuestra aplicación. Tampoco voy a hablar de TLS o de cómo podemos enviar información cifrada a través de la red. Nos centraremos en en su forma más pura. Nuestro caso es un sistema bancario utilizado por un grupo que defiende la naturaleza y el medio ambiente. Esta es solo una forma divertida de mostrar cómo funciona . El personaje principal de esta Liga de la Naturaleza es Lucy, que se está convirtiendo en un personaje común en todos mis artículos. JWT JWT JWT JWT 3. Arquitectura Antes de comenzar, dibujemos un boceto de nuestra aplicación en ejecución. Es una aplicación muy simple, pero aun así es bueno dibujarla: La razón por la que esto es tan simple es que, dado que se verifica en cada solicitud y cada solicitud se verifica con la clave pública, entonces sabemos que, siempre que enviemos el token correcto en cada solicitud, podremos pasar. se puede integrar con OAuth2, Okta SSO o cualquier otro mecanismo de autorización. En este caso, lo que estamos haciendo es establecer la autenticación y la autorización. En nuestra aplicación, vamos a utilizar y, con él, autenticar nuestro mensaje mediante una firma. Sin embargo, no iniciaremos sesión en la aplicación. En su lugar, autorizaremos a los usuarios a utilizar nuestra aplicación después de una autenticación exitosa. En este punto, es fácil ver que en su núcleo es en realidad una parte muy pequeña de una aplicación completa. No obstante, es necesario agregar algunas funciones. Estos son los recursos que necesitamos: JWT JWT JWT JWT Sistema de equilibrio Sistema de crédito Digamos que nuestro sistema básico solo registrará solicitudes de dinero y crédito. Básicamente, solo acumulará valores. Supongamos también que algunas personas podrán obtener crédito y otras no. Algunas personas podrán almacenar dinero y otras podrán obtener crédito. 4. Elección de tecnologías Como se mencionó en la introducción, utilizaremos como nuestro marco de aplicación empresarial e implementaremos una aplicación ultrabásica de manera que podamos ver la terminología y los conceptos básicos . Asegúrese de tener la versión correcta de Java. En esta etapa, necesitaremos tener instalado el SDK de Java 17 como mínimo. Necesitaremos maven, git, un IDE compatible con Java como IntelliJ y algún tipo de shell. KumuluzEE JWT 5. Configuración Para comenzar nuestra aplicación, tenemos algunas dependencias . Esto se debe principalmente a que , al igual que Spring Boot, necesita un par de dependencias. Echemos un vistazo al archivo POM brevemente: KumuluzEE KumuluzEE com.kumuluz.ee.openapi kumuluzee-openapi-mp com.kumuluz.ee.openapi kumuluzee-openapi-mp-ui com.kumuluz.ee kumuluzee-microProfile-3.3 ch.qos.logback logback-core ch.qos.logback logback-classic org.jetbrains.kotlin kotlin-stdlib org.assertj assertj-core test org.junit.jupiter junit-jupiter test io.mockk mockk-jvm test com.ninja-squad springmockk test io.kotest kotest-assertions-core-jvm test Analicemos brevemente algunas dependencias. Mientras lee esto, siga nuestro archivo de arriba a abajo. Esto es importante para comprender la siguiente explicación. Necesitamos un paquete de dependencias para que nuestra aplicación funcione. Afortunadamente, nos proporciona bibliotecas Microprofile que contienen paquetes estándar básicos para iniciar esta aplicación. Todo esto está contenido en la biblioteca -Microprofile. Para poder configurar nuestra aplicación con todos los parámetros que necesitamos, tenemos que agregarle una biblioteca MicroProfile. Al mismo tiempo, necesitamos una biblioteca de procesamiento JSON. Esto será lo que hará Johnson Core. Por supuesto, necesitamos el núcleo de para funcionar. Jetty es el servidor subyacente que ejecuta el marco . Es por eso que lo necesitamos en nuestras dependencias. Considerando que necesitamos , también necesitamos una biblioteca que lo admita. Para habilitar nuestros puntos finales REST, necesitamos la biblioteca rest de . Para obtener nuestra API, necesitamos una biblioteca Geronimo. Esto garantizará que tengamos una implementación de disponible. También necesitamos interpretar nuestro y su contenido Lombok no es realmente necesario per se. ¡Solo hace que todo sea hermoso y brillante! Logback también es importante para que podamos interpretar mejor los registros y comprender nuestros resultados. Ahora echemos un vistazo a nuestra carpeta . Para comenzar, primero entendamos qué esperamos encontrar en esta carpeta. Necesitamos configurar nuestra aplicación con algo relacionado con , Logback y, finalmente, necesitamos decir algo sobre los beans que vamos a crear. Veamos el archivo más simple allí. El beans.xml se puede encontrar en META-INF: pom.xml KumuluzEE KumuluzEE JWT KumuluzEE KumuluzEE CDI KumuluzEE JSR-374 JWT JSON-formatted resources JWT Este es un archivo típico y, como puede que estés pensando ahora, un poco antiguo. En este punto, la idea es simplemente poner en funcionamiento . Tenemos una acción de exclusión. Esto le dice a Weld que no considere la clase Accounts en su acción de escaneo de beans. Esto es importante porque con la implementación que estamos usando, básicamente considerará cada clase con un constructor vacío como un bean. Veremos más adelante por qué no queremos que Accounts se considere un bean. Por el momento, tengamos en cuenta que estamos realizando solicitudes en el ámbito Request. Esto es lógico porque cada solicitud puede tener un usuario diferente. Veamos ahora cómo se implementa " ". También se encuentra en : KumuluzEE Weld logback META-INF %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n Esta es una configuración muy sencilla para nuestros . Por último, quizás el archivo más importante de nuestra aplicación. Se trata de la plantilla de configuración. En este punto, es importante tener en cuenta que algunos de los archivos que he creado en este proyecto son parte de una estructura de plantilla. Explicaré más sobre esto más adelante. Se supone que este archivo de plantilla se debe convertir en un archivo config.yml que será leído por MicroProfile. Este archivo se encuentra en la raíz de los recursos: logs kumuluzee: name: your-financeje-banking version: 1.0.0 jwt-auth: public-key: {{ publicKey }} issuer: {{ issuer }} healthy: true Más adelante veremos qué significan exactamente todas estas propiedades. Todas se explican por sí solas. La clave pública y el emisor son parámetros que se reemplazarán. Lo exploraremos más adelante. Nuestros scripts bash se asegurarán de que se reemplacen. Ya casi estamos listos para comenzar a codificar, pero primero, echemos un vistazo a la estructura de nuestro token . JWT 6. Código práctico Vamos a crear nuestra aplicación muy pequeña. En esta sección, explicaremos cómo podemos hacer que nuestra aplicación funcione con . Lo que queremos ver es si podemos especificar que los usuarios accedan a algunos de nuestros métodos y no a otros. Una de las formas de comenzar a analizar este código es echar un vistazo a nuestro token simple. Aquí está nuestro ejemplo de administrador: JWT REST JWT { "iss": "joaofilipesabinoesperancinha", "jti": "01MASTERFINANCE", "sub": "admin", "aud": "nature", "upn": "admin", "groups": [ "user", "admin", "client", "credit" ], "user_id": 1, "access": "TOP", "name": "Admin" } Cada uno de estos nombres en nuestro se denomina reclamaciones. En nuestro ejemplo, vemos algunas reclamaciones reservadas: JSON " ": este es el emisor del token. Podemos elegir un valor arbitrario para este parámetro. El valor de este parámetro debe coincidir con la variable del emisor que se reemplazará en el archivo config.yml que hemos visto antes. iss " ": este es un identificador único del token. Podemos usar esta afirmación, por ejemplo, para evitar que un token se use dos o más veces. jti " ": este es el sujeto del token. Puede ser el usuario o cualquier otra cosa que queramos. Es importante tener en cuenta que también se puede utilizar como identificador, clave, nombre o cualquier cosa que queramos. sub " ": nombre principal del usuario. Se utiliza para identificar el principal que utiliza el usuario. upn " ": es una matriz de los grupos a los que pertenece el usuario actual. Básicamente, esto determinará lo que puede hacer una solicitud con este token. En nuestro token, vemos algunas reclamaciones personalizadas. Podemos usarlas de la misma manera que las reclamaciones reservadas. groups " ": usaremos esto para establecer el ID del usuario. user_id " " — Determinaremos el nivel de acceso del usuario. access " " — El nombre del usuario. name 7. Código práctico Hagamos un resumen de lo que sabemos hasta ahora. Sabemos que nos comunicaremos con tokens con una estructura que hemos determinado. Además, hemos configurado nuestra aplicación, la configuración de logback y, por último, configuramos una configuración personalizada para la búsqueda de enterprise bean. Veamos el modelo de paquete. Aquí encontraremos 3 clases. Estas clases básicamente representan una agregación de cuentas y la representación entre y . De esta manera, podemos comenzar mirando el archivo kotlin Model.kt donde se encuentra : client account Client data class Client constructor( @JsonProperty var name: String ?= null ) Esta primera clase modelo es la representación de nuestro cliente. Nuestro para nuestro caso solo tiene un nombre. Este es el nombre de usuario representado por el atributo " ". Además, tenemos : client jwt Account data class Account( @JsonProperty val accountNumber: String?, @JsonProperty val client: Client? = null, @JsonProperty var currentValue: BigDecimal = BigDecimal.ZERO, @JsonProperty var creditValue: BigDecimal = BigDecimal.ZERO ) { fun addCurrentValue(value: Long) = Account( accountNumber, client, currentValue .add(BigDecimal.valueOf(value)), creditValue ) fun addCreditValue(value: Long): Account = Account( accountNumber, client, currentValue, currentValue .add(BigDecimal.valueOf(value)) ) } En esta clase, básicamente configuramos un accountNumber, un client, un currentValue y finalmente un creditValue. Observe que estamos estableciendo todos los valores en 0 de forma predeterminada. También estamos usando BigDecimal, simplemente porque estamos tratando con dinero. El dinero debe ser exacto y no puede sufrir redondeos del sistema hacia arriba o hacia abajo. Esto significa, en otras palabras y como ejemplo, que un número como euros debe seguir siendo ese número todo el tiempo. Además, queremos agregar valores a nuestra cuenta. Aquí es donde entra en juego el método addCurrentValue. Por las mismas razones, también recargaremos nuestro crédito con . Finalmente, en la última parte de nuestra configuración de datos nos encontramos con la clase : 0000000000000000000000000000000000000000000000000001 addCreditValue Accounts open class Accounts constructor( open val accountMap: MutableMap = mutableMapOf() ) En esencia, se trata de un agregador de todas nuestras cuentas. Usaremos el contenido de su mapa para imitar el comportamiento de una base de datos. Ahora, veamos el paquete del controlador. Aquí es donde creamos nuestra aplicación que se ejecuta con nuestro modelo de datos. Primero, echemos un vistazo a la clase : BankApplication @LoginConfig(authMethod = "MP-JWT") @ApplicationPath("/") @DeclareRoles("admin", "creditor", "client", "user") class BankApplication : Application() Con esto, estamos diciendo 3 cosas importantes. Con la anotación LoginConfig, la definimos para usar y entender los tokens según MicroProfile. La ApplicationPath define la raíz de la aplicación. Aquí es donde comenzará la URL de la aplicación. En nuestro ejemplo, será . Finalmente, DeclareRoles define los roles que serán utilizados y aceptados por nuestra aplicación. Roles y Grupos son términos intercambiables en esta situación. Para que la inyección funcione de manera eficiente, creamos una anotación específica para identificar el mapa de cuentas: JWT HTTP://localhost:8080 annotation class AccountsProduct Entrar al modo de pantalla completa Salir del modo de pantalla completa A continuación, creamos una fábrica de objetos de caché AccountsFactory: class AccountsFactory : Serializable { @Produces @AccountsProduct @ApplicationScoped fun accounts(): Accounts = Accounts(mutableMapOf()) companion object { @Throws(JsonProcessingException::class) fun createResponse( currentAccount: Account, name: JsonString, accounts: Accounts, log: Logger, objectMapper: ObjectMapper, principal: Principal?, jsonWebToken: JsonWebToken? ): Response { val jsonObject = Json.createObjectBuilder() .add("balance", currentAccount.currentValue) .add("client", name) .build() accounts.accountMap[name.string] = currentAccount log.info("Principal: {}", objectMapper.writeValueAsString(principal)) log.info("JSonWebToken: {}", objectMapper.writeValueAsString(jsonWebToken)) return Response.ok(jsonObject) .build() } } } Esta fábrica es la razón por la que deshabilitamos la búsqueda específicamente para . En lugar de permitir que el proceso de búsqueda cree un bean, creamos la instancia del agregador nosotros mismos. El uso de la anotación Produces nos permite crear el bean. Al usar nuestra anotación personalizada, AccountsProduct, hacemos que el uso de este bean sea más específico. Finalmente, al usar , definimos su alcance como el alcance . En otras palabras, el bean de agregación de cuentas se comportará como un objeto singleton en toda la aplicación. " " es solo un método genérico para crear respuestas JSON. Lo que necesitamos ahora son dos "Resources". Esto es básicamente lo mismo que " " en Spring. Es un nombre diferente, pero tiene exactamente el mismo uso. Veamos la clase : Accounts ApplicationScoped Application createResponse Controllers AccountsResource @Path("accounts") @RequestScoped @Produces(MediaType.APPLICATION_JSON) open class AccountResource { @Inject @AccountsProduct open var accounts: Accounts? = null @Inject open var principal: Principal? = null @Inject open var jsonWebToken: JsonWebToken? = null @Inject @Claim("access") open var access: JsonString? = null @Claim("iat") @Inject open var iat: JsonNumber? = null @Inject @Claim("name") open var name: JsonString? = null @Inject @Claim("user_id") open var userId: JsonNumber? = null @POST @RolesAllowed("admin", "client", "credit") @Throws(JsonProcessingException::class) open fun createAccount(): Response = createResponse( requireNotNull(accounts).accountMap[requireNotNull(name).string] ?: Account( client = Client(name = requireNotNull(name).string), accountNumber = UUID.randomUUID().toString() ) ) @POST @RolesAllowed("admin", "user") @Path("user") @Throws(JsonProcessingException::class) open fun createUser(): Response { return createResponse( requireNotNull(accounts).accountMap[requireNotNull(name).string] ?: Account( client = Client(name = requireNotNull(name).string), accountNumber = UUID.randomUUID().toString() ) ) } @GET @RolesAllowed("admin", "client") @Throws(JsonProcessingException::class) open fun getAccount(): Response? { return createResponse( requireNotNull(accounts).accountMap[requireNotNull(name).string] ?: return Response.serverError() .build() ) } @PUT @RolesAllowed("admin", "client") @Consumes(MediaType.APPLICATION_JSON) @Throws( JsonProcessingException::class ) open fun cashIn(transactionBody: TransactionBody): Response? { val userAccount = requireNotNull(accounts).accountMap[requireNotNull(name).string] ?: return Response.serverError() .build() val currentAccount = userAccount.addCurrentValue(transactionBody.saldo?: 0) requireNotNull(accounts).accountMap[requireNotNull(name).string] = currentAccount return createResponse(currentAccount) } @GET @Path("all") @Produces(MediaType.APPLICATION_JSON) @Throws( JsonProcessingException::class ) open fun getAll(): Response? { val allAccounts = ArrayList( requireNotNull(accounts).accountMap .values ) logger.info("Principal: {}", objectMapper.writeValueAsString(principal)) logger.info("JSonWebToken: {}", objectMapper.writeValueAsString(jsonWebToken)) return Response.ok(allAccounts) .build() } @GET @Path("summary") @Throws(JsonProcessingException::class) open fun getSummary(): Response? { val totalCredit = requireNotNull(accounts).accountMap .values .map(Account::currentValue) .stream() .reduce { result, u -> result.add(u) } .orElse(BigDecimal.ZERO) val jsonObject = Json.createObjectBuilder() .add("totalCurrent", totalCredit) .add("client", "Mother Nature Dream Team") .build() logger.info("Summary") logger.info("Principal: {}", objectMapper.writeValueAsString(principal)) logger.info("JSonWebToken: {}", objectMapper.writeValueAsString(jsonWebToken)) return Response.ok(jsonObject) .build() } @GET @RolesAllowed("admin", "client") @Path("jwt") open fun getJWT(): Response? { val jsonObject = Json.createObjectBuilder() .add("jwt", requireNotNull(jsonWebToken).rawToken) .add("userId", requireNotNull(userId).doubleValue()) .add("access", requireNotNull(access).string) .add("iat", requireNotNull(iat).doubleValue()) .build() return Response.ok(jsonObject) .build() } @Throws(JsonProcessingException::class) private fun createResponse(currentAccount: Account): Response = AccountsFactory.createResponse( currentAccount, requireNotNull(name), requireNotNull(accounts), logger, objectMapper, principal, jsonWebToken ) companion object { val objectMapper: ObjectMapper = ObjectMapper() val logger: Logger = LoggerFactory.getLogger(AccountResource::class.java) } } Tómese un momento para observar esta clase con más detalle. La anotación define cómo llegar a este recurso desde la raíz. Recuerde que estamos usando "/" como raíz. En este caso, "accounts" es nuestro punto de acceso raíz para este recurso. Todos nuestros recursos, en nuestro caso solo dos, se ejecutan con el alcance RequestResource. Con la anotación Produces se determina que todas las respuestas a todas las solicitudes, independientemente de su tipo, tomarán la forma de mensajes con formato JSON. Para inyectar nuestro solo usamos la combinación de la anotación Inject y la anotación : Path aggregator AccountsProduct @Inject @AccountsProduct open var accounts: Accounts? = null Esto coincide con lo que definimos en la fábrica. Además, también estamos inyectando dos elementos importantes de seguridad: un y el : principal jsonWebToken @Inject open var principal: Principal? = null @Inject open var jsonWebToken: JsonWebToken? = null Tanto como serán iguales, y lo veremos en nuestros registros. En nuestros recursos, siempre podemos inyectar reclamos desde una solicitud con un token determinado: JsonWebToken Principal @Inject @Claim("name") open var name: JsonString? = null @Inject @Claim("user_id") open var userId: JsonNumber? = null Esto se logra con la combinación de las anotaciones y . El nombre colocado debajo de la anotación define qué claim queremos inyectar. Debemos tener cuidado con el tipo con el que definimos nuestros parámetros. En nuestro ejemplo, solo necesitamos los tipos y Primero, veamos cómo estamos creando cuentas y usuarios: Inject Claim Claim JsonString JsonNumber @POST @RolesAllowed("admin", "client", "credit") @Throws(JsonProcessingException::class) open fun createAccount(): Response = createResponse( requireNotNull(accounts).accountMap[requireNotNull(name).string] ?: Account( client = Client(name = requireNotNull(name).string), accountNumber = UUID.randomUUID().toString() ) ) @POST @RolesAllowed("admin", "user") @Path("user") @Throws(JsonProcessingException::class) open fun createUser(): Response { return createResponse( requireNotNull(accounts).accountMap[requireNotNull(name).string] ?: Account( client = Client(name = requireNotNull(name).string), accountNumber = UUID.randomUUID().toString() ) ) } Creación de cuentas y usuarios El objetivo aquí es poder separar los métodos y darles diferentes permisos. En nuestro ejemplo, ambos solo crean una cuenta, pero es importante notar que solo los usuarios con roles de usuario pueden usar el método createUser. De la misma manera, solo los usuarios con roles de cliente y crédito pueden acceder al método createAccount. Veamos ahora en detalle el método de solicitud PUT de este recurso: @PUT @RolesAllowed("admin", "client") @Consumes(MediaType.APPLICATION_JSON) @Throws( JsonProcessingException::class ) open fun cashIn(transactionBody: TransactionBody): Response? { val userAccount = requireNotNull(accounts).accountMap[requireNotNull(name).string] ?: return Response.serverError() .build() val currentAccount = userAccount.addCurrentValue(transactionBody.saldo?: 0) requireNotNull(accounts).accountMap[requireNotNull(name).string] = currentAccount return createResponse(currentAccount) } Cobrando Sabemos que la anotación indica que este método solo es accesible con solicitudes de tipo . La anotación Path le indica a Jetty que la ruta a este método es un valor. Esto también se conoce como . Finalmente, podemos definir que este método solo pueda ser utilizado por usuarios con roles de administrador o cliente. El valor de entrada se pasa a nuestra variable de valor Long mediante el uso de PathParam. Si no definimos ningún rol, cualquier usuario con el token correcto podrá acceder a estos métodos. se implementa de la misma manera: PUT PUT PathParam CreditResource @Path("credit") @RequestScoped @Produces(MediaType.APPLICATION_JSON) open class CreditResource { @Inject @AccountsProduct open var accounts: Accounts? = null @Inject open var principal: Principal? = null @Inject open var jsonWebToken: JsonWebToken? = null @Inject @Claim("access") open var access: JsonString? = null @Inject @Claim("iat") open var iat: JsonNumber? = null @Inject @Claim("name") open var name: JsonString? = null @Inject @Claim("user_id") open var userId: JsonNumber? = null @GET @RolesAllowed("admin", "credit") @Throws(JsonProcessingException::class) open fun getAccount(): Response = requireNotNull(accounts).let { accounts -> createResponse( accounts.accountMap[requireNotNull(name).string] ?: return Response.serverError().build() ) } @PUT @RolesAllowed("admin", "credit") @Consumes(MediaType.APPLICATION_JSON) @Throws( JsonProcessingException::class ) open fun cashIn(transactionBody: TransactionBody) = requireNotNull(accounts).let { accounts -> requireNotNull(name).let { name -> accounts.accountMap[name.string] = (accounts.accountMap[name.string] ?: return Response.serverError() .build()).addCreditValue(transactionBody.saldo?: 0L) createResponse( (accounts.accountMap[name.string] ?: return Response.serverError() .build()).addCreditValue(transactionBody.saldo?: 0L) ) } } @GET @Path("all") @Produces(MediaType.APPLICATION_JSON) @Throws( JsonProcessingException::class ) open fun getAll(): Response? { val allAccounts = ArrayList( requireNotNull(accounts).accountMap .values ) logger.info("Principal: {}", objectMapper.writeValueAsString(principal)) logger.info("JSonWebToken: {}", objectMapper.writeValueAsString(jsonWebToken)) return Response.ok(allAccounts) .build() } @GET @Path("summary") @Produces(MediaType.APPLICATION_JSON) @Throws( JsonProcessingException::class ) open fun getSummary(): Response? { val totalCredit = requireNotNull(accounts).accountMap .values .map(Account::creditValue) .stream() .reduce { total, v -> total.add(v) } .orElse(BigDecimal.ZERO) val jsonObject = Json.createObjectBuilder() .add("totalCredit", totalCredit) .add("client", "Mother Nature Dream Team") .build() logger.info("Summary") logger.info("Principal: {}", objectMapper.writeValueAsString(principal)) logger.info("JSonWebToken: {}", objectMapper.writeValueAsString(jsonWebToken)) return Response.ok(jsonObject) .build() } @GET @RolesAllowed("admin", "client") @Path("jwt") open fun getJWT(): Response? { val jsonObject = Json.createObjectBuilder() .add("jwt", requireNotNull(jsonWebToken).rawToken) .add("userId", requireNotNull(userId).doubleValue()) .add("access", requireNotNull(access).string) .add("iat", requireNotNull(iat).doubleValue()) .build() return Response.ok(jsonObject) .build() } @Throws(JsonProcessingException::class) private fun createResponse(currentAccount: Account): Response { return AccountsFactory.createResponse( currentAccount, requireNotNull(name), requireNotNull(accounts), logger, objectMapper, principal, jsonWebToken ) } companion object { val objectMapper: ObjectMapper = ObjectMapper() val logger: Logger = LoggerFactory.getLogger(CreditResource::class.java) } } La única diferencia es que en lugar de usar los roles y , ahora usamos los roles y . Además, tenga en cuenta que las cuentas de los usuarios nunca se crearán en este . Eso solo es posible a través del de la cuenta. Ahora que sabemos cómo se implementa el código, primero recapitulemos qué métodos hemos puesto a disposición en nuestro servicio . admin client admin credit resource resource REST 8. Uso de la aplicación Veamos la lista de los servicios que se utilizan: Tipo, URL, Carga útil, Resultado, Roles permitidos CORREO, créditos,Todos http://localhost:8080/accounts,n/a,Creado cuenta,administrador/cliente/crédito CORREO, http://localhost:8080/accounts/user,n/a,Creado usuario,admin/usuario CONSEGUIR, http://localhost:8080/accounts,n/a,Coincidencia cuenta,administrador/cliente PONER, http://localhost:8080/cuentas,{saldo: Largo}, Saldo actual, admin/cliente CONSEGUIR, http://localhost:8080/accounts/all,n/a,Todos cuentas corrientes,Todo CONSEGUIR, http://localhost:8080/accounts/summary,n/a,Suma de todos los saldos,Todos CONSEGUIR, http://localhost:8080/credit,n/a,Coincidencia cuenta,administrador/cliente PONER, http://localhost:8080/credit,{saldo: Largo}, Crédito actual, admin/cliente CONSEGUIR, http://localhost:8080/credit/all,n/a,Todos créditos,Todos CONSEGUIR, http://localhost:8080/credit/summary,n/a,Suma 9. Generación del entorno de pruebas He creado un archivo en la carpeta raíz. Este archivo se llama "setupCertificates.sh". Echémosle un vistazo para tener una idea de lo que hace: bash #!/bin/bash mkdir -p your-finance-files cd your-finance-files || exit openssl genrsa -out baseKey.pem openssl pkcs8 -topk8 -inform PEM -in baseKey.pem -out privateKey.pem -nocrypt openssl rsa -in baseKey.pem -pubout -outform PEM -out publicKey.pem echo -e '\033[1;32mFirst test\033[0m' java -jar ../your-finance-jwt-generator/target/your-finance-jwt-generator.jar \ -p ../jwt-plain-tokens/jwt-token-admin.json \ -key ../your-finance-files/privateKey.pem >> token.jwt CERT_PUBLIC_KEY=$(cat ../your-finance-files/publicKey.pem) CERT_ISSUER="joaofilipesabinoesperancinha" echo -e "\e[96mGenerated public key: \e[0m $CERT_PUBLIC_KEY" echo -e "\e[96mIssued by: \e[0m $CERT_ISSUER" echo -e "\e[96mYour token is: \e[0m $(cat token.jwt)" cp ../your-financeje-banking/src/main/resources/config-template ../your-financeje-banking/src/main/resources/config_copy.yml CERT_CLEAN0=${CERT_PUBLIC_KEY//"/"/"\/"} CERT_CLEAN1=${CERT_CLEAN0//$'\r\n'/} CERT_CLEAN2=${CERT_CLEAN1//$'\n'/} CERT_CLEAN3=$(echo "$CERT_CLEAN2" | awk '{gsub("-----BEGIN PUBLIC KEY-----",""); print}') CERT_CLEAN4=$(echo "$CERT_CLEAN3" | awk '{gsub("-----END PUBLIC KEY-----",""); print}') CERT_CLEAN=${CERT_CLEAN4//$' '/} echo -e "\e[96mCertificate cleanup: \e[0m ${CERT_CLEAN/$'\n'/}" sed "s/{{ publicKey }}/$CERT_CLEAN/g" ../your-financeje-banking/src/main/resources/config_copy.yml > ../your-financeje-banking/src/main/resources/config_cert.yml sed "s/{{ issuer }}/$CERT_ISSUER/g" ../your-financeje-banking/src/main/resources/config_cert.yml > ../your-financeje-banking/src/main/resources/config.yml rm ../your-financeje-banking/src/main/resources/config_cert.yml rm ../your-financeje-banking/src/main/resources/config_copy.yml echo -e "\e[93mSecurity elements completely generated!\e[0m" echo -e "\e[93mGenerating tokens...\e[0m" TOKEN_FOLDER=jwt-tokens mkdir -p ${TOKEN_FOLDER} # CREATE_ACCOUNT_FILE=createAccount.sh CREATE_USER_FILE=createUser.sh SEND_MONEY_FILE=sendMoney.sh ASK_CREDIT_FILE=askCredit.sh TOKEN_NAME_VALUE=tokenNameValue.csv echo "#!/usr/bin/env bash" > ${CREATE_ACCOUNT_FILE} chmod +x ${CREATE_ACCOUNT_FILE} echo "#!/usr/bin/env bash" > ${CREATE_USER_FILE} chmod +x ${CREATE_USER_FILE} echo "#!/usr/bin/env bash" > ${SEND_MONEY_FILE} chmod +x ${SEND_MONEY_FILE} echo "#!/usr/bin/env bash" > ${ASK_CREDIT_FILE} chmod +x ${ASK_CREDIT_FILE} for item in ../jwt-plain-tokens/jwt-token*.json; do if [[ -f "$item" ]]; then filename=${item##*/} per_token=${filename/jwt-token-/} token_name=${per_token/.json/} cp "${item}" jwt-token.json java -jar ../your-finance-jwt-generator/target/your-finance-jwt-generator.jar \ -p jwt-token.json \ -key ../your-finance-files/privateKey.pem > token.jwt cp token.jwt ${TOKEN_FOLDER}/token-"${token_name}".jwt token=$(cat token.jwt) echo "# Create account: ""${token_name}" >> ${CREATE_ACCOUNT_FILE} echo "echo -e \"\e[93mCreating account \e[96m${token_name}\e[0m\"" >> ${CREATE_ACCOUNT_FILE} echo curl -i -H"'Authorization: Bearer ""${token}""'" http://localhost:8080/accounts -X POST >> ${CREATE_ACCOUNT_FILE} echo "echo -e \"\e[93m\n---\e[0m\"" >> ${CREATE_ACCOUNT_FILE} echo "# Create user: ""${token_name}" >> ${CREATE_USER_FILE} echo "echo -e \"\e[93mCreating user \e[96m${token_name}\e[0m\"" >> ${CREATE_USER_FILE} echo curl -i -H"'Authorization: Bearer ""${token}""'" http://localhost:8080/accounts/user -X POST >> ${CREATE_USER_FILE} echo "echo -e \"\e[93m\n---\e[0m\"" >> ${CREATE_USER_FILE} echo "# Send money to: "${token_name} >> ${SEND_MONEY_FILE} echo "echo -e \"\e[93mSending money to \e[96m${token_name}\e[0m\"" >> ${SEND_MONEY_FILE} echo curl -i -H"'Content-Type: application/json'" -H"'Authorization: Bearer ""${token}""'" http://localhost:8080/accounts -X PUT -d "'{ \"saldo\": "$((1 + RANDOM % 500))"}'" >> ${SEND_MONEY_FILE} echo "echo -e \"\e[93m\n---\e[0m\"" >> ${SEND_MONEY_FILE} echo "# Asking money credit to: "${token_name} >> ${ASK_CREDIT_FILE} echo "echo -e \"\e[93mAsking credit from \e[96m${token_name}\e[0m\"" >> ${ASK_CREDIT_FILE} echo curl -i -H"'Content-Type: application/json'" -H"'Authorization: Bearer ""${token}""'" http://localhost:8080/credit -X PUT -d "'{ \"saldo\": "$((1 + RANDOM % 500))"}'">> ${ASK_CREDIT_FILE} echo "echo -e \"\e[93m\n---\e[0m\"" >> ${ASK_CREDIT_FILE} echo "${token_name},${token}" >> ${TOKEN_NAME_VALUE} fi done Generación de ambiente Siga el archivo mientras explico lo que hace. Esto es importante para que entendamos exactamente lo que está haciendo. Primero creamos claves privadas y públicas en formato . Luego usamos la clave privada con nuestro ejecutable "your-finance-jwt-generator.jar". Este es nuestro jar ejecutable que permite la creación rápida de tokens. El emisor no se puede cambiar más adelante. Finalmente, crea un token. Veremos cómo leer este token más adelante. Este token contiene 3 reclamos de encabezado adicionales. Estos son "kid", "typ" y "alg". Sigue el siguiente formato: PEM { "kid": "jwt.key", "typ": "JWT", "alg": "RS256" } El encabezado del JWT Veamos estas afirmaciones más de cerca: "kid": funciona como una pista que indica qué tipo de algoritmo estamos usando. "typ" — Se utiliza para declarar los tipos de medios . Hay tres opciones: (token web JSON), (cifrado web JSON) y (algoritmos web JSON). Estos tipos no son relevantes para nuestro experimento. Solo veremos que nuestro token no está muy bien cifrado y que es muy fácil descifrarlo. También veremos que, aunque podemos descifrar tokens, no podemos manipularlos tan fácilmente para realizar otras acciones. IANA JWT JWE JWA "alg": así definimos el tipo de firma que queremos utilizar. La firma puede considerarse una operación criptográfica que garantizará que el token original no haya sido modificado y sea confiable. En nuestro caso, utilizamos RS256, también conocido como Firma RSA con SHA-256. Con nuestra clave pública, finalmente podemos usarla para cambiar nuestra plantilla. El nuevo archivo config.yml debería verse así: kumuluzee: name: your-financeje-banking version: 1.0.0 jwt-auth: public-key: FAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKE.FAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETO.FAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKEN issuer: joaofilipesabinoesperancinha healthy: true configuración.yml El segundo paso es crear cuatro archivos. Para cada token simple en el directorio " ", crearemos cuatro comandos. El primer comando es para crear usuarios que puedan hacer cosas de manera efectiva con sus cuentas. Estos son usuarios con perfiles " ", " " y " ". Ejecutemos el archivo " " para crearlos. El segundo comando creará el resto de los usuarios que aún no poseen ningún derecho. Este es el archivo "createUser.sh". Ejecutémoslo. Ahora veremos que finalmente se crearon todos los usuarios. Ahora veamos los detalles sobre las transacciones y observemos los dos comandos restantes. Uno para "cashin" y otro para solicitar más crédito. El primer archivo generado es el script bash "sendMoney.sh". Aquí podemos encontrar todas las solicitudes para " ". En este archivo encontrará una solicitud curl para enviar cantidades aleatorias de dinero a los usuarios, por usuario. Veamos el caso de administrador: jwt-plain-tokens admin client credit createAccount.sh cashin #!/usr/bin/env bash # Send money to: admin echo -e "\e[93mSending money to \e[96madmin\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer= FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 125}' echo -e "\e[93m\n---\e[0m" # Send money to: cindy echo -e "\e[93mSending money to \e[96mcindy\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 360}' echo -e "\e[93m\n---\e[0m" # Send money to: faustina echo -e "\e[93mSending money to \e[96mfaustina\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 50}' echo -e "\e[93m\n---\e[0m" # Send money to: jack echo -e "\e[93mSending money to \e[96mjack\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 205}' echo -e "\e[93m\n---\e[0m" # Send money to: jitska echo -e "\e[93mSending money to \e[96mjitska\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 332}' echo -e "\e[93m\n---\e[0m" # Send money to: judy echo -e "\e[93mSending money to \e[96mjudy\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 295}' echo -e "\e[93m\n---\e[0m" # Send money to: lucy echo -e "\e[93mSending money to \e[96mlucy\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 160}' echo -e "\e[93m\n---\e[0m" # Send money to: malory echo -e "\e[93mSending money to \e[96mmalory\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 413}' echo -e "\e[93m\n---\e[0m" # Send money to: mara echo -e "\e[93mSending money to \e[96mmara\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 464}' echo -e "\e[93m\n---\e[0m" # Send money to: namita echo -e "\e[93mSending money to \e[96mnamita\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 51}' echo -e "\e[93m\n---\e[0m" # Send money to: pietro echo -e "\e[93mSending money to \e[96mpietro\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 491}' echo -e "\e[93m\n---\e[0m" # Send money to: rachelle echo -e "\e[93mSending money to \e[96mrachelle\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 474}' echo -e "\e[93m\n---\e[0m" # Send money to: sandra echo -e "\e[93mSending money to \e[96msandra\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 417}' echo -e "\e[93m\n---\e[0m" # Send money to: shikka echo -e "\e[93mSending money to \e[96mshikka\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/accounts -X PUT -d '{ "saldo": 64}' echo -e "\e[93m\n---\e[0m" Extracto de sendMoney.sh Los mismos usuarios también tienen asignadas sus solicitudes de crédito: #!/usr/bin/env bash # Asking money credit to: admin echo -e "\e[93mAsking credit from \e[96madmin\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 137}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: cindy echo -e "\e[93mAsking credit from \e[96mcindy\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 117}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: faustina echo -e "\e[93mAsking credit from \e[96mfaustina\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 217}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: jack echo -e "\e[93mAsking credit from \e[96mjack\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 291}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: jitska echo -e "\e[93mAsking credit from \e[96mjitska\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 184}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: judy echo -e "\e[93mAsking credit from \e[96mjudy\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 388}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: lucy echo -e "\e[93mAsking credit from \e[96mlucy\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 219}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: malory echo -e "\e[93mAsking credit from \e[96mmalory\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 66}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: mara echo -e "\e[93mAsking credit from \e[96mmara\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 441}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: namita echo -e "\e[93mAsking credit from \e[96mnamita\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 358}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: pietro echo -e "\e[93mAsking credit from \e[96mpietro\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 432}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: rachelle echo -e "\e[93mAsking credit from \e[96mrachelle\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 485}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: sandra echo -e "\e[93mAsking credit from \e[96msandra\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 500}' echo -e "\e[93m\n---\e[0m" # Asking money credit to: shikka echo -e "\e[93mAsking credit from \e[96mshikka\e[0m" curl -i -H'Content-Type: application/json' -H'Authorization: Bearer FAKE.FAKE.FAKE' http://localhost:8080/credit -X PUT -d '{ "saldo": 89}' echo -e "\e[93m\n---\e[0m" Extracto de askCredit.sh Todos nuestros son parte de la Liga de . Básicamente, solo un grupo de personas que forman parte de este sistema bancario. En este contexto, están defendiendo el medio ambiente. No es realmente relevante para el artículo lo que hace este grupo de personas o en qué parte de la historia encajan, pero para el contexto, participan en acciones para defender el medio ambiente y frenar los efectos del . Algunos de nuestros pueden hacer todo, otros no pueden hacer nada y otros solo pueden "cobrar" o simplemente "pedir crédito". También tenga en cuenta que estoy ocultando información confidencial. Estos tokens normalmente no deberían compartirse ni ser visibles en una URL en particular. Sí, siempre están disponibles a través de la consola de desarrollador del navegador, pero de todos modos es para algunas solicitudes que se realizan. Este es un concepto conocido como "seguridad por oscuridad" aunque técnicamente no impide que el usuario se dé cuenta del token que está utilizando, sí funciona como elemento disuasorio. En ambos métodos, cuando hacemos un depósito o cuando pedimos crédito, note que por cada solicitud estamos enviando un número aleatorio entre 1 y 500. Ya casi estamos listos para iniciar nuestra aplicación, pero primero, profundicemos un poco más en la teoría. characters Nature cambio climático characters protect and 10. ¿Cómo se crea un token JWT Ahora que hemos generado nuestros tokens, veamos uno de ellos. Voy a mostrarte un token ofuscado y lo vamos a usar para entender esto. Aquí está nuestro token: . . Lo que es importante notar aquí es que nuestro token se divide en tres partes: FAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKE FAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETO FAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKENFAKETOKEN : este es un encabezado de configuración JSON codificado en Base64, tal como lo comentamos anteriormente. Encabezado : esta es una carga útil JSON codificada en Base64. Aquí es donde definimos nuestras reclamaciones reservadas y personalizadas. También podemos definir aquí reclamaciones privadas y públicas. Ambas caen dentro de las reclamaciones personalizadas. Como nota rápida, podemos hacer lo que queramos con ambas reclamaciones. Sin embargo, las reclamaciones públicas se denominan como las definidas en el Registro de tokens web JSON de la IANA. Es importante que nombremos nuestros tokens de una determinada manera para evitar colisiones con el registro. Las reclamaciones públicas también se pueden definir como opcionales estándar. Las reclamaciones privadas no siguen ningún estándar y depende de nosotros definirlas. Carga útil : aquí es donde podemos ser un poco creativos. La firma es una combinación cifrada del y la . Decidimos el algoritmo que queremos utilizar y este bit del token determinará básicamente si el mensaje que estamos enviando es confiable. Es exclusivo de esa combinación y nuestro servidor utilizará la "clave pública" que creamos para determinar si tenemos una coincidencia. Si recuerdas lo anterior, estamos usando en nuestro ejemplo. Firma Header Payload RS256 Antes de continuar, tenga en cuenta que tanto el como la se pueden en nuestro ejemplo. Simplemente "no podemos" manipular la carga útil o el encabezado y aún así hacer que sea confiable. La protección contra los posibles efectos de un token malicioso solo se puede proteger mediante el algoritmo que elijamos. Así que elija sabiamente. Si trabaja en una organización donde la información de alto secreto es una preocupación, como un banco, NO haga lo que estamos a punto de hacer. Esta es solo una forma de verificar en línea el contenido de los tokens que hemos generado localmente. Primero, vayamos a y completemos nuestro token . Use el token que acaba de generar: Header Payload decyphered https://jwt.io/ JWT Usando para verificar el contenido de nuestro token Examinemos lo que tenemos aquí. Este es nuestro token de administrador. Esa persona es "Admin" en nuestro ejemplo. Podemos ver que nuestros parámetros están todos disponibles. En nuestra lista vemos "sub", "aud", "upn", "access", "user_id", "iss", "name", "groups" y finalmente "jti". También tenemos algunas reclamaciones adicionales. Veámoslas: https://jwt.io/ " " — Esta es la fecha en la que se realizó la autenticación. Nuestro token se autenticó el domingo 17 de julio de 2022 a las 16:15:47 GMT+02:00 DST" " — Esta es la fecha en la que se creó el token. En nuestro caso, esto sucede simultáneamente con auth_time." " — Esta es la fecha de vencimiento del token. Caduca el domingo 17 de julio de 2022 a las 16:32:27 GMT+02:00 DST. No especificamos ninguna fecha de vencimiento en nuestro token. Esto significa que usa su valor predeterminado de ~15 minutos. auth_time iat exp JWT Ahora vamos a realizar algunas pruebas. 11. Ejecución de la aplicación El código está listo para usarse en . Si verificamos el código y lo abrimos con Intellij, debemos tener en cuenta que no podemos ejecutar esta aplicación como una aplicación Spring Boot. No hay ningún "psvm" para ejecutarlo. En cambio, podemos ejecutar el jar generado directamente y asegurarnos de hacer un "mvn build" justo antes. Así es como lo estoy usando en este momento: GitHub [ ] "Configuración del entorno para ejecutar la aplicación") https://github.com/jesperancinha/your-finance-je Ahora ejecutemos nuevamente el script " ". No sé cuánto tiempo te tomó llegar hasta aquí, pero es muy probable que a esta altura ya hayan pasado los 15 minutos. Por las dudas, ejecútalos nuevamente. ¡Iniciemos nuestra aplicación! Podemos iniciarla de esta manera: setupCertificates.sh mvn clean install java -jar your-financeje-banking/target/your-financeje-banking.jar O podemos simplemente ejecutarlo a través de nuestra configuración lista para usar. Revise el repositorio y el Makefile de antemano si desea comprender todo lo que hace: make dcup-full-action Este script ejecutará 2 servicios. Uno en el puerto y el otro en el puerto En el puerto ejecutaremos una versión de este software que ejecuta nuestro propio código para generar tokens . En el puerto 8081, ejecutaremos una versión que utiliza el generador creado por . Sin embargo, este artículo se centrará en el servicio que se ejecuta en el puerto Si lo desea, también puede ejecutar con: 8080 8081 8080 JWT jwtknizr Adam Bien 8080 cypress make cypress-open Esto la consola y podrás ejecutar las pruebas con el navegador que elijas. Sin embargo, las opciones del navegador aún son limitadas en esta etapa. La mayoría de las solicitudes serán solicitudes de línea de comandos proporcionadas por . Por ahora, no analizaremos " ". Ve a tu navegador y dirígete a esta ubicación: open cypress cypress cypress http://localhost:8080/cuentas/todas Deberíamos obtener un resultado como este: Como podemos ver, " ", " " y " " no tienen crédito ni dinero. Esto se debe a que solo se les ha otorgado el grupo de usuarios. Observe también que no se le ha otorgado crédito. " " es nuestro único cliente que no tiene el crédito de grupo. Si observamos los registros, podemos ver que las operaciones exitosas tienen este formato: Malory Jack Fallout Jitska Shikka Shikka Sending money to admin HTTP/1.1 200 OK Date: Sun, 17 Jul 2022 15:01:13 GMT X-Powered-By: KumuluzEE/4.1.0 Content-Type: application/json Content-Length: 32 Server: Jetty(10.0.9) {"balance":212,"client":"Admin"} Un 200 nos permite saber que la operación se realizó con éxito. En el caso de "Malory", "Jack Fallout" y "Jitska", ambas operaciones fallan y luego recibiremos este tipo de mensaje: Sending money to jitska HTTP/1.1 403 Forbidden X-Powered-By: KumuluzEE/4.1.0 Content-Length: 0 Server: Jetty(10.0.9) Un 403 nos permite saber que nuestro token ha sido validado y es confiable. Sin embargo, el usuario no puede realizar esa operación. En otras palabras, no tiene acceso al método designado. JWT Vamos a modificar un poco nuestros tokens. Si cambiamos algunos de los tokens del archivo sendMoney.sh, deberíamos obtener esto: Sending money to admin HTTP/1.1 401 Unauthorized X-Powered-By: KumuluzEE/4.1.0 WWW-Authenticate: Bearer realm="MP-JWT" Content-Length: 0 Server: Jetty(10.0.9) Entrar al modo de pantalla completa Salir del modo de pantalla completa Este significa que nuestro token no fue validado. Significa que la clave pública que el servidor utiliza para verificar si nuestro token es confiable no encontró ninguna coincidencia. Si la clave pública no puede evaluar y validar la firma del token JWT, lo rechazará. 401 A modo de resumen, el encabezado y el "Payload" no están cifrados. Solo están "codificados" en base 64. Esto significa que la "Decodificación" nos permite siempre echar un vistazo al interior de lo que realmente es el payload. Si buscamos proteger nuestro payload de escuchas no autorizadas, no deberíamos utilizar el "Payload" del token para nada más que para seleccionar parámetros de identificación. El problema radica realmente cuando alguien consigue el token , por ejemplo, cuando el túnel TLS se ha visto comprometido y alguien puede leer el contenido de los mensajes intercambiados. Cuando eso sucede, todavía hay otra protección. Y esta es la firma. El único capaz de validar un mensaje entrante es el servidor que contiene la clave pública. Esta clave pública, aunque pública, solo permite validar el mensaje entrante ejecutándose contra la firma y el "Header + Payload". JWT 12. Conclusión Hemos llegado al final de nuestra sesión. Gracias por seguirla. Podemos ver cómo los tokens son compactos y mucho menos detallados que su contraparte XML, los tokens . Hemos visto lo fácil que es crear y usar tokens para obtener ciertas autorizaciones necesarias para ciertos métodos y cómo llegamos allí a través de un token firmado. Sin embargo, creo que es muy importante tener una idea de cómo funciona . Con suerte, con esto, te he dado una buena introducción a cómo funcionan los tokens . Para tener una mejor idea de cómo funciona todo esto, te aconsejo que juegues con las pruebas implementadas. Esta es una excelente manera de ver cómo se realizan las solicitudes y qué estamos probando y qué se espera. Entonces también tendrás una mejor idea de por qué algunos usuarios realizan ciertas operaciones y otros no. He colocado todo el código fuente de esta aplicación en Espero que hayas disfrutado de este artículo tanto como yo disfruté escribiéndolo. ¡Gracias por leer! JWT SAML JWT JWT cypress GitHub. 13. Referencias API de autenticación JWT de Eclipse MicroProfile Token web JSON de MicroProfile (JWT) Reclamaciones de tokens web JSON Blog de Kumuluz kumuluzEE Seguridad de la API REST Seguridad de API RESTful Tutorial: Crear y verificar JWT en Java oktadeveloper/ejemplo-de-okta-java-jwt Interfaz de línea de comandos Spring Boot API de seguridad Java EE (JSR 375/Soteria) con tokens JWT payara/Payara-Ejemplos Protección de puntos finales JAX-RS con JWT Proteja su aplicación con Eclipse MicroProfile JWT Auth Dispensador JWT Expiración de token configurable 4.0.0 Microservicios con KumuluzEE MicroProfile 1.2 Autenticación JWT: cuándo y cómo utilizarla La guía definitiva para manejar JWT en clientes frontend (GraphQL) Token web JSON de la IANA (JWT) Chef cibernético Uso de la seguridad de KumuluzEE Una introducción sencilla a los tokens web JSON (JWT): qué son y qué no son Grupo de trabajo de ingeniería de Internet RFC7519