Header Ads Widget

Ticker

6/recent/ticker-posts

Intercambio de datos en IoT

 

Uso compartido de datos en el IOT nordic-apis-doerrfeld-01

Constantemente ponemos en riesgo nuestros datos personales. La seguridad de la API se refiere a sky rocket a medida que aumenta constantemente el deseo del usuario de pasar el acceso a otros. Con el auge de los dispositivos de Internet de las cosas (IoT) , la capacidad de compartir el uso de dispositivos físicos conectados hace que la gestión del acceso sea una preocupación cada vez mayor.

Ya sea que compartan un documento colaborativo o la ubicación del automóvil, los usuarios transmiten datos de forma rutinaria y acceden a miembros de la familia, amigos, compañeros de trabajo, clientes o usuarios de aplicaciones, la mayoría de las veces mediante API. Pero, ¿cómo se pueden lograr estos intercambios de datos de una manera segura y eficiente utilizando los estándares existentes?

En una sesión con API nórdicas, Jacob Ideskog demuestra cómo esto es posible usando OAuth habilitado con OpenID Connect . En este artículo, examinaremos cómo implementar el intercambio seguro de datos para un nuevo dispositivo de IoT con candado para bicicletas , un ejemplo del mundo real de la introducción de un enfoque de mejores prácticas para la gestión de identidades en el ámbito de IoT.

Una nueva economía basada en la propiedad compartida y delegada

Además de alterar drásticamente la forma en que se realizan los negocios empresariales , las API están impulsando un cambio importante en los consumidores. Con el amanecer de la ubicuidad de los teléfonos inteligentes, los sensores y los dispositivos de IoT, han surgido rápidamente nuevos servicios de suscripción y empresas en torno al concepto de compartir el acceso a la propiedad personal .

Los propietarios de viviendas se están convirtiendo en propietarios de negocios a tiempo parcial con Airbnb , los ciudadanos con automóvil y tiempo libre obtienen ingresos adicionales conduciendo con Uber o Lyft . Las aplicaciones permiten a los usuarios compartir su oficina o espacio de trabajo, o usar autos comunales con Car2Go o ZipCar . En pocas palabras, el modelo Anything-as-a-Service (XaaS) es la ola del futuro .

Compartir la propiedad conlleva riesgos inherentes. Riesgos por parte de la parte que usa la propiedad y riesgos dentro del proceso de intercambio de datos. Entonces, ¿cómo evita una aplicación los riesgos de seguridad para garantizar que la propiedad se delegue correctamente? ¿Qué tecnologías y flujos de trabajo específicos ofrecen la mejor ruta para la gestión de acceso?

Skylock - Ejemplo de dispositivo de IoT

Tomemos a Skylock , una iniciativa de financiación colectiva para desarrollar un candado de bicicleta inteligente conectado con energía solar. Está repleto de funciones: una función antirrobo incorporada, un acelerómetro para analizar el movimiento y alertas automáticas de respuesta de seguridad. Skylock también permite la entrada sin llave y tiene la capacidad de compartir el acceso de forma remota con amigos usando la aplicación Skylock.

Es probable que la cerradura y la aplicación Skylock utilicen muchas API propias o de terceros para impulsar la ubicación, el mapeo, la respuesta de seguridad y más. Pero de todo el software que impulsa los escenarios presentados en su video promocional, la parte más compleja de un sistema como este puede ser el  acceso compartido que ocurre entre los usuarios.

Relacionado: Sumérjase en OAuth y OpenID Connect

¿Cómo funciona esto?

En un escenario como este, el usuario normalmente autoriza a la aplicación a acceder a la API. Llamaremos al chico Adam ya su novia Bianca. Digamos que Adam quiere compartir el acceso para que la aplicación de Bianca pueda acceder a la cuenta de Adam a través de la API. En este caso, compartir es delegar el uso.

uso-paso-en-acceso-intercambio de datos-iot-nordic-apis

¿No se puede usar OAuth para eso? No exactamente. OAuth se trata realmente de que el usuario delegue el acceso del usuario a la aplicación, es decir, la delegación de usuario a aplicación . Normalmente, en OAuth, la aplicación solicita acceso a una API y el usuario concede ese acceso. Luego, OAuth le da a la aplicación un token.

Más bien, esta nueva situación es más complicada. Dado que Adam quiere permitir que Bianca acceda a su cuenta, delegando la responsabilidad del usuario a Bianca, estamos tratando con la delegación de usuario a usuario . Hay dos maneras de hacer esto. O configura una base de datos o una tabla alrededor de la API para que Bianca obtenga acceso para recuperar datos, o el sistema le otorga a Bianca un token de acceso que pertenece a otra persona , es decir, Adam, otorgándole poderes equivalentes a Bianca.

Relacionado: Cómo controlar la identidad del usuario dentro de los microservicios

Opción # 1: Tablas de acceso

tablas de acceso

En el primer enfoque, usamos la API para recuperar datos de una tabla de acceso. El flujo es el siguiente:

  1. La aplicación de Bianca se pone en contacto con el servidor OAuth.
  2. El servidor OAuth reta a Bianca a ingresar sus credenciales (nombre de usuario / contraseña).
  3. El servidor OAuth acepta y emite el token de acceso de su propia cuenta.
  4. Bianca usa este token para enviar una solicitud a la API. En este punto, debe indicar de alguna manera a la API que pretende realizar en otros recursos; debe distinguir entre usuarios para acceder a la cuenta de Adam. (Este paso es desafortunado, ya que requiere una gestión de identidad enredada dentro de la propia API).
  5. La API habla con la base de datos para verificar que el acceso sea real y valida el acceso.
  6. Luego, la API responde con los datos de Adam a la aplicación.

