Lab003 - Protección de Ruta mediante tokens.

En este laboratorio, se procede a crear una ruta, que consumirá un servicio de tipo Mockup para simular una respuesta del servicio de Xposer.

Esto nos ayudara a entender como funciona el mecanismo de autorización por tokens, y ademas nos permitirá entender como se pueden crear servicios simulados mediante la herramienta de Mocking del Xposer Server.

1. Personalización del helm chart.

A continuación realizaremos la actualización de valores, mediante el uso del archivo de values personalizado.

Dentro de la carpeta de los laboratorios, podemos observar un archivo llamado valuescust.yaml, el cual contiene una configuración personalizada para utilizar el servidor de OAuth2 para agregar la validación por token a los servicios, mediante el realm que configuramos en el laboratorio 1 de esta sección. También pueden descargar el paquete del laboratorio desde lab003-pack, donde encontraras el archivo de values para su edición.

1.1. Modificar el valor del secret del archivo, con el valor que se obtuvo al configurar el cliente en el realm de Keycloak como se muestra en la imagen:

1.2. Desde la linea de comandos, entrar a la carpeta del laboratorio, donde se encuentra el chart, y ejecutar el siguiente comando, para actualizar y aplicar la configuración al pod de xposer que tenemos desplegado actualmente.

• client: consumidor_autorizado_oauth
• secret: EL-SECRET-DEL-KEYCLOAK-CLIENT
• serverUrl: http://kubernetes.docker.internal:8080/realms/labs

helm install xposer-demo xposer-server-latest.tgz -f valuescust.yaml

En caso de usar un servicio de Keycloak externo, se debe cambiar la dirección del host, para quedar acorde a la ubicación necesaria.

Con este ultimo comando, actualizaremos la configuración de nuestro pod, y aplicaremos la visibilidad del keycloak para los fines de autorización que necesitamos.

1.3. Para verificar que si se aplicaron los cambios, ejecutar el siguiente comando:

helm get values xposer-demo

con lo que obtendremos el listado de variables aplicadas. Debemos buscar la sección de authorizationServer, y debemos buscar que los valores de nuestra configuración se aplicaron correctamente:

2. Creación de Mockup Response

2.1 Abrir el swagger-ui incluido con el Xposer Server entrando a la siguiente dirección:

https://localhost:8443/xposer-admin/v1/docs

2.2. Presionar el botón Authorize de la interfaz del swagger-ui para introducir el API Key:

2.3. Introducir el Apikey en el dialogo y presionar Authorize una vez ofuscada la llave, presionar el botón Close:

2.4. Buscar en la sección de Xposer Admin MOCKUP, el método POST, y presionar el botón :

2.5. En la sección de body, colocar el siguiente payload:

