-
Notifications
You must be signed in to change notification settings - Fork 0
Sprint 3
-
Como administrador cuando un empleado realice una transacción, dado que el sistema opera normalmente yo quiero que la información de la transacción sea consistente con la operación realizada. Y debe suceder el 100% de las veces
-
Como administrador cuando un empleado haga consultas de las transacciones del negocio, dado que el sistema opera normalmente yo quiero que no tengan acceso a la información, solo que puedan crear las transacciones. Y debe suceder el 100% de las veces
S3 Mi Favorito (ASRs con tag "sprint3")
Para resolver el problema de Integridad, se implementaron nuevos componentes claves en la arquitectura, los cuales son: (1) KeyManager y (2) TrustManager, los cuales se encargan de (1) generar las llaves y (2) verificar la integridad de las transacciones enviadas respectivamente.
Para resolver el problema de confidencialidad, se mantuvo el componente de Autenticación externa, que en nuestro caso fue Auth0 y, mediante permisos de autenticación se permite o no crear una transacción.
A continuación se analizarán las pruebas realizadas para corroborar el funcionamiento de la implementación de nuestra arquitectura para solucionar cada uno de los ASR's:
Se implementó un servidor que actúa garantizando la integridad de la información de la transacción realizada y un componente que genera las llaves y certificado que le va a dar la llave pública de la transacción a este servidor para que corrobore la integridad del mismo.
En la implementación realizada se obtuvo que el servidor identifica con éxito cuando la integridad de la transacción se ha visto alterada o no. De esta manera, se garantiza que la transacción sea consistente con la operación realizada.
Aquí se ve el envío de la transacción con su firma
Encontramos así:
Error en verificación Integridad
Se implementó la integración del servicio externo de Auth0 para que pueda validar el rol de cada persona que intente realizar acciones en las Transacciones. Estos roles fueron definidos como los scopes de readProduct, readProducts, writeProducts y deleteProducts. En donde cada uno de ellos cuenta con los permisos de: leer un producto, leer varios productos, registrar y persistir los productos y eliminar los productos respectivamente. A continuación, se muestran screenshots de cada uno de los roles y sus acciones integrado en la aplicación, y la implementación de un SuperUsuario el cual puede realizar todas las acciones mencionadas anteriormente.