Mirándolo, este es arquitectónicamente el flujo más simple, pero sin embargo, la implementación es la más difícil. Esto es especialmente difícil cuando se crean microservicios que se completan con muchas API. Es posible que estemos construyendo muchas API pequeñas que necesitan implementar y contactar servicios para permitir repetidamente el acceso a los datos.

Estos microservicios pueden estar haciendo muchas cosas distintas. Es posible que sus protocolos de comunicación no sean similares, y además, si tiene información de usuario enredada en esos datos, tendrá que programar mucho, mucho que dejar a los desarrolladores para que lo manejen.

Opción # 2: Tokens delegados: OpenID Connect

intercambio de datos en iot-nordic-apis-tokens-delegados-call-api

OpenID Connect es un protocolo complementario de OAuth. Habilitar un servidor OAuth con OpenID Connect agrega una capa de identidad en la parte superior. Ahora nuestra API no solo sabe qué acceso se está dando, sino que también sabe quién está accediendo a esos datos.

Esto se procesa utilizando el punto final de OpenID Connect Userinfo, un punto final simple al que se puede llamar usando un verbo GET con un token de autorización. El punto final Userinfo responde con un documento JSON, que contiene información básica del usuario como nombre, teléfono, correo electrónico, etc. Con un token de usuario puede recuperar Userinfo para acceder a la información del usuario, un proceso bastante simple.

Podemos tomar esta respuesta y cambiar el significado agregando tokens de acceso en esta respuesta. Así es como enumeramos las delegaciones. Usaremos el punto final de Userinfo para volver a emitir tokens o degradar tokens. En el caso de nuestro candado para bicicletas, Bianca recibe un token de acceso para el propietario de los recursos, Adam, que contiene datos significativos y alcances para especificar quién es el autenticador, en nuestro caso, Bianca.

El nuevo flujo es así:

  1. La aplicación solicita acceso desde el servidor OAuth habilitado para OpenID Connect.
  2. El servidor reta a Bianca a ingresar sus credenciales (nombre de usuario / contraseña).
  3. Bianca recibe su propio token de acceso.
  4. Luego, Bianca llama al punto final de Userinfo con su token de acceso.
  5. El servidor habilitado para OpenID Connect toma este token de acceso.
  6. El servidor responde con un segundo token (el token de acceso de Adam). Esto vino del documento JSON.
  7. BIanca ahora tiene 2 fichas. Cuando Bianca necesita operar con datos de Adams, usa el token que obtuvo del punto final UserInfo. Si necesita hacer algo en su cuenta, usa el token de acceso inicial que obtuvo.
  8. La API recibirá en todo momento un token y podrá verlo para ver en qué usuario debe operar.

Un ejemplo de respuesta JSON de Userinfo puede verse así:

{
    "sub": 'bianca",
    "name": "Bianca Doe",
    ...
    "example:delegations" : {
    "adam" : {
        "access_token" : "te2eg9a-2daca99-ad9caf-nacnkh3h",
        "expires_in" : 300,
        "scope" : ["stuf", "otherstuff"]
         }
    }
}

Compartir el acceso entre microservicios

Como aprendimos en Cómo controlar la identidad del usuario dentro de los microservicios , el manejo de los datos del usuario dentro de los microservicios es un proceso muy similar. Enviamos un token de acceso y termina ese token. Si queremos acceder a la cuenta de otra persona, simplemente usamos un token diferente. Para regular este proceso podemos colocar una puerta de entrada en esta intersección. Realmente no importa: los tokens de acceso regular o delegado se actúan de la misma manera. Nuestro caso de acceso normal no tendrá que ser alterado, lo que significa que no es necesario modificar el backend.

Ideskog admite un posible inconveniente es que si una aplicación debe mantener una multitud de tokens. Al delegar toneladas de tokens con muchas personas involucradas en un solo flujo, puede encontrarse con una hinchazón del sistema.

Para más información, vea a Jacob Ideskog presentando sobre este tema en un evento de API nórdicas

Revisar:

Gracias a enfoques inteligentes para delegar el acceso, Adam puede compartir de forma remota el candado de su bicicleta con Bianca de manera segura y confiable. Estas metodologías también se transfieren a la gestión de identidades dentro de aplicaciones web, API o situaciones de IoT en las que los usuarios deben otorgar funcionalidad a otros usuarios . Como revisión, para lograr esto hay dos alternativas:

Enfoque de búsqueda de tabla de acceso : la identidad está integrada en la API y se almacena una base de datos, la búsqueda de acceso se almacena.

  • Fácil de implementar desde una perspectiva ADMIN
  • Cada API necesita saber sobre la delegación
  • Cada API necesita resolver los derechos de acceso
  • Con los microservicios, esto se vuelve MUCHO más pesado.

Enfoque de tokens delegados : la identidad se elimina de la API, se lanza al servidor OpenID Connect y al servidor OAuth.

  • Fácil de implementar en el lado de la API
  • Las API funcionan igual para el acceso regular y el acceso delegado
  • La aplicación debe mantener varios tokens

Es importante recordar que OAuth es delegación de usuario a aplicación , no delegación de usuario a usuario. Sin embargo, si lanzamos OpenId Connect y usamos el punto final de Userinfo, podemos agregar la delegación de usuario a usuario y completar los estándares de calidad de acceso compartido.

Divulgaciones:

  • Skylock se usa solo como un ejemplo ilustrativo, y no tenemos ninguna afiliación con la compañía y no sabemos si usaron esta técnica específica en su sistema.
  • Gráficos propiedad de Twobo Technologies.
  • Jacob Ideskog es un especialista en identidad de Twobo Technologies, patrocinador de las API nórdicas.

Publicar un comentario

0 Comentarios