{
  "id": "mockup::testingaccount::001",
  "name": "POST::/accounts valida nombre",
  "description": "POST::/accounts validación del nombre, si llega ADAN RODRIGUEZ, manda un mensaje de aprobado",
  "cases": [
    {
      "name": "evaluación de nombre especifico en campo \"Name\" == \"ADAN RODRIGUEZ\" dentro del body",
      "method": "post",
      "rules": [
        {
          "messagePart": "body",
          "property": "FirstName",
          "operator": "starts with",
          "value": "ADAN"
        },
        {
          "messagePart": "body",
          "property": "Edad",
          "operator": ">=",
          "value": "40"
        }
      ],
      "response": {
        "timeToResponse": 1500,
        "status": 200,
        "body": {
          "message": "Aprobado DESDE LA REGLA DE ADAN con mas de 40 años"
        },
        "headers": {
          "Content-Type": "application/json; charset=utf-8",
          "date": "2025-03-17 18:00:02"
        }
      }
    },
    {
      "name": "evaluación de nombre especifico en campo \"Name\" == \"MCKEYLO\" y \"LastName\" contains \"GATO\" dentro del body",
      "method": "post",
      "rules": [
        {
          "messagePart": "body",
          "property": "FirstName",
          "operator": "==",
          "value": "MCKEYLO"
        },
        {
          "messagePart": "body",
          "property": "LastName",
          "operator": "contains",
          "value": "GATO"
        }
      ],
      "response": {
        "status": 200,
        "body": {
          "message": "Transacción en espera para el usuario MCKEYLO GATO",
          "Status": "WTNG",
          "ContactInfo": "https://localhost:8443/accounts/12312312313"
        },
        "headers": {
          "Content-Type": "application/json; charset=utf-8",
          "date": "Tue, 06 Apr 2021 13:19:28 GMT"
        }
      }
    },
    {
      "name": "Default, Respuesta Exitosa",
      "method": "post",
      "rules": [],
      "response": {
        "status": 200,
        "body": {
          "message": "Caso por defecto de POST"
        },
        "headers": {
          "Content-Type": "application/json; charset=utf-8",
          "date": "Tue, 06 Apr 2021 13:19:28 GMT"
        }
      }
    },
    {
      "name": "Consulta de numero de registro por GET",
      "method": "get",
      "rules": [
        {
          "messagePart": "query",
          "property": "Queue",
          "operator": "==",
          "value": "12312312313"
        }
      ],
      "response": {
        "status": 200,
        "body": {
          "message": "Transacción APROBADA para el usuario MCKEYLO GATO",
          "Status": "APRB",
          "ContactInfo": "https://localhost:8443/accounts/12312312313"
        },
        "headers": {
          "Content-Type": "application/json; charset=utf-8",
          "date": "Tue, 06 Apr 2021 13:19:28 GMT"
        }
      }
    },
    {
      "name": "Default, Respuesta Exitosa",
      "method": "get",
      "rules": [],
      "response": {
        "status": 200,
        "body": {
          "message": "Caso por defecto de GET"
        },
        "headers": {
          "Content-Type": "application/json; charset=utf-8",
          "date": "Tue, 06 Apr 2021 13:19:28 GMT"
        }
      }
    }
  ]
}

2.6. Presionar el botón de y revisar que la ejecución se haya realizado correctamente.

2.7. Verificar que se ha creado el servidor correctamente, consumiendo el servicio de GET Server By ID. Buscar el método GET con la ruta /xposer-admin/v1/servers/{id}:

2.8. Presionar el botón y en el campo de id, colocar el valor server::oauth2::001

2.9. Presionar el botón de como se muestra en la imagen y como podemos observar, se retorna el server que acabamos de crear:

3. Creación de la ruta para usar el mockup

3.1. Abrir el swagger-ui incluido con el Xposer Server entrando a la siguiente dirección:

https://localhost:8443/xposer-admin/v1/docs

3.2. Presionar el botón Authorize de la interfaz del swagger-ui para introducir el API Key:

3.3. Introducir el Apikey en el dialogo y presionar Authorize una vez ofuscada la llave, presionar el botón Close:

3.4. Buscar en la sección de Xposer Admin ROUTE, el método POST, y presionar el botón :

3.5. En la sección de body, colocar el siguiente payload:

{
  "url": "/labs/core/accounts",
  "prefix": "/labs/core",
  "name": "solicitud de cuentas",
  "tags": ["pruebas", "mocking"],
  "enabled": true,
  "methods": {
    "GET": {
      "schema": {
        "summary": "Obtener objetos de api externa",
        "tags": ["Lab003"],
        "produces": ["application/json"],
        "description": "Método GET de pruebas",
        "queryParams": {
          "type": "object",
          "properties": {
            "Queue": {
              "type": "string"
            }
          }
        }
      }
    },
    "PUT": {},
    "HEAD": {},
    "POST": {
      "schema": {
        "summary": "Obtener objetos de api externa",
        "tags": ["Lab003"],
        "consumes": ["application/json"],
        "produces": ["application/json"],
        "description": "Método POST de pruebas",
        "body": {
          "type": "object",
          "properties": {
            "Id": {
              "type": "string"
            },
            "FirstName": {
              "type": "string"
            },
            "LastName": {
              "type": "string"
            },
            "Address": {
              "type": "string"
            },
            "Bank": {
              "type": "string"
            },
            "Edad": {
              "type": "string"
            }
          }
        },
        "response": {
          "200": {
            "type": "object",
            "properties": {
              "message": {
                "type": "string"
              },
              "Status": {
                "type": "string"
              },
              "ContactInfo": {
                "type": "string"
              }
            },
            "description": "Respuesta correcta que se obtendrá desde la llamada al usuario"
          },
          "500": {
            "description": "Mensaje de error desde el servidor",
            "type": "object",
            "properties": {
              "error": {
                "type": "string"
              },
              "code": {
                "type": "string"
              }
            }
          }
        }
      }
    },
    "PATCH": {},
    "DELETE": {}
  },
  "metadata": {},
  "description": "Esta es una ruta de pruebas para mocking con token",
  "id": "route::mockuptest::001"
}

