tv.um.es

La última, la última parte que vamos a ver en la parte de los modelos auxiliares, otros módulos. Qué nos queda por ver? Por un lado, esta año la parte de la autenticación y la autorización. Vamos a tener 2, dos tipos de usuarios o dos fuentes de usuarios. Por un lado, vamos a poder tener usuarios locales del propio sistema, que se puedan, incluso autor registrar el sistema es que entienden, pretenden acceder a poder verlo y quieran consultar información. Ahí nos menos tengamos dados de alta ningún otro lugar. Por tanto, van a poder tener esa esa opción de otro registro, e incluso no es nuestro nuestra aplicación y luego por otro lado, estaría la parte de decir. Bueno, no sé si será conocéis esta. Esta parte si eres, es el servicio de identidad de Bale, el cual ofrece un servicio de autenticación federado para los servicios que proveen las entidades asociadas tanto a nivel nacional como internacional, como características que nos da Sir. Por un lado, sería la autenticación, se realiza la plataforma local de cada década, institución ofreciendo la forma de autenticación, a la que está acostumbrado cada usuario a ofrecer una mayor seguridad, ya que las credenciales no salen del entorno local, de la propia institución del usuario, y que cada institución aplica los mecanismos de control que estime que estime convenientes que quiere decir todo. Todo esto al final, nosotros cuando observamos a la aplicación nos va a llevar así y, es decir, vamos a poder ir a nuestra institución. Por ejemplo, si somos usuarios de la Universidad de Murcia, Bale nos va a llegar al single de la Universidad de Murcia. Me voy a poder autentificar en el single Saigón de la Universidad de Murcia con mi usuario, del dominio de la Universidad de Murcia, pero si, por ejemplo, soy usuario de la Universidad de Oviedo, por ejemplo, podría irme. Hablan a los usuarios de la inglesa y no de la Universidad de Oviedo, el hogar? Me con mi con mis datos de ese dominio y acceder igualmente al sistema y así como otros, como otras universidades que pueda, que pueda existir un poco lo que lo que nos viene a decir todo esto. Esto nos da esa, esa ventaja de que cada usuario va a poder dedicarse con sus credenciales, que tenga el dominio no va a tener unas específicas para para esta, para esta solución, sino que va a poder trabajar con las que tenga ya de su organización, por así decirlo y y poco lo que comentaba, esa mayor seguridad. Al no salirse de ese ámbito, no del ámbito de su desorganización, iba a ser cada organización la que decida los los atributos que es necesario compartir o que nos va a enviar hacia hacia Sir. De acuerdo dentro de dentro de este sistema. Hay en cuanto a los organismos que están adheridos a ello. Principalmente estamos hablando de las universidades españolas, aunque si bien es cierto que hay algún otro organismo, bueno podéis entrar en la página de rendir y si hay un poco todos los que los que hay una y otra serie de organismos públicos que también, que también estarían adheridos, vale? Entonces, como con cualquiera de ellos podríamos podríamos llegar a entrar en este este sistema? Como decía, nuestro sistema está basado en la federación de identidad, pero qué es la Federación de Entidades? No es la gran pregunta en la definición más mágica. Podríamos decir que es el esfuerzo entre dos o más entidades para conseguir que sea la entero la entidad sea interoperable entre ellas, no que podamos trabajar con la identidad de otra entidad. En nuestra aplicación, ejemplo el caso que comentaba antes, en nuestra aplicación de la Universidad de Murcia puedo acceder con la identidad de alguien de la Universidad de Oviedo, por ejemplo, un poco vamos a conseguirlo de esta de esta manera, no? Entonces ampliando hasta esta definición. Este punto de vista digamos que sienta las bases de una relación entre varias entidades digitales, habitualmente a entidades que proveen recursos y entidades que proveen identidades de acuerdo. Entonces, y también establece los formatos y protocolos con los cuales se va a transmitir la información, entre ellos. Entonces, hay varios elementos en este ecosistema y el primero de ellos fundamentales, el propio proveedor de identidad, o bueno muchas veces no veremos por ahí identificado como que va a permitir autentificar a los usuarios verificando que alguien es quien dice ser y que no no lo va a hacer mediante un solamente mediante usuario y contraseña. Podría ser por cualquier otro mecanismo que tenga definido ese proveedor de identidad, por ejemplo un certificado con como biometría, bueno, etc, etc. No cualquier mecanismo que decida si esa organización, que es válido para poder identificarse, lógicamente no enviaría a los atributos que sean necesarios de cara a la autorización, como como comentaba antes, que cada entidad enviará a los que los que sean necesarios para para la aplicación en concreto para el servicio en concreto. El tema también suele estar conectado con uno o varios repositorios de identidad. Es decir, por un lado podríamos tener diferentes mecanismos de acceso que decía antes como por ejemplo certificado biometría, contraseña, es actor, pero también esos usuarios podrían estar en diferentes lugares. Por ejemplo, le da una base de datos relacional o en cualquier otro, otro, software que tengamos instalado, como podría ser un caso, por ejemplo, active, director y de azufre, o cualquier otro similar que podamos vamos a encontrarlo. Luego también posee el nivel de identidad, pues normalmente suele implementar a su vez un single. También no deja de ser una especie de, lógicamente el otro. El otro gran elemento que no nos vamos a encontrar pues es el proveedor de servicio, es la aplicación la que va a dar servicio al usuario. Por un lado está el proveedor de identidad, que es el que identifica al usuario, y por otro lado está el proveedor de servicios, que es el que da el servicio valga la redundancia al usuario, el que le va a dar la funcionalidad que reclama el usuario, la demanda. Qué va a permitir? Por un lado, conectar directamente con el líder o bien con un servicio de descubrimiento? Podríamos tener los dos mecanismos. Delegar la autenticación a un agente externo o a autorizar en base a la respuesta recibida? Ha dicho externo el proveedor de servicios. Además, si se consumen cierta, esa absorción es ahora la respuesta de la autenticación y los atributos, por ejemplo, en el mundo j o doblete. Todo esto se conoce como, por ejemplo. No nos va a permitir, en base a esos datos y sus metadatos, dejarlas no dejarle hacer ciertas cosas, y también crea que lo haríamos por lo general, y esto no tiene por qué ser así; pero, por lo general se podrían crear cuentas locales en base a esa información recibida. No sería nada descabellado, pues ese usuario que recibamos de un agente externo tenga su correspondencia en un usuario, en el local, para poder asociar ciertos recursos de la aplicación o para hacer una auditoría. No tiene por qué ser todos los datos, lógicamente ni tiene por qué ser la forma en la Cámara, ni si se ha conectado con contraseña; no tengamos almacenar la contraseña sino almacenar lo justo, lo que me haga falta, pues a lo mejor es un nombre y un uso un nombre y apellidos para mostrar arriba, para menuda río, para la cabecera, para identificar al usuario que está conectado, por ejemplo, o o alguna otra información que me envíe que sea relevante o un correo electrónico para poder enviarle notificaciones de acuerdo. Otro de los de los elementos de la Federación sería el servicio de descubrimiento que permitiría al usuario localizar su organización y su subida en su proveedor de identidad suelen implementar elementos de filtrado, a veces no por nombre, por si por localización. Podríamos esto puede ser útil para, para, en base a ciertas características del usuario que me vaya directamente a un proveedor de identidad. Otro antes comentábamos que podríamos tener varios proveedores de identidad para distintos usuarios y cada uno 70 con el que le corresponda de esta manera. Este servicio descubrimiento me podría ya dirigir directamente en base a mis características, que me vaya ya directamente a uno u otro sin tener que seleccionar lo que es una especie de de facilitar las cosas al usuario también podría tener memoria relacionada con esto sea lo último que he seleccionado, pues es el que me va a que me va a llevar a que me va a abrir por defecto este. Este servicio descubrimiento podría implementarse en el propio proveedor del servicio o estar relegado a un servicio externo también esto último el servicio externo es bastante común en federaciones del tipo Japan aunque también suele verse en otras de tipo de malla Banesto, lo veremos a ahora un poco los distintos tipos de federación, que que existe como cómo funciona, entonces dentro de la de la Federación, tiene que existir una relación de confianza. Entonces se establece en base a políticas, acuerdos y no serie de metadatos, como son identificadores de entidad claves públicas de identidad para firmado y cifrado en Pons en los que se espera recibir ciertas peticiones de autenticación o de atributos en el caso que los proveedores de servicios, también los atributos que se solicita, los metadatos, ejemplos y trabajar. Si hablásemos enclave, examen suelen contener además información de protocolo soportados, ciertas extensiones o categorías, etc. Etc. Y generalmente esto es datos suelen estar unidos al proceso por el que se firma la pertenencia a una entidad a la federación, la política de federación en sí misma. En cuanto a los modelos de federación que antes hablábamos de mes o Maya y el japonés poco podríamos encontrarnos con varios de ellos con varios distintos, en este caso el primero que nos podemos encontrar sería Bale, que habría una conexión directa entre los proveedores de identidad y el proveedor de servicios y soporte de protocolos. Por tanto, dependería de los soportados por el propio proveedor de identidad y podría existir una especie de descubrimiento centralizado. En este caso sería lo más parecido por ejemplo, un single, por ejemplo, en el que todas y todos nuestros servicios van a ir con esta base, ese proveedor de identidad, por decirlo de alguna manera, a un único proveedor de identidad. Si nos vamos a algo más avanzado y no seríamos a un modelo desmaya modelo mes donde la habría una conexión directa entre diferentes proveedores de identidad y proveedores de servicios. Al final sería un poco una extensión de casi de lo de lo anterior, lo que pasa que habría habido como varias burbujas, con su propio proveedor de identidad, asociado a ciertos proveedores de servicios. Si bien es cierto que que aunque una entidad pueda perder un servicio, tenga asociado un proveedor de identidad, si estoy logado en otro proveedor de servicios que estén Amaia podría tener acceso a ese ese servicio, en concreto. Por eso, el nombre de de Amaia, el soporte de protocolos dependería, de los protocolos también soportados por por el lógicamente, Bale, y podría existir descubrimiento, también centralizado, en este caso para, para un poco organizar un poco mejor manera. Toda la toda la malla y también los metadatos estarían, estaría centralizado en este caso el caso del modelo Japan, todo vale. Este es el modelo que utiliza, así realmente bale, quería un poco que viésemos diferentes modelos para entenderlo bien. El modelo que utiliza Sir es este modelo Japan -stock y se basa en que la conexión entre los diferentes proveedores de identidad y los proveedores de servicios se realiza a través de un hat, el Jaap en el caso de Siria es el propio sistema, decir vale ser un pueblo al que nos va a poner esa esa relación un poco al que se va, el que va a organizar todo el que va dirigir la orquesta. Por decirlo de alguna manera, entonces yo como proveedor de servicios, lo que voy a tener es que conectar, de conseguir, y ya si eso que se va a encargar de de lanzarme con los con los diferentes proveedores de identidad digamos si no Entonces. Los protocolos que se van a poder utilizar aquí serán todos los protocolos que utilice el pueblo, que no sea capaz de proporcionar si en este caso en concreto no. Entonces aquí tenemos una una gran ventaja, porque, independientemente del de aplicación, independientemente del proveedor de servicios y simplemente con conectarnos a través decir, vamos a poder tener la opción de tener un gran abanico de proveedores de identidad disponibles, simplemente porque ellas ya están, dice ya están configuradas dentro decir entonces digamos que nos lo centraliza de cierta. Cierta manera, por supuesto, el descubrimiento centralizado juega un papel muy importante debido a este. Este motivo y por supuesto tienen que estar centralizados no puede ser de otra manera porque el proveedor de servicios no nos va a conocer nada que no esté en el año que va a ser al centro de este modelo. Ahora, una vez visto toda la parte de decir, bueno, antes hablábamos del tema también, que iba a haber usuarios locales con la posibilidad de de autor, registro. Vale, que vamos a tener que quedar que darle soporte, poder asignar los roles en función del nivel de acceso que queramos darle y también poder tener una gestión y administración de estos usuarios locales. Por un lado, tendríamos los usuarios que nos vamos a ir de la Federación de decir y, por otro lado, vamos a tener este otro grupo de usuarios desbaratando. No surgen una serie de desafíos que tenemos que darles solución. Por eso, diferentes sistemas de autenticación y autorización. Si local, bueno, de momento no tenemos más, pero podría llegar a darse el caso en algún momento no, pero queremos eso. Tenemos 2, dos bases de datos de usuarios, por un lado y, por otro lado, los usuarios locales y además diferentes protocolos en el caso de decir está trabajando con la respuesta que nos va a dar examen, como como casi cualquier Jaap de autenticación, va casi todos trabajando en este mecanismo. Sin embargo, internamente antes lo comentábamos cuando estábamos hablando de los servicios, lo ideal sería trabajar con j o doblete. Sigamos el estándar, por decirlo de alguna manera, para resolver la parte de autenticación de autorización dentro del ecosistema de servicios. Por lo tanto, tendremos que hacer una especie de de traducción de traducción de ese protocolo de transformarlo the same, la jota doblete bale. Entonces, cómo lo vamos a? Cómo lo vamos a intentar resolver? Pues necesitamos una pieza que nos cubra estos 2, estos dos puntos, por un lado, que nos centralice. Eso es ese gestión de usuarios locales con usuarios remotos y además nos haga la traducción, Bale. Entonces, ahí es donde viene al rescate lo que va a ser un es ni Aemet. Ni aena orientado a aplicaciones y servicios es un proyecto que está bajo el paraguas de Rijkaard, lo cual es toda una garantía de cuentas entre las características que se pueden en que podemos encontrar aquí. Bueno, pues por un lado, el registro de usuarios. Esto nos nos va a venir muy pero que muy bien para el tema de los usuarios locales, que comentábamos hace un rato, y yo nos va a resolver toda esta. Toda esta papeleta nos va a dar la opción del otro registro y también la lógica de esos usuarios nos va a dar toda esa pantalla y también esa gestión de grupos de usuarios roles etcétera etcétera gestión de permisos también tienen la posibilidad integración y federación con sistemas de look de terceros, incluyendo lo social y el uso de protocolos estándar como penalti, con todo a 2, a dos puntos 0; junto con esto puede funcionar como broker de identidad. Lo cual es muy importante para el caso de Sir, en este caso. No podemos conectarlo con Sir perfectamente vale. Nuestra aplicación va a trabajar con cloaca y cloacas. Es el que se comunica con, digamos que pondríamos nuestro propio aquí en el, el nuestro lado que nos va a juntar tanto los usuarios que nos vengan decir, como los usuarios que nos vengan de que tenga definidos localmente. Vale, con lo cual, tendríamos de cara a la aplicación único, mecanismo de autenticación y autorización de cara de cara al propio servicio, vale tanto para usuarios locales como para el usuario, es decir, que luego sería el que el que nos vaya a gestionar las dos fuentes de datos las dos fuentes de usuarios. Entonces ahí la importancia de entrada, donde juega un papel fundamental en este caso y por eso lo nos hemos decantado por una solución de este tipo lógicamente es capaz de soportar diferentes métodos de acceso vale para para una misma aplicación. Es decir, podríamos decirle que queremos entrar como usuario local o como usuario de acceso mediante Sir Bale, con lo cual es otro de los de los puntos también relacionado con los usuarios locales, pues podríamos customizar de cierta manera a las pantallas de registro y luego para adaptarlo a esos, a eso. Al nuestra aplicación vamos al Luca Anfield de nuestra de nuestro sistema y bueno, pues también otras características, integración con la edad activa, director y autenticación doble factor en? Bueno, podremos tener una única instancia para diferentes aplicar y luego, bueno, pues en cuanto al tema de la configuración también poco resaltar que es bastante sencillo, tiene una interfaz gráfica, que nos permite administrarlo; y además hay otros sistemas parecidos que no nos lo tienen tan logrado como como este la verdad y muy muy potente para para solucionar el tema de la autenticación en este caso y bueno, luego ya otro. Pasando a otro tema. Si tienes alguna pregunta cerca de la parte de autenticación, autorización, etc. No vale. El vano ya por por último, haya casi el otro parte que quería comentar. Es un poco la integración. Con la infraestructura antológica, vale la infraestructura antológicas las van enseñar mañana vale entonces no no voy a entrar hay en el detalle para ver lo que es ya mañana, nos lo vamos a comentar, pero en cierta manera vamos a necesitar integrar la infraestructura antológica, con la arquitectura semántica en la arquitectura, se mantenga. Esta parte de lo que estamos viendo es como almacenar los datos. Vale, como transformar desde el origen de datos, transformarlos hasta hasta un formato que tengamos establecido, digamos, a través de un proceso de tve, y al fin y al final acabará insertando en los triples toros y luego podríamos explotarlos a través de un puente es pagar que lo frontal etc etc vale la infraestructura antológica lo que va a hacer es definir la antología los datos. Todo esto vale que nos nos define el esquema por, por decirlo de alguna manera, y reduciendo mucho, no de entonces tenemos que poder hacer esa integración entre ambas partes y desde luego esa integración debería requerir el menor esfuerzo manual posible, pues la mayoría de los de los escenarios que surjan de los cambios en la antología. Sobre todo, es el problema. El gran problema que queremos dar solución aquí es adaptarnos a esos cambios que pasa cuando cambia los datos. Cuando cambia la estructura de los datos, si sigo en la antología, ha cambiado, por ejemplo, que un proyecto además de tener nombre, se le añade un campo nuevo, por ejemplo, que sea la fecha de comienzo para decir algo, y se elimina no sé qué otro campo y además se añade otra entidad nueva que no teníamos contemplada. Eso puede ser, puede ocurrir desde que este sistema ha puesto en producción y eso tenemos que darle solución de cierta cierta manera, y hoy es un poco lo que lo que queremos tenemos que lidiar, eso, todo aquello que podamos que podamos automatizar para minimizar los cambios manuales, pues es necesario. Eso es lo que comentaba. Ahora mismo no que indicar que, aunque se busque la máxima automatización posible, pues habrá puntos en lo que los que están no se podrá llevar a cabo como, por ejemplo, el proceso de creación y actualización de antologías y la adaptación de éstos a los cambios al proceso de mal. Es decir, la tele va a haber que modificarlas. Si me cambia la estructura de datos, donde tengo que ir, lógicamente la tele tendrá que transformar otra cosa, no ya que requiere de una actualización manual. Evidentemente no hay no, no hay mucho mucho que hacer. Entonces el proceso comienza con cambios en general, Bale, comenzaría con cambios en la red de Deontología. Estos cambios desembocan en flujos de trabajo automáticos. En las acciones de las cuales construyen y despliegan la antología van a van a generar una serie de artefactos. Como resultado de estas modificaciones, al final todo esto como os digo lo comentarán mañana seguramente la sesión como resultado de mediante estas modificaciones se va a generar el un artefacto, una librería, un con las clases, con los ojos, digamos, que corresponden a las clases o tipos de entidades. Que han definido la odontología. Bale que posteriormente se utilizará la arquitectura semántica, como vimos antes, y este artefacto se va a subir automáticamente a la central para que esté disponible a través de un repositorio. Además, ese artefacto se va a crear un fichero de instrucciones de eta con los cambios producidos, es decir, nos va, nos va a decir, pues he cambiado concierto, estructura vale para que se sea entendible por por una máquina. Nos va a decir que se ha modificado esta clase se ha añadido este atributo se ha eliminado este otro etc etc entonces es lo que denominamos fichero del tacón, los cambios, la comunicación, entre la infraestructura antológica y la arquitectura semántica para recuperar estos ficheros del tas se realizará a través de una que denominamos, que es la que está ahí un poco y en el medio. Cuando el número de cambios en la antología sea suficientemente maduro, vale un pastor humano, aquí no va a quedar más remedio que cáncer; nación manual. Se va a encargar de la parada de servidor bale y posterior realización del bacalao de los datos existentes, para que antes de hacer nada, ninguna modificación en la estructura, estructuras, asegurarse de que, si pasase algún problema, poder recuperarnos, el siguiente paso sería hacer de forma manual los cambios en los cambios que se pudieran haber hecho a mano a en paralelo mientras el sistema se estaba desarrollando. Lo hablado en Teología y además, pero, bueno, realmente tendríamos que desplegar los cambios de la tele para hacer la importación de los de los datos. Eso tendría que ser manual y ya lo último paso y éste sí de forma automatizada. Una vez se levanta la aplicación sería el procesamiento del fichero delta para modificar los datos almacenados en el triple héctor. Se tendrán que coger todo ese fichero y hacer las actuaciones que tengas que hacer para adaptarlo a lo que te está diciendo, a esos cambios que se que sean, que se han producido. Entonces, bueno, básicamente el proceso de integración entre entre ambas, entre ambas partes, entre ambos bloques, grandes bloques del sistema, como son la infraestructura antológica, la arquitectura semántica sería. Esto dicho un poco a grandes, a grandes rasgos, no. Entonces, bueno, nada. Bueno, hasta aquí era el material que tenía preparado para hoy. No sé si queréis aprovechar el tiempo que queda para para resolver alguna alguna duda que os haya surgido durante durante la sesión. Entonces, bueno, si no, también cualquier duda que surge a posteriori también nos podéis, nos podéis ir preguntando o en los próximos días al resto de gente que vaya impartiendo la sesión al buenamente aclararán muchas de las que de los melones que, seguramente abierto durante durante esta sesión. Entonces, es nada a vuestra disposición para para resolver dudas. Pues sí claro, cuando vayamos viendo los próximos días. No iba a decir, yo supongo que la próxima envía cuando hay duda, ahora mismo, una visión general, todavía no sé claro, el objetivo de la sesión de hoy era ver un poco, de forma general lo que es la arquitectura, y, como se había montado, qué decisiones de la arquitectura se habían llegado a tomar. Luego ya la idea sería un poco más a meterse a fondo en cada una de las de las partes, no van a ser seguramente sesiones más, más prácticas, o no digo la de mañana porque va a ser un poco similar a pero relacionada con la parte de la infraestructura antológica, pero a partir de ahí digamos que van a hacer sesiones más, gracias. También son más entretenidas que que esta, que, bueno, es un poco, un poco larga al final y de teoría. Entonces, yo creo que si vengo con respecto a este último cambio de la antología y la admiración a la arquitectura semántica, todo la aplicación del delta la tiene que hacer una persona, o sea, los cambios que que no sé cuál ha dicho la aplicación del fichero Delta que una vez que separa la sede datos, ver las diferencias y tal, no lo hace una máquina lo tiene que hacer una persona, no lo hace una máquina es precisamente lo que tiene que hacer una persona, digamos, en este caso es actualizarlo, que los módulos que se hayan visto afectados por el cambio de la antología, el primero de ellos, fundamentalmente bueno, por un lado ese fichero ya de con los ojos, que habrá que actualizarlo, la siguiente versión y evidentemente, estamos en el mundo Java y ese tipo de actualizaciones no se pueden hacer en caliente. Con lo cual, como mínimo Barry, va a requerir de un reinicio, y el siguiente punto, que tendría que ser manual, sería el cambio de la tele. Porque vamos a pasar de estar transformando los datos a una versión, a una estructura que teníamos previa a una nueva, a una nueva versión en la que tengamos un una estructura más o menos diferente, porque pueden ser cambios mínimos o podría ser un cambio muchísima más, más más sustancial. Ahí hay, dependería no, pero eso sería lo que tiene que hacerse de forma manual, lo que es la aplicación del delta. El sistema va a saber luego, en el próximo, cuando se levante con los cambios, va a aplicar ese ese fichero de forma automática. Solo eso. No sé si tenéis alguna duda más, sino bueno, pues no lo podemos dejar aquí como fue así. Vale pues mañana mañana seguimos entonces bueno tocará con mis compañeros pero pero bueno lo explicará muy bien. Luego.