3.6. Presionar el botón de y revisar que la ejecución se haya realizado correctamente.

3.7. Verificar que se ha creado la ruta correctamente, consumiendo el servicio de GET Route By ID. Buscar el método GET con la ruta /xposer-admin/v1/routes/{id}:

3.8. Presionar el botón y en el campo de id, colocar el valor route::oauth2::001

3.9. Presionar el botón de como se muestra en la imagen y como podemos observar, se retorna el server que acabamos de crear:

4. Creación de regla que solicita token

4.1. Abrir el swagger-ui incluido con el Xposer Server entrando a la siguiente dirección:

https://localhost:8443/xposer-admin/v1/docs

4.2. Presionar el botón Authorize de la interfaz del swagger-ui para introducir el API Key:

4.3. Introducir el Apikey en el dialogo y presionar Authorize una vez ofuscada la llave, presionar el botón Close:

4.4. Buscar en la sección de Xposer Admin RULE, el método POST, y presionar el botón :

4.5. En la sección de body, colocar el siguiente payload:

{
  "name": "rule::security::token",
  "description": "Regla de Servidor de consumo de OAuth2 API",
  "endpointType": "mockup",
  "mockup": "mockup::testingaccount::001",
  "groups": [],
  "consumers": [],
  "authorizationType": "token",
  "route": "route::mockuptest::001",
  "id": "rule::mockwsecuritytoken::001"
}

4.6. Presionar el botón de y revisar que la ejecución se haya realizado correctamente.

4.7. Verificar que se ha creado la ruta correctamente, consumiendo el servicio de GET Rule By ID. Buscar el método GET con la ruta /xposer-admin/v1/rules/{id}:

4.8. Presionar el botón y en el campo de id, colocar el valor rule::securitytoken::001

4.9. Presionar el botón de como se muestra en la imagen y como podemos observar, se retorna el server que acabamos de crear:

5. Prueba de aseguramiento del servicio.

5.1. Calcular un token, utilizando los siguientes parámetros en el endpoint de /labs/oauth/v2/{*}

• client_id: consumidor_autorizado_oauth
• client_secret: [[EL-SECRET-QUE-GENERARON]]
• grant_type: password
• scope: openid email
• username: userdemo
• password: Pass1234
• *: token

5.2. Copiar el token que esta dentro del body, en la variable de access_token.

5.3. Dentro del servicio de GET /labs/core/accounts, presionar el botón de try it out y en el campo del header de authorization, colocar lo siguiente:

• authorization: Bearer [[PEGAR EL TOKEN DEL PASO 5.2]]

5.4. Ejecutar presionando el botón de execute button, y obtendremos la siguiente respuesta:

5.5. Ejecutar en el método POST de /labs/core/accounts, utilizando el siguiente body:

{
  "Id": "098A09S8908D",
  "FirstName": "ADAN",
  "LastName": "RODRIGUEZ GARCIA",
  "Address": "CRA 56 #16145",
  "Bank": "BANCOLOMBIA",
  "Edad": "40"
}

5.6. Obtendremos la siguiente respuesta:

Nota. Debido a que los mockups tienen la capacidad de detectar valores parametrizados desde las reglas de su configuración, es posible obtener respuestas ligadas a las reglas, que simulan la interacción con un servidor real. Ademas, podemos colocar retrasos en la respuesta, para simular un servidor muy cargado, con lo que es posible simular situaciones de trafico intenso y verificar como es que van a reaccionar los sistemas que consumirán esos servicios, en dichos entornos.