UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS...
Transcript of UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS...
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN NETWORKING Y
TELECOMUNICACIONES
“IMPLEMENTACIÓN DE UN SISTEMA CENTRALIZADO DE
AUTENTICACIÓN PARA USUARIOS DE LAS DIFERENTES
APLICACIONES WEB DE LA UG”
PROYECTO DE TITULACIÓN
Previa a la obtención del Título de:
INGENIERO EN NETWORKING Y TELECOMUNICACIONES
AUTORES:
CARLOS LEONARDO PEÑARRIETA VALENCIA
DAYANA MISHELL VILLAFUERTE VILLAFUERTE
TUTOR:
ING. MARLON ALTAMIRANO DI LUCA, MSIA
GUAYAQUIL – ECUADOR
2017
REPOSITORIO NACIONAL EN CIENCIA Y TECNOLOGÍA
FICHA DE REGISTRO DE TESIS/TRABAJO DE GRADUACIÓN
TÍTULO Y SUBTÍTULO: “IMPLEMENTACIÓN DE UN SISTEMA CENTRALIZADO DE AUTENTICACIÓN PARA
USUARIOS DE LAS DIFERENTES APLICACIONES WEB DE LA UG”
AUTORES:
REVISOR/TUTOR:
INSTITUCIÓN:
UNIDAD/FACULTAD:
MAESTRÍA/ESPECIALIDAD:
GRADO OBTENIDO:
FECHA DE PUBLICACIÓN: No. DE PÁGINAS:
ÁREAS TEMÁTICAS:
PALABRAS CLAVES/ RESUMEN:
ADJUNTO PDF:
SI
NO X
CONTACTO CON AUTOR/ES: Teléfono: E-mail:
CONTACTO CON LA Nombre:
INSTITUCIÓN:
Teléfono:
E-mail:
Peñarrieta Valencia Carlos Leonardo y Dayana Mishell Villafuerte Villafuerte
Revisor: Ing. Alvarado Unamuno Eduardo Antonio, M.Sc Tutor: Ing. Altamirano Di Luca Marlon Alfonso, Msia Universidad de Guayaquil
Facultad de Ciencias Matemáticas y Físicas
Ingeniería en Networking y Telecomunicaciones
Tercer Nivel
127
La Universidad de Guayaquil cuenta con más de una aplicación web y cada una maneja una autenticación independiente. Basados en la fundamentación teórica se plantea usar un middleware haciendo uso del protocolo OpenID Connect para gestionar las credenciales de los usuarios, se utilizó la investigación aplicada y de campo realizando encuestas a los usuarios de las aplicaciones web de la UG. Para dar solución a la problemática se propone utilizar la herramienta IdentityServer4 con el fin de acceder a las aplicaciones protegidas con un único inicio de sesión, este sistema hace uso de un API para conectarse con Microsoft Office 365 y validar las credenciales de autenticación de los usuarios. Se utilizó la metodología Scrum para un desarrollo ágil y colaborativo. Se demostró que es factible centralizar la autenticación de las aplicaciones web de la UG, implementando este sistema se beneficiará a los estudiantes, docentes y administrativos de la UG.
Tecnología de la Información, Seguridad de la información.
Sistema Centralizado, Autenticación, Autorización, Usuario, Seguridad.
0988418354 0939105450
II
CARTA DE APROBACIÓN DEL TUTOR
En mi calidad de Tutor del trabajo de titulación, “IMPLEMENTACIÓN DE
UN SISTEMA CENTRALIZADO DE AUTENTICACIÓN PARA USUARIOS
DE LAS DIFERENTES APLICACIONES WEB DE LA UG“ elaborado por
el Sr. Peñarrieta Valencia Carlos Leonardo y la Srta. Villafuerte Villafuerte
Dayana Mishell Alumnos no titulados de la Carrera de Ingeniería en
Networking y Telecomunicaciones de la Facultad de Ciencias Matemáticas
y Físicas de la Universidad de Guayaquil, previo a la obtención del Título
de Ingeniero en Networking y Telecomunicaciones, me permito declarar
que luego de haber orientado, estudiado y revisado, la Apruebo en todas
sus partes.
Atentamente
__________________________________
Ing. Marlon Altamirano, Msia
TUTOR
III
DEDICATORIA DE DAYANA MISHELL VILLAFUERTE VILLAFUERTE
Esta tesis va dedicada a Dios por
darme el don de la perseverancia para
lograr mis objetivos y permitirme llegar
hasta donde estoy, a mis padres
Mirian y Félix Villafuerte ellos fueron el
pilar fundamental para la construcción
de mi vida profesional, sembraron en
mí amor, respeto, responsabilidad y
deseos de superación, enseñándome
a encarar las adversidades y perseguir
mis sueños sin olvidar quien soy, de
donde vengo y a donde voy.
IV
DEDICATORIA DE CARLOS LEONARDO PEÑARRRIETA VALENCIA
Este trabajo lo dedico a Dios ya que
sin sus bendiciones nada de esto sería
posible.
A mi madre Liliana Valencia por el
apoyo constante a lo largo de mi vida
y por ser mi motivo de superación, a
mis hermanos por ser siempre
incondicionales y a toda mi familia por
su apoyo constante.
Dedicado a cada uno de ustedes por
ayudarme a alcanzar mis metas.
V
AGRADECIMIENTOS DE DAYANA MISHELL VILLAFUERTE
VILLAFUERTE
Agradezco principalmente a Dios por
permitirme sonreír ante mis logros que
son el resultado de mi esfuerzo y
perseverancia, todo lo que soy y lo que
tengo es gracias a él, por regalarme
unos padres maravillosos quienes han
forjado mi camino y me han dirigido
por el sendero correcto.
Gracias a mi familia, mis padres y
hermano por apoyarme en cada
decisión y creer en mí. Por los
ejemplos de perseverancia y
constancia que me ha infundado, por
su amor y sacrificios en todos estos
años, gracias a ustedes he logrado
llegar hasta aquí y convertirme en lo
que soy.
Gracias a Leo mi compañero de tesis
por su apoyo incondicional y por la
oportunidad de compartir este logro
juntos.
Agradezco también a mi tutor, revisor,
maestros y a la Universidad en general
por los conocimientos otorgados para
hacer esto posible.
VI
AGRADECIMIENTOS DE CARLOS LEONARDO PEÑARRRIETA
VALENCIA
Agradezco a Dios por darme la
sabiduría y la constancia para
alcanzar mis metas y objetivos.
A mi madre por siempre apoyarme y
motivarme para lograr todos mis
objetivos.
A mi tía Maria Valencia por el apoyo
brindado para mi preparación
profesional.
A Mishell por su dedicación en este
proyecto y el apoyo incondicional de
siempre.
Agradezco al tutor y revisor por sus
consejos para el desarrollo de este
proyecto.
A mis amigos, familiares, compañeros
y profesores por las experiencias y
conocimientos compartidos.
VII
TRIBUNAL PROYECTO DE TITULACIÓN
_____________________________
Ing. Eduardo Santos Baquerizo, M.Sc.
DECANO DE LA FACULTAD
CIENCIAS MATEMÁTICAS Y FÍSICAS
_____________________________
Ing. Eduardo Alvarado Unamuno, M.Sc
PROFESOR TUTOR REVISOR
DEL PROYECTO DE TITULACIÓN
_________________________
Ing. Harry Luna Aveiga, M.Sc
DIRECTOR
CINT
_____________________________
Ing. Marlon Altamirano Di Luca, Msia
PROFESOR DIRECTOR DEL
PROYECTO
DE TITULACIÓN
_________________________
Ab. Juan Chávez A.
SECRETARIO
VIII
DECLARACIÓN EXPRESA
“La responsabilidad del contenido de este Proyecto de Titulación, me corresponden exclusivamente; y el patrimonio intelectual de la misma a la UNIVERSIDAD DE GUAYAQUIL” ___________________________________
PEÑARRRIETA VALENCIA CARLOS LEONARDO
___________________________________
VILLAFUERTE VILLAFUERTE DAYANA MISHELL
IX
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN NETWORKING Y
TELECOMUNICACIONES
“IMPLEMENTACIÓN DE UN SISTEMA CENTRALIZADO DE
AUTENTICACIÓN PARA USUARIOS DE LAS DIFERENTES
APLICACIONES WEB DE LA UG”
Proyecto de Titulación que se presenta como requisito para optar por el
título de INGENIERO EN NETWORKING Y TELECOMUNICACIONES
Autores:
PEÑARRIETA VALENCIA CARLOS LEONARDO C.I.: 1722952189
VILLAFUERTE VILLAFUERTE DAYANA MISHELL C.I.: 0951622240
Tutor: ING. MARLON ALTAMIRANO DILUCA, MSIA
Guayaquil, septiembre del 2017
X
CERTIFICADO DE ACEPTACIÓN DEL TUTOR
En mi calidad de Tutor del proyecto de titulación, nombrado por el Consejo
Directivo de la Facultad de Ciencias Matemáticas y Físicas de la
Universidad de Guayaquil.
CERTIFICO:
Que he analizado el Proyecto de Titulación presentado por
los estudiantes PEÑARRIETA VALENCIA CARLOS LEONARDO y
VILLAFUERTE VILLAFUERTE DAYANA MISHELL, como requisito previo
para optar por el título de Ingeniero en Networking y Telecomunicaciones
cuyo tema es:
“IMPLEMENTACIÓN DE UN SISTEMA CENTRALIZADO DE
AUTENTICACIÓN PARA USUARIOS DE LAS DIFERENTES
APLICACIONES WEB DE LA UG”
Considero aprobado el trabajo en su totalidad.
Presentado por:
Peñarrieta Valencia Carlos Leonardo C.I.: 1722952189
Villafuerte Villafuerte Dayana Mishell C.I.: 0951622240
Tutor: Ing. Marlon Altamirano, Msia
Guayaquil, septiembre del 2017
XI
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN NETWORKING Y TELECOMUNICACIONES
AUTORIZACIÓN PARA PUBLICACIÓN DE TESIS EN FORMATO
DIGITAL
1. Identificación del Proyecto de titulación
Nombre Alumno: Peñarrieta Valencia Carlos Leonardo
Dirección: Guayaquil, Bastión Popular Bloque 7B
Teléfono: 0988418354 E-mail: [email protected]
Nombre Alumno: Villafuerte Villafuerte Dayana Mishell
Dirección: Guayaquil, Mapasingue Este Coop 27 de enero
Teléfono: 0939105450 E-mail: [email protected]
Facultad: Ciencias Matemáticas y Físicas.
Carrera: Ingeniería en Networking y Telecomunicaciones.
Título al que opta: Ingeniero en Networking y Telecomunicaciones
Profesor guía: Ing. Marlon Altamirano, Msia
Título del Proyecto de titulación: “IMPLEMENTACIÓN DE UN SISTEMA CENTRALIZADO DE AUTENTICACIÓN PARA USUARIOS DE LAS DIFERENTES APLICACIONES WEB DE LA UG”
XII
Tema del Proyecto de Titulación: Integración, Autenticación,
Centralizado, SSO, OAuth2, OpenID, Seguridad, Usuario.
2. Autorización de Publicación de Versión Electrónica de la Tesis
A través de este medio autorizo a la Biblioteca de la Universidad de Guayaquil y a la Facultad de Ciencias Matemáticas y Físicas a publicar la versión electrónica de esta tesis. Publicación electrónica:
Inmediata X Después de 1 año
Firma Alumnos:
___________________________________________ PEÑARRRIETA VALENCIA CARLOS LEONARDO
__________________________________________ VILLAFUERTE VILLAFUERTE DAYANA MISHELL
3. Forma de Envío:
DVDROM X CDROM
XIII
ÍNDICE GENERAL
CARTA DE APROBACIÓN DEL TUTOR ...................................................II
DEDICATORIA DE DAYANA MISHELL VILLAFUERTE VILLAFUERTE ..III
DEDICATORIA DE CARLOS LEONARDO PEÑARRRIETA VALENCIA . IV
AGRADECIMIENTOS DE DAYANA MISHELL VILLAFUERTE VILLAFUERTE ......................................................................................... V
AGRADECIMIENTOS DE CARLOS LEONARDO PEÑARRRIETA VALENCIA ............................................................................................... VI
TRIBUNAL PROYECTO DE TITULACIÓN ............................................. VII
DECLARACIÓN EXPRESA ................................................................... VIII
CERTIFICADO DE ACEPTACIÓN DEL TUTOR ...................................... X
AUTORIZACIÓN PARA PUBLICACIÓN DE TESIS EN FORMATO DIGITAL .................................................................................................. XI
ÍNDICE GENERAL ................................................................................ XIII
ABREVIATURAS .................................................................................. XVII
SIMBOLOGÍA ...................................................................................... XVIII
ÍNDICE DE CUADROS .......................................................................... XIX
ÍNDICE DE GRÁFICOS .......................................................................... XX
RESUMEN............................................................................................. XXI
ABSTRACT .......................................................................................... XXII
INTRODUCCION .......................................................................................1
CAPÍTULO I ...............................................................................................4
EL PROBLEMA .........................................................................................4
PLANTEAMIENTO DEL PROBLEMA ........................................................4
Ubicación del Problema en un Contexto .................................................4
Situación Conflicto. Nudos Críticos .........................................................5
Causas y consecuencias del problema ...................................................6
Delimitación del problema .......................................................................7
Formulación del problema ......................................................................7
Evaluación del Problema ........................................................................7
Alcances del Problema ...........................................................................8
OBJETIVOS DE LA INVESTIGACIÓN.......................................................9
Objetivo general......................................................................................9
XIV
Objetivos específicos ..............................................................................9
JUSTIFICACIÓN E IMPORTANCIA DE LA INVESTIGACIÓN .................10
CAPÍTULO II ............................................................................................11
MARCO TEÓRICO ..................................................................................11
ANTECEDENTES DEL ESTUDIO ...........................................................11
FUNDAMENTACIÓN TEÓRICA ..............................................................13
Autenticación ........................................................................................14
Modelos de autenticación ..................................................................14
Autorización ..........................................................................................15
Single Sign-On .....................................................................................16
Protocolos y estándares .......................................................................17
OpenID ..............................................................................................17
OAuth ................................................................................................18
OAuth 2.0 ..........................................................................................20
OpenID OAuth Hybrid Protocol ..........................................................22
Facebook Connect .............................................................................23
OpenID Connect ................................................................................23
API........................................................................................................25
API de Microsoft Office 365 ..................................................................25
Requerimientos para la elección de la solución ....................................26
Opciones candidatas ............................................................................28
Cas ....................................................................................................28
Shibboleth ..........................................................................................30
Enterprise Sign On Engine.................................................................33
IdentityServer4...................................................................................35
Puntuación de las opciones candidatas ................................................39
Sistema elegido para la implementación ...............................................41
Descripción de Identity Server ..............................................................41
Panorama de las aplicaciones ..............................................................41
OpenID Connect y OAuth2 en IdentityServer4 ......................................44
¿Cómo puede ayudar IdentityServer4? ................................................45
Análisis de Aplicaciones web ................................................................46
Sistema de gestión de proyectos .......................................................46
XV
Sistema Integrado de la Universidad de Guayaquil (SIUG) ................47
Mecanismos para integrar aplicaciones clientes con Identity Server4 ...49
Mecanismos en Identity Server4 ........................................................49
Mecanismos en las aplicaciones clientes ...........................................50
FUNDAMENTACIÓN SOCIAL .................................................................51
FUNDAMENTACIÓN LEGAL ..................................................................52
HIPÓTESIS .............................................................................................58
VARIABLES DE LA INVESTIGACIÓN .....................................................58
Variable independiente .........................................................................58
Variable dependiente ............................................................................58
DEFINICIONES CONCEPTUALES .........................................................59
CAPITULO III ...........................................................................................62
METODOLOGÍA DE LA INVESTIGACION ..............................................62
DISEÑO DE LA INVESTIGACIÓN ...........................................................62
Modalidad de la Investigación ...............................................................62
Cuantitativo ...........................................................................................62
Tipos de Investigación ..........................................................................62
Investigación aplicada...........................................................................62
POBLACIÓN Y MUESTRA ......................................................................63
Población ..............................................................................................63
Muestra ................................................................................................64
INSTRUMENTOS DE RECOLECCIÓN DE DATOS ................................66
Técnica .................................................................................................66
Instrumentos de la Investigación ...........................................................66
Encuesta ............................................................................................66
Recolección de la información ..............................................................66
Procesamiento y Análisis ......................................................................67
Análisis e Interpretación de Datos ........................................................67
Validación de la Hipótesis .....................................................................76
CAPÍTULO IV ..........................................................................................78
PROPUESTA TECNOLÓGICA ................................................................78
Factibilidad operacional ........................................................................78
Factibilidad técnica ...............................................................................79
XVI
Factibilidad legal ...................................................................................79
Factibilidad económica .........................................................................80
Etapas de la metodología del proyecto .................................................81
Entregables del proyecto ......................................................................84
Criterios de validación de la propuesta .................................................88
Criterios de aceptación del producto o servicio .....................................91
CONCLUSIONES Y RECOMENDACIONES ...........................................94
Conclusiones ........................................................................................94
Recomendaciones ................................................................................95
BIBLIOGRAFÍA ........................................................................................96
ANEXOS ............................................................................................... 102
XVII
ABREVIATURAS
UG Universidad de Guayaquil
www World Wide Web (red mundial)
M.Sc. Master
MSIA Magister en Seguridad Informática Aplicada
Ing. Ingeniero
Http Protocolo de transferencia de Hyper Texto
Url Localizador de fuente Uniforme
Api Interfaz de programación de aplicaciones
SSO Single Sign-On
SIUG Sistema Integrado Universidad de Guayaquil
XVIII
SIMBOLOGÍA
n Tamaño de la muestra
e Error de estimación
m Tamaño de la población
XIX
ÍNDICE DE CUADROS
CUADRO N° 1 APLICACIONES WEB Y USUARIOS DE LA UG ...............5
CUADRO N° 2 CAUSAS Y CONSECUENCIAS DEL PROBLEMA ............6
CUADRO N° 3 DELIMITACIÓN DEL PROBLEMA.....................................7
CUADRO N° 4 PUNTUACIÓN DE LAS OPCIONES CANDIDATAS ........40
CUADRO N° 5 CUADRO DISTRIBUTIVO DE LA POBLACIÓN ..............65
CUADRO N° 6 CUADRO DISTRIBUTIVO DE LA MUESTRA ..................65
CUADRO N° 7 MEDICIÓN DE RESULTADOS – PREGUNTA 1 .............68
CUADRO N° 8 MEDICIÓN DE RESULTADOS – PREGUNTA 2 .............69
CUADRO N° 9 MEDICIÓN DE RESULTADOS – PREGUNTA 3 .............70
CUADRO N° 10 MEDICIÓN DE RESULTADOS – PREGUNTA 4 ...........71
CUADRO N° 11 MEDICIÓN DE RESULTADOS – PREGUNTA 5 ...........72
CUADRO N° 12 MEDICIÓN DE RESULTADOS – PREGUNTA 6 ...........73
CUADRO N° 13 MEDICIÓN DE RESULTADOS – PREGUNTA 7 ...........74
CUADRO N° 14 MEDICIÓN DE RESULTADOS – PREGUNTA 8 ...........75
CUADRO N° 15 CUADRO DE COSTOS .................................................80
CUADRO N° 16 SPRINT DEL PROYECTO ............................................81
CUADRO N° 17 CRITERIOS DE VALIDACIÓN DE LA PROPUESTA .....88
CUADRO N° 18 CRITERIOS DE ACEPTACIÓN DEL PRODUCTO O SERVICIO ...............................................................................................91
CUADRO N° 19 SPRINT REALIZADOS DURANTE EL PROYECTO ......93
XX
ÍNDICE DE GRÁFICOS
Gráfico 1 Descripción Gráfica Del Procedimiento De Autenticación .........14
Gráfico 2 Descripción Gráfica Del Procedimiento De Autorización ..........16
Gráfico 3 Escenario de funcionamiento de OAuth 2.0..............................21
Gráfico 4 Primer paso para la autenticación con el CAS ..........................29
Gráfico 5 Acceso a un aplicativo protegido con el CAS ...........................30
Gráfico 6 Grafico Proceso de login de Shibboleth ....................................33
Gráfico 7 Esquema de conectividad con Enterprise Sign On Engine .......34
Gráfico 8 Uso de IdentityServer ...............................................................39
Gráfico 9 Panorama de las aplicaciones ..................................................43
Gráfico 10 Representación Gráfica del Middleware .................................46
Gráfico 11 Página de Sistema de gestión de proyectos ...........................47
Gráfico 12 Página SIUG ..........................................................................49
Gráfico 13 Medición De Resultados – Pregunta 1 ...................................68
Gráfico 14 Medición De Resultados – Pregunta 2 ...................................69
Gráfico 15 Medición De Resultados – Pregunta 3 ...................................70
Gráfico 16 Medición De Resultados – Pregunta 4 ...................................71
Gráfico 17 Medición De Resultados – Pregunta 5 ...................................72
Gráfico 18 Medición De Resultados – Pregunta 6 ...................................73
Gráfico 19 Medición De Resultados – Pregunta 7 ...................................74
Gráfico 20 Medición De Resultados – Pregunta 8 ...................................75
Gráfico 21 Proceso de Inicio de Sesión ...................................................85
Gráfico 22 Página de login .......................................................................86
Gráfico 23 Actualizar datos ......................................................................87
XXI
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS CARRERA DE INGENIERÍA EN NETWORKING Y
TELECOMUNICACIONES
IMPLEMENTACIÓN DE UN SISTEMA CENTRALIZADO DE
AUTENTICACIÓN PARA USUARIOS DE LAS DIFERENTES
APLICACIONES WEB DE LA UG
Autores: Villafuerte Villafuerte Dayana Mishell
Peñarrieta Valencia Carlos Leonardo
Tutor: Ing. Marlon Altamirano. Msc
RESUMEN
La Universidad de Guayaquil cuenta con más de una aplicación web y cada una maneja una autenticación independiente. Basados en la fundamentación teórica se plantea usar un middleware haciendo uso del protocolo OpenID Connect para gestionar las credenciales de los usuarios, se utilizó la investigación aplicada y de campo realizando encuestas a los usuarios de las aplicaciones web de la UG. Para dar solución a la problemática se propone utilizar la herramienta IdentityServer4 con el fin de acceder a las aplicaciones protegidas con un único inicio de sesión, este sistema hace uso de un API para conectarse con Microsoft Office 365 y validar las credenciales de autenticación de los usuarios. Se utilizó la metodología Scrum para un desarrollo ágil y colaborativo. Se demostró que es factible centralizar la autenticación de las aplicaciones web de la UG, implementando este sistema se beneficiará a los estudiantes, docentes y administrativos de la UG. Palabras Claves: Sistema Centralizado, Autenticación, Autorización, Usuario, Seguridad.
XXII
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS CARRERA DE INGENIERÍA EN NETWORKING Y
TELECOMUNICACIONES
IMPLEMENTATION OF A CENTRALIZED SYSTEM OF
AUTHENTICATION FOR USERS OF THE DIFFERENT WEB
APPLICATIONS OF THE UG
Authors: Villafuerte Villafuerte Dayana Mishell
Peñarrieta Valencia Carlos Leonardo
Advisor: Ing. Marlon Altamirano. Msc
ABSTRACT
The University of Guayaquil has more than one web application and each handles an independent authentication. Based on the theoretical basis, it is proposed to use a middleware using the OpenID Connect protocol to manage the users' credentials, applied and field research using surveys to the UG web application users. To solve the problem, it is proposed to use the IdentityServer4 tool to access protected applications with a single login, this system makes use of an API to connect with Microsoft Office 365 and validate the authentication credentials of users. Scrum methodology was used for agile and collaborative development. It was demonstrated that it is feasible to centralize the authentication of the web applications of the UG, implementing this system will benefit the students, teachers and administrative of the UG.
Keywords: Centralized Systems, Authentication, Authorization, User, Security.
1
INTRODUCCION
En la actualidad el uso de internet y el aumento de los servicios que se
ofertan en este, se han convertido en parte fundamental para las
comunicaciones y el acceso a la información; la mayoría de personas que
pertenecen a una organización o institución utilizan múltiples aplicaciones
que funcionan en la web. En su mayoría estas aplicaciones requieren la
autenticación del usuario, es decir, demostrar mediante un identificador
que es quien dice ser. Además, varias de estas aplicaciones almacenan
información delicada de los usuarios como datos personales lo cual
requiere una mayor seguridad.
Por lo general cada una de estas aplicaciones utilizan su propio sistema
de autenticación al ser independientes entre sí, ocasionando
inconvenientes en los usuarios a medida que aparecen nuevos sistemas,
por tener que recordar un nombre de usuario y contraseña diferente en
cada aplicación para autenticarse, esto conlleva en muchos casos a que
el usuario realice malas prácticas comprometiendo la seguridad en las
aplicaciones que utiliza, como lo son:
Configuración de contraseñas inseguras.
Anotación de contraseñas en objetos o documentos en los que
puede tener acceso algún tercero.
Reutilización de contraseñas en las diferentes aplicaciones.
2
El objetivo de este proyecto de titulación es dar una solución a esos
inconvenientes, implementando un prototipo de sistema centralizado de
autenticación para demostrar que los usuarios puedan acceder a todas
las aplicaciones web de la UG con un solo nombre de usuario y
contraseña, este servicio de autenticación sirve para las aplicaciones
actuales y para futuras aplicaciones que se desarrollen para la UG,
debido a su escalabilidad.
Por lo que se propone la implementación de un Sistema Centralizado de
Autenticación similar a los utilizados por otras plataformas como la de
Google en la que una vez autenticado el usuario tiene acceso a sus
diferentes aplicaciones como Google+, Gmail, Drive y YouTube, evitando
autenticarse en cada aplicativo, siendo ninguno de ellos similares entre sí
ni alojados en distintos servidores.
A continuación, se detallan cada uno de los capítulos que conforman este
proyecto de titulación:
Capítulo I – PLANTEAMIENTO DEL PROBLEMA, este capítulo se
describirá las generalidades del proyecto, detallando el problema que se
desea resolver con sus causas y consecuencias, además de la
delimitación, alcance, objetivos para la implementación de este proyecto.
Capítulo II – MARCO TEÓRICO, este capítulo redacta los antecedentes
de estudio, la información teórica para el desarrollo e implementación del
proyecto, fundamentación legal y fundamentación social apegados a
nuestra área.
3
Capítulo III – METODOLOGÍA DE LA INVESTIGACION, este capítulo
detalla las modalidades y tipos de investigación, la población y la muestra.
Con el uso de técnicas de investigación se recolectará información
necesaria para el desarrollo de este proyecto, la cual será analizada para
llegar a conclusiones en el desarrollo.
Capítulo IV – PROPUESTA TECNOLÓGICA, luego del análisis de la
información obtenida de la población, en este capítulo se definirá la
propuesta tecnológica, se realizará un análisis de factibilidad, etapas de la
metodología, entregables del proyecto, criterios de evaluación de la
propuesta y aceptación del producto o servicio.
Se desarrollaron las respectivas conclusiones y recomendaciones al final
de la documentación, además, se adjuntan los anexos los cuales
contienen información adicional que puede ser consultada.
4
CAPÍTULO I
EL PROBLEMA
PLANTEAMIENTO DEL PROBLEMA
Ubicación del Problema en un Contexto
La universidad estatal de Guayaquil es la institución de educación
superior más grande del país de acuerdo con el número de estudiantes,
cuenta con su sede principal en la ciudadela Salvador Allende junto al
Malecón del Salado entre Av. Delta y Av. Kennedy en la ciudad de
Guayaquil, Guayas.
Al ser un centro educativo requiere sistemas para compartir servicios y
recursos que son necesarios para interactuar con la información.
La universidad de Guayaquil “UG” en la actualidad cuenta con un
Sistema Integrado de aplicaciones “SIUG”, el cual es un frond-end1 que
interactúa con diferentes aplicaciones, tanto en el ámbito académico,
financiero, talento humano y consultas públicas. Además, se encuentra
en desarrollo una aplicación para la publicación de proyectos de
investigación, esta aplicación lleva el nombre de “Sistema Integrado de
Gestiones”.
La UG también cuenta con un servicio de correo institucional con un
proveedor externo Microsoft Office 365.
1 Frond-end es la parte frontal de un sitio web, la parte que el usuario final ve en el navegador.
5
El principal inconveniente es que para el uso de estas aplicaciones se
requiere una autenticación diferente, es decir, la persona debe tener un
usuario y contraseña distinto para cada aplicación, resultando tedioso
para el usuario a medida que incrementa el número de sistemas.
Situación Conflicto. Nudos Críticos
Actualmente en la UG no existe un Sistema Centralizado de Autenticación
para las aplicaciones web, por lo que se da la redundancia de
autenticación en cada sistema.
Entre las diferentes aplicaciones web que ofrece como servicio la UG se
encuentran los siguientes:
CUADRO N° 1 APLICACIONES WEB Y USUARIOS DE LA UG
Aplicaciones web Usuarios que la utilizan
Office 365 Estudiantes, docentes y
administradores
SIUG Estudiantes, docentes y
administradores
Sistema Integrado de gestiones Docentes e investigadores
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Estas aplicaciones facilitan la comunicación, acceso a la información y
procesos educativos por medio de ambientes virtuales de aprendizaje.
Al tener más de una aplicación disponible en el centro universitario, a los
usuarios se les dificulta recodar las credenciales de autenticación para
cada sistema web. Para evitar recordar diferentes claves de autenticación,
hay usuarios que usan la misma contraseña en todos los aplicativos,
6
siendo esto una práctica insegura, ya que, si un usuario pone en
evidencia estas credenciales, una persona mal intencionada podría
ingresar a todos los aplicativos de la víctima, obligando al usuario a
cambiar sus claves en cada sistema.
Causas y consecuencias del problema
CUADRO N° 2 CAUSAS Y CONSECUENCIAS DEL PROBLEMA
CAUSAS CONSECUENCIAS
Falta de integración de las
aplicaciones en un sistema
centralizado de autenticación.
Tener un sistema de autenticación
independiente para cada
aplicación.
Poseer un usuario y contraseña
diferente para cada aplicación.
Recordar varios usuarios y
contraseña, llegando al olvido de
alguno.
Anotación manual de
credenciales de ingreso a los
sistemas.
La mala manipulación de estas
credenciales podría exponerla a
terceros.
Que el usuario pierda un equipo
portátil en el que contiene sus
credenciales de autenticación
guardadas en archivos digitales.
Que un tercero acceda a este
equipo portátil y haga uso mal
intencionado de las credenciales
de autenticación.
El usuario requiere mayor soporte
al olvidar las claves en los
sistemas.
Se necesita ayuda de los
administradores de sistemas para
el cambio de la clave en cada
aplicativo.
Personas con pocos
conocimientos en informática
Problemas al recordar un usuario y
contraseña diferente para cada
aplicación.
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
7
Delimitación del problema
CUADRO N° 3 DELIMITACIÓN DEL PROBLEMA
Campo: Informático
Área: Seguridad informática
Aspecto: Desarrollo de software y Base de
Datos
Tema: “Implementación de un Sistema
Centralizado de Autenticación
para usuarios de las diferentes
aplicaciones web de la UG”
Geográfica: Universidad de Guayaquil
Ciudadela Salvador Allende
Espacio: Mayo-Septiembre del 2017
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Formulación del problema
¿Si se demuestra que es posible la implementación de un Sistema
Centralizado de Autenticación, se podrá integrar a las aplicaciones web
de la universidad de Guayaquil con una sola autenticación?
Evaluación del Problema
Delimitado: Comprende la implementación de un prototipo de Sistema
Centralizada de Autenticación para la UG que autenticará al usuario para
poder acceder a las aplicaciones web.
8
Claro: El objetivo consiste en que se utilice un prototipo que demuestre
que se puede tener un único sistema de autenticación para las
aplicaciones web de la UG.
Concreto: En base a la problemática se ofrece implementación de un
prototipo de Sistema Centralizado de Autenticación, integrado con el
sistema Microsoft Office 365 y el SIUG.
Original: El usuario no necesitará reingresar sus credenciales para tener
acceso a todas las aplicaciones que se encuentren protegidas por este
sistema de autenticación.
Contextual: El Sistema de Autenticación se encargará de unificar y
centralizar la autenticación de los usuarios en las aplicaciones web de la
Universidad de Guayaquil.
Factible: Es posible la ejecución de este sistema porque contamos con
los conocimientos necesarios para desarrollarlo, además, existe suficiente
información científica y bibliográfica para poder lograr el prototipo de
implementación. Por otra parte, este proyecto cuenta con el permiso de
las autoridades de la UG, también con los materiales, infraestructura y
tecnología para poder ejecutarla.
Alcances del Problema
En esta investigación se implementará un prototipo de Sistema
Centralizado de Autenticación. Este sistema se integrará con la
plataforma Microsoft Office 365 para extraer las credenciales de
autenticación.
9
Para validar la autenticación se utilizará una nueva versión del SIUG y
dos aplicativos de desarrollo propio para realizar la demostración.
Se desarrollará pruebas de autenticación con dos tipos de usuarios:
estudiantes y docentes.
Para que el usuario se autentique se desarrollará una página web de
login, en el que deberá ingresar sus credenciales para acceder a los
aplicativos que integra el Sistema de Autenticación.
Este sistema será software libre, desarrollado en ASP.NET CORE, se
implementará en Microsoft Azure y estará activo hasta diciembre del 2017
para realizar las demostraciones.
OBJETIVOS DE LA INVESTIGACIÓN
Objetivo general
Implementar un prototipo de Sistema Centralizado de Autenticación para
los usuarios de las aplicaciones web de la UG.
Objetivos específicos
Analizar las aplicaciones web de la UG.
Definir mecanismos de integración para un solo sistema de
autenticación.
Demostrar la factibilidad técnica de tener un Sistema Centralizado
de Autenticación.
10
JUSTIFICACIÓN E IMPORTANCIA DE LA INVESTIGACIÓN
Debido a que las tecnologías de la información han evolucionado a
través de los años para mejorar la interacción de la información, con ello
se ha planteado la necesidad de autenticar a los usuarios para que
tengan acceso a los aplicativos, protegiendo la integridad del usuario y la
información almacenada.
Por lo tanto, se ha optado por realizar la implementación de este
prototipo, con el objetivo de demostrar que se puede centralizar la
autenticación de las aplicaciones web de la UG, para que los usuarios
puedan acceder a los diferentes sistemas protegidos con una única
autenticación, asegurando la privacidad de los usuarios e integridad de la
información.
Este prototipo por implementar busca centralizar la administración de
credenciales de autenticación y acceso de los usuarios, a su vez
eliminando la creación de nuevos métodos de autenticación por cada
aplicación que se disponga.
Con esta implementación se ayudará al usuario, ya que no necesitará
recordar diferentes credenciales de autenticación, porque utilizará un
Sistema Centralizado para autenticarse con las aplicaciones.
Ante la posible creación de nuevos servicios web en la UG, se plantea
que se utilice un único sistema de autenticación flexible, escalable y
seguro.
11
CAPÍTULO II
MARCO TEÓRICO
ANTECEDENTES DEL ESTUDIO
Cuando se desarrollan sistemas por separado y cada uno tiene su propio
sistema de autenticación ocasiona que los usuarios posean una
credencial de autenticación diferente para cada aplicación.
A continuación, se presentan estudios previos donde se utilizan Sistemas
Centralizados de Autenticación.
(Lozano, 2013) En su proyecto “SISTEMA CENTRALIZADO DE
AUTENTICACIÓN DE USUARIOS PARA LA SUBDIRECCIÓN DE
SEGURIDAD DE LA INFORMACIÓN UNAM-CERT” llega a la conclusión
que su proyecto fue enfocado principalmente a cambiar el esquema de
autenticación de usuarios que utilizan las aplicaciones dentro la
organización, llegando a sustituir satisfactoriamente el anterior sistema de
autenticación y consigue depender únicamente de su sistema, pensando
en nuevos proyectos que a futuro pueden ser integrados, además que
destaca la ejecución de una adecuada política para la creación de
contraseñas.
(Cano, 2014) En el proyecto “IMPLEMENTACIÓN DEL SISTEMA
CENTRALIZADO DE AUTENTICACIÓN Y AUTORIZACIÓN PARA LAS
12
APLICACIONES WEB DEL CENTRO DE CÁLCULO E INVESTIGACIÓN
DE LA FACULTAD DE INGENIERÍA DE LA UNIVERSIDAD DE SAN
CARLOS DE GUATEMALA” afirma que al poseer un Sistema
Centralizado de Autenticación para las aplicaciones web en una
organización, se tendrá un gran beneficio para el personal de desarrollo,
ya que se enfocarán solamente en los requerimientos de la organización,
y no se necesitará crear nuevos sistemas para autenticar cada aplicación
que se desarrolle, logrando ocupar ese tiempo en mejorar la calidad de
los aplicativos o emplearlo en nuevos desarrollos.
En el proyecto de (Marrero, 2014) denominado “SISTEMA
CENTRALIZADO DE GESTIÓN DE USUARIOS PARA INNOVA 7”
comenta que una ventaja de utilizar un sistema único de autenticación es
evitar que las personas tengan un usuario y contraseña diferente para
cada aplicativo, disminuyendo el tiempo que pasan autenticándose en
cada sistema.
En su proyecto “IMPLEMENTACIÓN DE UN SISTEMA PROVEEDOR DE
IDENTIDAD PARA OFRECER SERVICIOS DE AUTENTICACIÓN
MEDIANTE INICIO DE SESIÓN ÚNICO EN UNA UNIVERSIDAD DE
TAMAÑO GRANDE” (Restrepo, 2015) afirma que al centralizar la
autenticación mejora la usabilidad que tienen los usuarios con las
aplicaciones, además permitirá a los administradores mejorar el
13
mantenimiento y seguridad de las aplicaciones así como la seguridad de
las mismas, evitará que los desarrolladores creen un sistema de
autenticación en cada aplicación.
(Alvarado, 2015) En su proyecto “MIDDLEWARE PARA UN SISTEMA DE
GESTIÓN DE IDENTIDAD EN TELEFÓNICA CHILE” afirma que al poseer
un sistema centralizado de autenticación se concentran las cuentas de
usuarios en un único punto, eliminando así la dificultad de manejar las
cuentas de forma distribuida logrando gestionarlas con mayor facilidad.
FUNDAMENTACIÓN TEÓRICA
La autenticación y autorización de los usuarios en los aplicativos web en
una organización es de suma importancia para mantener segura e integra
la información, a medida que se crean nuevos servicios web es incómodo
para el usuario final tener que autenticarse en cada uno, llegando a
instancias en las que se tiene configurada las mismas contraseñas para
todos los aplicativos, también pueden haber casos en los que se tiene
contraseñas fáciles de recordar pero consideradas inseguras, también las
credenciales pueden quedar expuestas ya que por tratar de no olvidarlas
hay quienes tienen anotaciones en objetos o lugares que pueden ser
accedidos por terceros.
En el presente proyecto se realizará la implementación de un prototipo de
Sistema Centralizado de Autenticación, con el que se busca demostrar
14
que se puede tener un punto único de autenticación para tener acceso a
las aplicaciones web de la UG.
Autenticación
La autenticación es el proceso que un usuario debe seguir para tener
acceso a los recursos de un sistema o de una red de computadoras.
Generalmente, para poder acceder se requiere de un nombre de usuario y
contraseña llegando a un procedimiento de autenticación para certificar
que el usuario es quien dice ser, en el gráfico 1 se puede observar el
proceso antes descrito. (Sánchez, 2011)
Gráfico 1 Descripción Gráfica Del Procedimiento De Autenticación
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Modelos de autenticación
(Holguín, 2012) Existen dos modelos de autenticación:
Autenticación descentralizada.
Autenticación centralizada.
15
Autenticación descentralizada
Según (Holguín, 2012) la autenticación descentralizada consiste en tener
diferentes servicios en red y cada uno controla sus claves por separado,
como ejemplo pueden ser los usuarios de Oracle, de un firewall o los
administradores de un sitio web, las claves de estas aplicaciones no son
compartidas y son manejas por separado.
Autenticación Centralizada
(Holguín, 2012) se refiere como autenticación centralizada el tener a los
usuarios con sus contraseñas en un repositorio central, y las aplicaciones
que se manejen se las configure para autenticarlas con dicho repositorio.
Autorización
Consiste en dar permisos a un usuario o sistema para acceder a una serie
de recursos (por lo cual el usuario o sistema tendrían que haberse
autenticado previamente). La autorización también se da a conocer como
el perfil de usuario; el cual indica el nivel o grado de acceso que tiene la
persona o el sistema interventor. (Sánchez, 2011)
En el gráfico 2 podemos observar que, para llegar a un punto de
autorización, un sistema primero se autentica para poder tener un perfil o
rol específico.
16
Gráfico 2 Descripción Gráfica Del Procedimiento De Autorización
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
No todos tienen el mismo nivel de acceso, aquellos que juegan un papel
de administrador sobre el sistema o dan mantenimiento tienen un perfil
establecido, al cual se lo conoce como súper usuario o cuenta de
administrador. Por otro lado, está el usuario genérico el cual no posee
ciertos privilegios dentro del sistema, a pesar de estar autenticado.
Entonces, podemos ver que cada rol de un usuario tiene un nivel de
autorización determinada, para llevar a cabo tareas específicas dentro del
sistema. (Sánchez, 2011)
Single Sign-On
SSO siglas que significan Single Sign-ON y en español Inicio de Sesión
Único, es una característica que algunos sistemas de autenticación
poseen y que permite que los usuarios obtener la respectiva autorización
para acceder a varias aplicaciones según su perfil, esto ingresando sus
credenciales una única vez en el proceso de autenticación. (Gonzáles,
2010)
17
Protocolos y estándares
Para la gestión del proceso de autenticación el sistema a implementar
hará uso de algún protocolo que funcione en la web, a continuación, se
describen los principales y más importantes protocolos de autenticación y
autorización que en la actualidad se utilizan en internet.
OpenID
Es un estándar de identificación digital que permite utilizar una cuenta
existente para iniciar sesión en varias aplicaciones web sin necesidad de
crear nuevas contraseñas.
OpenID fue creado por una comunidad de código abierto, no es propiedad
de nadie, cualquier persona puede optar por utilizarlo o convertirse en un
proveedor de esta herramienta de forma gratuita sin tener que registrarse
o ser aprobado por alguna organización. (OpenID, 2017).
OpenID es un protocolo de autenticación federada2 que consiste
básicamente en que el usuario selecciona un servidor externo (proveedor
de OpenID) quien va hacer que valide su identidad en un sistema
determinado (consumidor de OpenID). Con el uso de un proveedor de
OpenID, el usuario deberá recordar solo una contraseña con su
identificador OpenID para poder autenticarse en todos los servicios que
hagan uso de este protocolo de autenticación. (Sánchez, 2011)
Existen varios proveedores de OpenID en internet como lo son: Flickr,
Yahoo, Google, entre otros; además existen myOpenID que realiza el
2 La autenticación federada consiste otorgar a una entidad en la que se confíe la tarea de guardar y obtener los datos de los usuarios para su autenticación.
18
servicio de OpenID dedicado, dejando al usuario con la opción de
implementar su propio proveedor de OpenID. (Sánchez, 2011)
En un estudio realizado por (Sánchez, 2011) OpenID presenta los
problemas que son detallados a continuación:
Es complejo ya que no se implementa fácilmente.
Problemas de seguridad debido a que es vulnerable al Phishing3.
Problemas de privacidad al almacenar demasiada información del
usuario en los proveedores OpenID.
Problemas de confianza debido a que OpenID ofrece para
diferentes servidores un solo sistema de autenticación, pero no
garantiza que la identidad del usuario sea real.
OAuth
OAuth es un protocolo de autorización, que concede permisos a un
tercero para acceder a los recursos propios. El objetivo de este protocolo
es que un usuario que posee determinados recursos en un servidor
(proveedor de OAuth) pueda dar acceso a un tercero (el consumidor,
usualmente un sitio web), sin necesidad de que ese tercero conozca su
usuario y contraseña, evitando así el control total de la cuenta. (Sánchez,
2011)
(Lozano, 2013) Para realizar la autenticación y establecer permisos al
contenido protegido por un usuario, se necesitan de tres partes, un
3 El Phishing es una técnica de ingeniería social utilizada por los ciberdelincuentes para engañar y obtener datos información delicada de los usuarios.
19
proveedor de servicios, un consumidor y un usuario. A continuación, se
describe cada uno:
Proveedor de servicios: Sitios web que posee información de un
usuario que tiene restringido el acceso. Por ejemplo, Google,
Facebook o Twitter, estos proveedores ofrecen al desarrollador una
API que soporta OAuth.
Usuario o propietario: Es el propietario del recurso que intenta
acceder, por lo cual es necesario que realice un inicio de sesión
con un proveedor de servicio y se ejecute OAuth.
Cliente o consumidor: Puede ser un sitio o aplicación web, móvil
o de escritorio que para acceder a la información restringida que
guarda un proveedor de servicios. Únicamente el usuario o
propietario del recurso puede autorizar o denegar al consumidor.
(Lozano, 2013) OAuth ha desarrollado mejoras sobre los modelos de
autenticación, entre estos se puede mencionar:
El usuario no tendrá que teclear sus credenciales en cada solicitud
de autenticación, trabajo con el uso tokens4 para no compartir
ninguna contraseña del usuario.
Se emitirá los tokens del sitio proveedor, se desarrollan
mecanismos en que los tokens expiran, solicitando a las
aplicaciones que renueven el token de acceso periódicamente para
4 Cadena de caracteres que contiene un cierto significado coherente de un lenguaje de programación.
20
que accedan a los datos de los usuarios cuando realicen las
peticiones.
(Sánchez, 2011) Las siguientes son críticas que se han realizado a este
protocolo:
Protocolo orientado especialmente a ser utilizado en navegadores
web, su uso en otra clase de aplicaciones es problemático.
Es complejo al existir diversas implementaciones y librerías que
tienen poca robustez y poca documentación.
Se han detectado problemas en la seguridad para este protocolo.
OAuth 2.0
OAuth 2.0 es un protocolo de autorización que permite a los clientes el
acceso a contenidos de un usuario sin conocer o manejar los datos de
autenticación del usuario. Este protocolo proporciona autorización para
aplicaciones web, de escritorio y dispositivos móviles. Por lo que se puede
decir que este protocolo se basa en la autorización para estas
aplicaciones. (Parecki, 2017)
Para llevar a cabo su funcionamiento, OAuth 2.0 define cuatro Roles que
se describen a continuación:
Propietario de recursos: Es la entidad capaz de conceder acceso
a un recurso que se mantiene protegido, si es una persona es
considerada como el usuario final.
21
Cliente: Es la aplicación que realiza peticiones de recursos
protegidos, con autorización y en nombre del propietario del
recurso.
Servidor de recursos: Es el servidor donde se mantiene alojados
los recursos protegidos, además acepta y responde a peticiones de
recursos protegidos usando tokens de acceso.
Servidor de autorización: Es el servidor que emite los tokens de
acceso al cliente después de autenticar de forma satisfactoria al
propietario del recurso para que obtenga la autorización.
En el gráfico 3 se puede observar cada uno de los roles en el
funcionamiento de OAuth 2.0.
Gráfico 3 Escenario de funcionamiento de OAuth 2.0
Fuente: (González, 2012)
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
22
OAuth 2.0 tiene la ventaja que soluciona problemas de confianza que se
tiene entre aplicaciones de terceros y los usuarios, además permite que
un proveedor de servicios o API facilitar a las aplicaciones de terceros que
expandan sus servicios y utilicen los datos de sus usuarios de forma
segura, otorgando al usuario la decisión permitir el acceso a sus datos o
la aplicación realice tareas en su nombre, pero esto sin compartirle las
credenciales de autenticación de dicho sistema. (González, 2012)
Se puede asegurar que el protocolo OpenID es la capa de identidad que
funciona sobre el protocolo base OAuth2. Existe una principal diferencia
entre estos dos protocolos y es que OpenID proporciona la misma
autenticación para varios sitios, en cambio OAuth2 autoriza que un sitio
consuma servicios o información de otro. (Marrero, 2014)
OpenID OAuth Hybrid Protocol
Este protocolo híbrido combina los sistemas OpenID y OAuth, estos
protocolos combinados tienen objetivos distintos pero complementarios,
uno realiza la autenticación federada del usuario y el otro la autorización.
Con esta combinación el usuario haciendo uso de su proveedor de
OpenID podrá autenticarse con un servidor externo, inmediatamente se
autorizará a que el servidor externo acceda a determinados recursos del
proveedor. Si no se usara este protocolo el usuario deberá realizar dos
procesos; primero la autenticación y luego la autorización. (Sánchez,
2011)
23
Proveedores como Google, MySpace y Yahoo! Han adoptado este
protocolo.
Facebook Connect
En el 2008 debido al aumento del número de sus usuarios la compañía
Facebook lanzó su propio sistema con el nombre de Facebook Connect.
Con este lanzamiento Facebook optó por querer posicionarse en internet
como un repositorio central de identidad, además de ofrecerse como
proveedor de servicio de autenticación y autorización.
Facebook Connect parece haber sido abandonado por Facebook
actualmente, adoptando el protocolo OAuth 2.0 como protocolo de
autorización, utilizándolo para integrar en páginas externas los servicios
de la red social. (Sánchez, 2011)
OpenID Connect
OpenID Connect es un protocolo de autenticación interoperable que es
basado en especificaciones del protocolo OAuth 2.0. Este protocolo
permite a los desarrolladores autenticar a los usuarios a través de sitios
web y aplicaciones sin poseer o administrar archivos de contraseñas.
Funciona bajo la respuesta verificable y segura de la pregunta ¿Cuál es la
identidad de la persona que está utilizando el navegador actualmente o la
aplicación nativa que tiene conectada? (OpenID, 2017)
OpenID Connect permite a clientes de todo tipo, incluyendo JavaScript5
basado en navegador y aplicaciones móviles nativas, lanzar flujos de
5 Lenguaje de programación utilizado para crear páginas web dinámicas.
24
inicio de sesión y recibir validaciones de identidad de usuarios
conectados.
(Identidad, Autenticación) + OAuth 2.0 = OpenID Connect
Permite a los desarrolladores de aplicaciones y sitios autenticar a los
usuarios sin asumir la responsabilidad de almacenar y administrar
contraseñas, debido a que en internet hay muchas personas que intentan
comprometer las cuentas de los usuarios para su propia
ganancia.(OpenID, 2017)
OAuth 2.0 fue publicado en el año del 2012 fue diseñado para ayudar en
el proceso de autenticación y protocolos de autorización, además que
proporciona una serie de flujos de mensaje que son estandarizados y
están basados en JSON6 y HTTP7; con estas especificaciones lo utiliza
OpenID Connect para brindar los servicios de identidad. (OpenID, 2017)
Existen algunas compañías que hacen uso de OpenID Connect, entre las
más importantes se puede mencionar a Microsoft y Yahoo!, además para
ver un ejemplo real de funcionamiento de este protocolo se pude ingresar
al inicio de sesión de Google+, cuya oferta de identidad está basado
totalmente en OpenID Connect. (OpenID, 2017)
OpenID Connect es comparado con SAML (Security Assertion Markup
Languaje) pero el funcionamiento de cada uno lo veremos así, el estándar
6 JSON abreviatura de Java Script Object Notation, es un formato de texto ligero que se utiliza en programación para el intercambio de datos. 7 HTTP abreviatura de Hypertext Transfer Protocol, es un protocolo de comunicación que se utiliza para transferir información en la Word Wide Web.
25
SAML es una tecnología de federación que está basada en XML8
diseñada para soportar solo aplicaciones basada en la web, por el
contrario, OpenID Connect es un protocolo basado en JSON/REST9
diseñado para aplicaciones nativas, aplicaciones móviles y web. (OpenID,
2017)
API
Application Programming Interface conocido como API y en su traducción
al español como Interfaz de Programación de Aplicaciones, son reglas y
especificaciones que siguen las aplicaciones para comunicarse entre
ellas, su estructura es funcionar como interfaz entre aplicaciones
diferentes de la misma forma que la interfaz de usuario ayuda en la
interacción entre el humano y el software. (Merino, 2014)
API de Microsoft Office 365
La API de Microsoft Office 365 permite proporcionar a sus clientes el
acceso a sus datos de Microsoft, incluyendo correos electrónicos,
calendarios, contactos, archivos, carpetas, usuarios y grupos, todo esto
desde su propia aplicación. (Microsoft, 2017)
Se puede hacer uso y acceder a las API de Office 365 desde aplicaciones
creadas en diferentes plataformas como móviles, web y de escritorio. No
importa la plataforma de desarrollo o la herramienta que se utilice, ya que
se puede crear aplicaciones web utilizando Php, .Net, Java, Python o
8 XML abreviatura de eXtensible Markup Languaje, es un metalenguaje o lenguaje que se utiliza para decir algo acerca de otro, permite organizar y etiquetar documentos. 9 REST abreviaturas de Representational State Transfer, es una técnica de arquitectura de software utilizado para la transferencia de representación de estado de una aplicación.
26
Ruby on Rails, también se pueden utilizar aplicaciones Windows Universal
Apps, iOS, Android o en otra plataforma de dispositivos a su
elección.(Microsoft, 2017)
El sistema Centralizado de Autenticación a implementar hará uso del API
de Microsoft office 365 para acceder a los datos de los usuarios y validar
su autenticación utilizando su correo institucional y la respectiva
contraseña.
Para controlar la comunicación entre las APIs de las aplicaciones,
permitiendo el paso de datos, se pude hacer uso de algún método como
los tickets, tokens, entre otros. (Marrero, 2014)
A continuación, se describe el esquema planteado:
Se tendrá una capa de autenticación la cual enviará las credenciales al
servidor de autenticación, este retornará un token para el usuario, se
utilizará el API de comunicación que en todo momento tendrá la
información de los tokens que se genera y esto será utilizado para la
comunicación entre los distintos aplicativos. (Marrero, 2014)
Requerimientos para la elección de la solución
Para dar solución a la problemática planteada se propone la
implementación de un sistema centralizado de autenticación con las
siguientes características:
Debe ser reutilizable, pensado a futuro para que se pueda
modificar y volver a reutilizar el código en cada una de sus capas.
27
Multiplataforma, para que se pueda integrar con diferentes tipos de
lenguajes para varias aplicaciones.
Tener una configuración sencilla.
Desarrollado en un lenguaje de programación popular.
El sistema debe ser liviano.
Debe contar con suficiente y buena documentación.
Característica de Inicio de Sesión Único (SSO) para facilitar el
acceso de los usuarios hacia las aplicaciones.
Tiene que ser escalable en el que se pueda integrar aplicaciones
web a futuro y así funcionar a largo plazo para ser el sistema de
autenticación de las aplicaciones web de la Universidad de
Guayaquil.
Debe ser software libre, debido a que la UG es una entidad pública,
las herramientas informáticas que utilicen deben ser de libre
distribución, que se puedan modificar dentro de los parámetros que
estén soportados por su licencia, particularmente que se pueda
adaptar a los requerimientos de la institución.
Que se pueda integrar con Office 365 mediante el uso del API y
mediante este autenticar a los usuarios, este sistema propuesto
debe tener la característica de poder utilizar unos de los
estándares abiertos que anteriormente se describieron.
28
Opciones candidatas
A continuación, se describe algunos sistemas que pueden ofrecen el
servicio de autenticación centralizada, entre ellos se elegirá uno para
utilizarla en este proyecto, debe cumplir con los requerimientos antes
definidos.
Cas
Conocido como Servicio de Autenticación Centralizada, proporciona una
comunidad de código abierta que apoya y contribuye al proyecto,
proporciona un servicio de inicio de sesión única para la web, está bien
documentado, es un componente de servidor de Java de código abierto,
soporte para los protocolos como los son (CAS, SAML, OAuth, OpenID).
Este sistema utiliza una biblioteca de clientes para Java, .Net, Php, Perl,
Apache, uPortal y otros. (Apereo, 2017)
(Ulpgc, 2017)Entre las ventajas que posee están las siguientes:
Facilidad de instalación y uso.
Amplia comunidad.
Posee una buena librería PhpCas que permite integrar con
aplicaciones Php.
Utilizada por universidades como ULL, Berkeley y Yale.
Las desventajas que posee son las siguientes:
Desarrollada en Java
Configuración vía XML
29
(Ulpgc, 2017) Su funcionamiento sigue el siguiente patrón:
Primer paso para la autenticación:
El servidor requerirá un usuario con su respectiva contraseña.
Si el proceso es el correcto se le enviará un ticket al cliente.
El ticket es transparente y no contendrá información del usuario.
Este primer paso de autenticación está representado en el gráfico 4.
Gráfico 4 Primer paso para la autenticación con el CAS
Fuente: (Ulpgc, 2017)
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Acceso a un aplicativo protegido:
La aplicación re-direcciona al navegador al servidor CAS.
El navegador presenta el ticket que se le otorgó anteriormente.
El servidor Cas envía a la aplicación un ticket de servicio.
30
El servidor Cas redirige el navegador a la aplicación
La aplicación validará el ticket de servicio con el servidor Cas.
El navegador tendrá acceso por parte de la aplicación.
En el gráfico 5 se representa los pasos para acceder a un aplicativo
protegido.
Gráfico 5 Acceso a un aplicativo protegido con el CAS
Fuente: (Ulpgc, 2017)
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Shibboleth
Es un sistema de código abierto basado en estándares que tiene la
funcionalidad de autenticar a los usuarios ofreciendo el servicio de Inicio
de sesión único SSO para aplicaciones web, su autenticación se basa en
31
la identidad federada e infraestructura utilizando el protocolo
SAML.(Shibboleth, 2017)
(Shibboleth, 2017) Este sistema posee las siguientes características:
Es compatible con sistemas como KERBEROS10, LDAP11 entre
otros.
Es escalable, tanto en el rendimiento como capacidad para
gestionar.
Puede tener alta disponibilidad.
Puede funcionar con implementaciones que son compatibles con
SAML 1.1 Y 2.0.
Puede soportar el protocolo CAS 2 SSO, así como extensiones
adicionales.
Hace uso de Apis extensas y administradas de forma cuidadosa
para que el sistema se expanda permitiendo la personalización de
escenarios.
(Díaz, Cohn y Rios, 2015)En un sistema Shibboleth que realiza el servicio
de autenticación se puede identificar tres elementos:
Proveedor de Identidad (ldP): Pone a disposición los servicios
SSO, que cuando la autenticación es correcta envía al proveedor
de servicio la información necesaria del usuario.
10 Kerberos es un protocolo de seguridad utilizado para la autenticación de usuarios. 11 LDAP abreviaturas de Lightweight Directory Access Protocol, es un conjunto de protocolos que se utilizan para acceder a información guardada a través de la red.
32
Proveedor de Servicio (SP): Su función permita la integración de
los recursos al sistema SSO que lo dispone el proveedor de
Identidad.
Servicio de Descubrimiento (DS): Este servicio permitirá al
usuario que elija el proveedor de identidad que utilizará para el
inicio de sesión sobre un proveedor de Servicios.
Cuando el usuario, haciendo uso de un navegador, intenta acceder a una
aplicación protegida, el SP re-direcciona al usuario al DS para que
seleccione el nombre de la organización a la que pertenece, el navegador
redirige nuevamente al usuario al ldP de la organización para que realice
la autenticación, si la autenticación es exitosa el ldP enviará al SP la
información necesaria con la identidad del usuario, esto para permitirle
verificar al sistema el grado de autorización del usuario y validar el
acceso. En la siguiente figura se pude observar el flujo que se realiza para
la autenticación del usuario con el SP. (Díaz, Cohn y Rios, 2015)
En el gráfico 6 se observa el proceso de login con el sistema Shibboleth.
33
Gráfico 6 Grafico Proceso de login de Shibboleth
Fuente: (Díaz, Cohn y Rios, 2015)
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Enterprise Sign On Engine
Enterprise Sign On Engine (ESOE) un sistema de código abierto que tiene
las funcionalidades de inicio de sesión único, control de acceso y
federación, se construye y es mantenido por la universidad tecnológica de
Queensland, se abre la fuente para fomentar el desarrollo continuo de la
comunidad, se hizo disponible bajo la licencia de código de Apache 2.0,
es un sistema desarrollado en Java. (Wikiwand, 2017)
Ha sido construido utilizando estándares de código abierto de OASIS12
como SAML y XACML13, lo que permite integrarse con otros proveedores
12 Es la Organización para el Avance de Estándares de información Estructurada. 13 XACML abreviaturas de eXtensible Access Control Markup Languaje, es un lenguaje basado en XML, fue diseñado para políticas de seguridad y derecho para el acceso a la información.
34
que apoyan estos estándares. Permite integrarse con sistemas que
almacenan usuarios como lo son LDAP y Active Directory de Microsoft.
(Lang y Lang, 2009)
Como el espacio de identidad esta siempre cambiando, ESOE tiene futuro
probado con una capacidad de traducir tokens en diferentes formatos, es
decir que ESOE puede soportar identidades de fuentes remotas tales
como las proporcionadas por OpenID. Si un tipo de token nuevo o
específico llega, ESOE se puede expandir rápidamente para
aprovecharlo. (Lang y Lang, 2009)
En el gráfico 7 se representa el esquema de conectividad que puede tener
ESO con diferentes tipos de integraciones.
Gráfico 7 Esquema de conectividad con Enterprise Sign On Engine
Fuente: (Lang y Lang, 2009)
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
35
IdentityServer4
IdentityServer es una estructura de OpenID Connect y OAuth 2.0 para
ASP.NET Core14, está certificado oficialmente por la Fundación OpenID y
forma parte de la Fundación .NET.(Allen y Baier, 2017)
IdentityServer permite implementar un inicio de sesión único y el control
de acceso para aplicaciones web y API modernas usando protocolos
como OpenID Connect y OAuth2, es gratuito y además tiene soporte
comercial en caso de requerirlo. Este sistema puede ser integrado con
aplicaciones web, apps móviles y con aplicaciones de escritorio. Hay
suficiente documentación en la web para que sean estudiadas. (Allen y
Baier, 2017)
Cada día los usuarios y recursos crecen. El IdentityServer4 será el
encargado de facilitar la tarea de la gestión de credenciales. Gracias a
este servidor, con una única identificación, el usuario puede acceder a
todos los recursos a los que se le ha permitido el acceso de manera
segura. El IdentityServer4 tendrá la función de identificar a ese usuario y
de gestionar a qué recursos puede acceder. (Chakray, 2017)
(Allen y Baier, 2017) IdentityServer4 permite las siguientes funciones en
sus aplicaciones:
Autenticación como servicio: Lógica de inicio de sesión
centralizada y flujo de trabajo para todas sus aplicaciones como
web, de escritorio, móviles y de servicios.
14 ASP.NET Core es una plataforma para compilar aplicaciones web basadas en servidores, permite usar lenguajes de programación como Visual Basic y C#.
36
SSO: Inicio de sesión y salida única sobre múltiples tipos de
aplicaciones.
Control de acceso para API: Emite tokens de acceso para APIs a
varios tipos de clientes, por ejemplo, servidor a servidor,
aplicaciones web, aplicaciones de escritorio y aplicaciones móviles.
Es un Gateway Federado: Soporta proveedores de identidad
externos como Google, Facebook, Azure Active Directory. Es un
Gateway federado porque proteger a las aplicaciones clientes de
los detalles de cómo conectarse con estos proveedores de
identidad externos.
Hecho en código abierto: Utiliza licencia permisiva de Apache 2
permitiendo la construcción de productos comerciales encima de él.
También forma parte de la Fundación .Net brindando respaldo legal
y de gobierno.
Enfoque en la personalización: Muchos aspectos de
IdentityServer se pueden personalizar para adaptarse a sus
necesidades. Dado que IdentityServer4 es un framework15, se
puede reescribir su código para adaptar el sistema de la forma que
tenga sentido para sus escenarios.
15 Marco de trabajo con varias herramientas que sirve para el desarrollo de aplicaciones.
37
IdentityServer es un proveedor de OpenID Connect, implementando
OAuth 2.0, en diferentes publicaciones se utilizan diferentes términos para
el mismo rol como servicio de tokens de seguridad, proveedor de
identidad, servidor de autorización entre otras, pero en resumen es un
software que emite tokens de seguridad a los clientes. (Allen y Baier,
2017)
IdentityServer tiene una serie de roles, incluyendo:
Protección de los recursos.
Autentica a los usuarios utilizando un almacén de cuenta local o a
través de un proveedor de identidad externo.
Proporciona un inicio de sesión único.
Gestiona y autentica clientes.
Publica fichas de identidad y acceso a clientes
Valida las fichas
A continuación, se detalla cómo es el funcionamiento de cada una de las
partes que intervienen en la estructura de IdentityServer.
Usuario: Un usuario es una persona que utiliza un cliente
registrado para acceder a los recursos.
Cliente: Un cliente es una pieza de software que solicita tokens de
IdentityServer, ya sea para autenticar un usuario (es decir solicitar
un token de identidad) o para acceder a un recurso (solicitando un
token de acceso). Un cliente debe primero registrarse con
38
IdentityServer para poder solicitar tokens. Los clientes son
aplicaciones web, aplicaciones móviles o de escritorio, entre otras.
Recursos: Los recursos es lo que se desea proteger con
IdentityServer: los datos de identidad de sus usuarios (por ejemplo,
nombre o dirección de correo electrónico) o los recursos de las
APIs. Cada recurso tiene un nombre único y los clientes utilizan
este nombre para especificar a qué recursos desea acceder.
Token de identidad: Un token de identidad representa el resultado
de un proceso de autenticación, contiene un identificador para el
usuario e información sobre cómo y cuándo el usuario se autenticó.
Puede contener datos de identidad adicionales.
Token de acceso: Un token de acceso permite el acceso a un
recurso API. Los clientes solicitan token de acceso y los envían a
las API. Los tokens de acceso contienen información sobre el
cliente y el usuario (si está presente). Las API utilizan esa
información para autorizar el acceso a sus datos. (Allen y Baier,
2017)
En el gráfico 8 se representan las partes que intervienen en una
infraestructura en la que IdentityServer4 protege a uno o varios recursos y
la forma como un usuario intenta acceder a dichos recursos. En primer
lugar el usuario intenta acceder haciendo uso de un cliente que será
redirigido al IdentityServer el cual autenticará y autorizará al usuario
39
emitiendole los respectivos tokens de acceso con la respectiva identidad,
comunicandolo con los recursos protegidos o con las Apis si es el caso.
Gráfico 8 Uso de IdentityServer
Fuente: (Allen y Baier, 2017)
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Puntuación de las opciones candidatas
En el cuadro 4 se puntuará cada uno de los requerimientos que se solicita
para la elección de uno de los sistemas analizados, por cada
requerimiento que cumpla se le dará un punto al sistema. Se elegirá al
sistema que cumpla con la mayoría de requerimientos es decir que tenga
mayor puntaje entre las opciones comparadas.
40
CUADRO N° 4 PUNTUACIÓN DE LAS OPCIONES CANDIDATAS
Alternativa \
Requerimieto Cas Shibboleth Enterprise Sign
On Engine Identity Server 4
Reutilizable 1 0 0 1
Multiplataforma 0 0 0 1
Configuración Sencilla
1 1 1 1
Desarrollado en un lenguaje de programación popular
1 1 1 1
Liviano 1 1 1 1
Buena documentación
1 1 0 1
Single Sign On 1 1 1 1
Escalable 1 1 1 1
Software libre 1 1 1 1
Utiliza uno de los protocolos antes descritos
1 0 0 1
Total 9 7
6 10
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
De las sistemas analizados y comparados el que cumple con la mayoría
de los requerimientos llegando a tener un mayor puntaje es
IdentityServer4, por esta razón es el sistema elegido y que se utilizará
para que funcione como Sistema Centralizado de Autenticación para los
usuarios de las Aplicaciones web de la Universidad de Guayaquil.
41
Sistema elegido para la implementación
IdentityServer4 es el sistema que cumple con todos los requerimientos
solicitados, al ser desarrollado en .Net tiene la facilidad de poder
integrarse con la plataforma Microsoft Office 365 haciendo uso de su API
por ser compatible con los sistemas de Microsoft, además tiene la
particularidad que se pueden integrar aplicaciones web, móviles y de
escritorio pensando a futuro para que otras personas opten por la
integración de estas aplicaciones de diferentes aplicaciones con el
sistema de este proyecto.
Descripción de Identity Server
Según se añada usuarios y servicios, la gestión de identidades se vuelve
más compleja. Por ello, un IdentityServer debe de ser el núcleo de
cualquier infraestructura para el control de accesos y de identidades. Para
una gestión de identidades eficiente y segura, todos nuestros recursos IT
deberían de acudir a nuestro Identity Server para comprobar y autentificar
el acceso de los usuarios. (Chakray, 2017)
Panorama de las aplicaciones
(Allen y Baier, 2017) En el Gráfico 9 podemos observar las interacciones
de las aplicaciones.
Los navegadores se comunican con las aplicaciones web.
Las aplicaciones se comunican con las aplicaciones de la web por
cuenta propia o en nombre de un usuario.
42
Las aplicaciones basadas en navegador se comunican con las API
web.
Las aplicaciones nativas se comunican con las API de la web.
Las aplicaciones de servidor se comunican con las API web.
Las API de la web se comunican con otras API de la web por
cuenta propia o en nombre de un usuario.
Normalmente, cada capa (front-end, middle-end16 y back-end17) tiene
que proteger los recursos e implementar autenticación y autorización,
a menudo contra el mismo almacenamiento de usuarios. Externalizar
estas funciones fundamentales de seguridad a un servicio de token
evita duplicar esa funcionalidad en esas aplicaciones y puntos finales.
Reestructurar las aplicaciones para admitir un servicio de token de
seguridad conlleva a tener la siguiente arquitectura con los siguientes
protocolos. (Allen y Baier, 2017)
16 Parte del software que gestiona y hace valer las reglas y lógica del negocio, hace peticiones a las bases de datos. 17 Parte del software que se encuentra del lado del servidor que interactúa con la base de datos.
43
Gráfico 9 Panorama de las aplicaciones
Fuente: (Allen y Baier, 2017)
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
(Allen y Baier, 2017) Este diseño divide las preocupaciones de seguridad
en dos partes:
Autenticación: La autenticación es necesaria cuando una
aplicación necesita conocer la identidad del usuario, para
asegurarse de que este usuario sólo pueda acceder a los datos
que se le permite. Los protocolos de autenticación más comunes
son SAML, WS-Federation18 y OpenID Connect.
18 WS-Federation es una colección de dominios que han establecido relaciones para poder compartir recursos de manera segura, utiliza el intercambio de token de seguridad en servicios web.
44
OpenID Connect es el protocolo de autenticación más reciente,
pero se considera que es el futuro porque tiene el mayor potencial
para las aplicaciones modernas. Está diseñado para ser una API
amigable.
Acceso a la API: Las aplicaciones tienen dos formas
fundamentales con las que se comunican las APIS, ya sea
utilizando la identidad de la aplicación o delegar la identidad del
usuario, en algunos casos se combinan los dos métodos.
El protocolo OAuth 2.0 permite a las aplicaciones solicitar tokens
de acceso desde un servicio de tokens de seguridad y utilizarlos
para comunicarse con las API. Esto reduce la complejidad en las
aplicaciones cliente como en las API, ya que la autenticación y la
autorización puede centralizarse.(Allen y Baier, 2017)
OpenID Connect y OAuth2 en IdentityServer4
Ambos protocolos son muy similares, de hecho, OpenID Connect es una
extensión superior de OAuth 2.0. Las dos juntas son fundamentales para
la seguridad de los aplicativos y el acceso a la información. La
autenticación y el acceso a la API se combinan en un único protocolo, con
un solo viaje de ida y vuelta al servicio de tokens de seguridad. (Allen y
Baier, 2017)
IdentityServer4 es una implementación de estos dos protocolos y está
altamente optimizado para resolver problemas de seguridad de las
45
aplicaciones de escritorio, móviles y web actuales. Es un gran enfoque
para asegurar las aplicaciones actuales y futuras previsibles.
¿Cómo puede ayudar IdentityServer4?
IdentityServer es un middleware19 que añade los extremos compatibles
con OpenID y OAuth2.0 a una aplicación ASP.NET Core.(Allen y Baier,
2017)
Normalmente se construye una aplicación con inicio de sesión y cierre de
sesión, el middleware IdentityServer añade las cabeceras de protocolo
necesarias para que las aplicaciones clientes puedan hablar, utilizando
los protocolos estándar.
En el gráfico 10 se representa a una aplicación construida con inicio y
cierre de sesión, con el funcionamiento del middleware de IdentityServer4
se añadirán las cabeceras necesarias para la comunicación con la
aplicación y se emitirán los tokens y la autorización necesaria para
descubrir el acceso al aplicativo.
19 Middleware es la lógica de intercambio de información entre aplicaciones, es decir un software o componentes que sirven para integrar aplicaciones.
46
Gráfico 10 Representación Gráfica del Middleware
Fuente: (Allen y Baier, 2017)
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Análisis de Aplicaciones web
La universidad de Guayaquil cuenta con dos aplicaciones web en la
actualidad, las que realizaremos un análisis de su estructura y
funcionamiento.
Sistema de gestión de proyectos
Esta aplicación cumple con la función de registrar proyectos que
requieran en la universidad y exponerla al público, es utilizada por
investigadores y docentes, está desarrollada en el Framework Laravel
utilizando el lenguaje de desarrollo Php, actualmente los usuarios se
47
registran en el sistema guardándose los usuarios en una base de datos
local e independiente y cuando realizan el proceso de autenticación el
sistema accede a esta base para comprobar la identidad de los usuarios,
para su puesta en marcha se lo ha instalado y está funcionando en un
servidor de pruebas en la nube llamado Amazon en el siguiente link.
http://ec2-54-149-21-181.us-west-2.compute.amazonaws.com/
Gráfico 11 Página de Sistema de gestión de proyectos
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Sistema Integrado de la Universidad de Guayaquil (SIUG)
Este sistema es un Front-end que interactúa con varias aplicaciones que
son utilizadas en el ámbito académico, financiero, talento humano y
consultas públicas.
48
En el ámbito académico es utilizado para registrar y consultar
calificaciones, en el podemos encontrar datos personales de los usuarios,
se puede realizar matriculaciones, evaluar docentes, acceder a la
biblioteca virtual de la universidad y con las que se tienen convenios
siendo de gran ayuda para que los usuarios realicen investigaciones,
tiene publicado temas de ayuda que son instructivos académicos en
general y otras opciones en las que solo tienen acceso los Docentes y
personal administrativo de la Universidad de Guayaquil.
Esta aplicación está desarrollada en Php usando el framework Laravel,
dispone de una base de datos local en la que se tienen registrados los
usuarios que forman parte de la Universidad de Guayaquil, esta base será
utilizada para validar al usuario en el proceso de autenticación haciendo
uso de su número de cédula y contraseña.
Este sistema se puede encontrar en la dirección web:
https://servicioenlinea.ug.edu.ec/SIUG/Default.aspx
49
Gráfico 12 Página SIUG
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Mecanismos para integrar aplicaciones clientes con Identity Server4
Para integrar las aplicaciones web con el Sistema Identity Server4 y así
tener un solo sistema de autenticación se deben definir los siguientes
mecanismos.
Mecanismos en Identity Server4
En el servidor Identity Server4 se deben definir las aplicaciones clientes
serán protegidas y también los servicios se pueden utilizar que también
50
están protegidos, además se especifica los servicio puede utilizar cada
aplicación, en este caso las aplicaciones clientes podrán usar el servicio
de autenticación.
En el archivo appsettings de Identity server se definen los siguientes
parámetros de los clientes que se conectarán:
client_id: Es el id de la aplicación cliente que se va a conectar.
client_secret: Es la contraseña de la aplicación cliente que se va a
conectar.
Mecanismos en las aplicaciones clientes
Las aplicaciones clientes deben enviar estos parámetros cuando realizan
el proceso de autenticación con Identity Server4.
El endpoint expuesto para la autenticación es url.com/Connect/Token
Mediante método Post la aplicación deberá enviar los siguientes
parámetros que es del tipo www/urlEncoded
Grant_type: Es el tipo de autorización que está pidiendo la
aplicación, en este caso el password.
Username: Es el nombre del Usuario.
Password: Es la contraseña del Usuario.
Client_id: Es el client_id de la aplicación cliente que se definió en
Identity Server4.
Client_secret: Es el client_secret de la aplicación cliente que se
definió en Identity Server4.
Scope: Son los servicios que estoy pidiendo autorización.
51
FUNDAMENTACIÓN SOCIAL
La identidad se está convirtiendo en la fuerza motriz de los nuevos
paradigmas de seguridad, por lo que los departamentos de TI deben
poner más énfasis en la autenticación es decir garantizar que los usuarios
son quienes dicen ser, teniendo en cuenta los factores fundamentales a la
hora de planificar sus estrategias de autenticación. (CATechnologies,
2014)
A medida que los usuarios y servicios aumentan, la gestión de
identidades se vuelve más compleja, para esto necesitamos contar con
una infraestructura más eficiente que nos permita el control absoluto de
las entidades que acceden a nuestra información.
Con un servidor de identidad, el usuario puede acceder a todos los
recursos a los que se le ha permitido el acceso de forma segura, con una
única identificación. Sin una gestión de identidades en bloque, el usuario
no podría acceder a diferentes recursos con un mismo acceso, sino que
tendría que insertar sus credenciales en cada uno de los servicios a los
que quiera acceder, volviéndose además tedioso memorizar una cantidad
de contraseñas complejas. (Chakray, 2017)
Este proyecto está orientado a brindar una solución a la UG y que los
administradores de las páginas web, puedan garantizar un mejor y
eficiente servicio, tanto al personal administrativo como al académico.
“Es esencial contar con un proceso de autenticación sencillo, pero seguro
que cuide la experiencia del usuario; esto puede ser un factor
52
diferenciador clave para impulsar la adopción de aplicaciones basadas en
la web orientadas al cliente”. (CATechnologies, 2014).
La implementación de este proyecto provee un gran aporte de seguridad,
al controlar todo desde un único punto de administración se minimiza la
probabilidad de errores, así como también la reducción de tiempo al
momento de gestionar usuarios.
“Una solución de autenticación flexible, eficaz y centralizada puede
contribuir a la reducción de costes de TI, desde la implementación inicial
hasta las tareas comunes de soporte y mantenimiento”. (CATechnologies,
2014).
FUNDAMENTACIÓN LEGAL
Constitución de la república de Ecuador (2008)
Título II Derechos Capítulo VI Derechos de la Libertad
Art. 66.- Se reconoce y garantizará a las personas:
19. El derecho a la protección de datos de carácter personal, que incluye
el acceso y la decisión sobre información y datos de este carácter, así
como su correspondiente protección. La recolección, archivo,
procesamiento, distribución o difusión de estos datos o información
requerían la autorización del titular o el mandato de la ley.
Título III Garantías Constitucionales Capítulo III Garantías
Jurisdiccionales Sección V Acción de Habeas Data
53
Art. 92.- Toda persona, por sus propios derechos o como representante
legitimado para el efecto, tendrá derecho a conocer de la existencia y a
acceder a los documentos, datos genéticos, bancos o archivos de datos
personales e informes que sobre sí mismo, o sobre sus bienes, consten
en entidades públicas o privadas, en soporte material o electrónico. Así
mismo, tendrá derecho a conocer el uso que se haga de ellos, su
finalidad, el origen y destino de información personal y el tiempo de
vigencia del archivo o banco de datos.
Ley orgánica de Protección de Datos-LOPD (1999)
Título I Disposiciones generales
Art. 1.- Objeto. La presente Ley Orgánica tiene por objeto garantizar y
proteger, en lo que concierne al tratamiento de los datos personales, las
libertades públicas y los derechos fundamentales de las personas físicas,
y especialmente de su honor e intimidad personal y familiar
Art. 3.- Definiciones. A los efectos de la presente Ley Orgánica se
entenderá por: “a) Datos de carácter personal: cualquier información
concerniente a personas físicas o identificables”
Ley orgánica de Gestión de la Identidad y Datos Civiles (2016)
Título I Generalidades, Capitulo Único Preceptos Fundamentales
Art. 1.- Objeto. La presente Ley tiene por objeto garantizar el derecho a la
identidad de las personas y normar y regular la gestión y el registro de los
hechos y actos relativos al estado civil de las personas y su identificación.
54
Ley de Comercio Electrónico, Firmas Electrónicas y Mensajes de
Datos
Capítulo I Principios Generales
Art. 9.- Protección de datos, inciso 1 y 2.- Para la elaboración,
transferencia o utilización de bases de datos, obtenidas directa o
indirectamente del uso o transmisión de mensajes de datos, se requerirá
el consentimiento expreso del titular de éstos, quien podrá seleccionar la
información a compartirse con terceros.
La recopilación y uso de datos personales responderá a los derechos de
privacidad, intimidad y confidencialidad garantizados por la Constitución
Política de la República y esta ley, las cuales podrán ser utilizados o
transferidos únicamente con autorización del titular u orden de autoridad.
Código Orgánico Integral Penal (2014)
Sección Tercera Delitos Contra la Seguridad de los Activos de los
Sistemas de Información y Comunicación
Art. 229.- Revelación ilegal de base de datos. - La persona que, en
provecho propio o de un tercero, revele información registrada, contenida
en ficheros, archivos, bases de datos o medios semejantes, a través o
dirigidas a un sistema electrónico, informático, telemático o de
telecomunicaciones; materializando voluntaria e intencionalmente la
violación del secreto, la intimidad y la privacidad de las personas, será
sancionada con pena privativa de libertad de uno a tres años.
55
Si esta conducta se comete por una o un servidor público, empleadas o
empleados bancarios internos o de instituciones de la economía popular y
solidaria que realicen intermediación financiera o contratista, será
sancionada con pena privativa de libertad de tres a cinco años.
Decreto 1014
Sobre el uso de Software Libre
Art. 1.- Establecer como política pública para las Entidades de la
Administración Pública General la utilización de Software Libre en sus
sistemas y equipamientos informáticos.
Art. 2.- Se entiende por Software Libre, a los programas de computación
que se pueden utilizar y distribuir sin restricción alguna, que permitan su
acceso a los códigos fuentes y que sus aplicaciones puedan ser
mejoradas.
Estos programas de computación tienen las siguientes libertades:
a) Utilización del programa con cualquier propósito de uso común.
b) Distribución de copias sin restricción alguna.
c) Estudio y modificación del programa (Requisito: código fuente
disponibles).
d) Publicación del programa mejorado (Requisito: código fuente
disponible).
Art. 3.- Las entidades de Administración Pública Central previa a la
instalación del software libre en sus equipos, deberán verificar la
56
existencia de capacidad técnica que brinde el soporte necesario para el
uso de este tipo de software.
Art. 4.- Se faculta la utilización de software propietario (no libre)
únicamente cuando no exista una solución de Software Libre que supla
las necesidades requeridas, o cuando esté en riesgo la seguridad
nacional, o cuando el proyecto informático se encuentre en un punto de
no retorno.
Para efectos de este decreto se comprende como seguridad nacional, las
garantías para la supervivencia de la colectividad y la defensa del
patrimonio nacional.
Para efectos de este decreto se entiende por un punto de no retorno,
cuando el sistema o proyecto informático se encuentre en cualquiera de
estas condiciones:
a) Sistema en producción funcionando satisfactoriamente y que un
análisis de costo beneficio muestre que no es razonable ni
conveniente una migración a Software Libre.
b) Proyecto en estado de desarrollo y que un análisis de costo –
beneficio muestre que no es conveniente modificar el proyecto y
utilizar software libre.
Periódicamente se evalúan los sistemas informáticos que utilizan software
libre propietario con la finalidad de migrarlos a Software Libre.
57
Art. 5.- Tanto para software libre como software propietario, siempre y
cuando se satisfagan los requerimientos, se debe preferir las soluciones
en este orden:
a) Nacionales que permitan autonomía y soberanía tecnológica.
b) Regionales con componente nacional.
c) Regionales con proveedores nacionales.
d) Internacionales con componente nacional.
e) Internacionales con proveedores nacionales.
f) Internacionales.
Art. 6.- La subsecretaría de Informática como órgano regulador y ejecutor
de las políticas y proyectos informáticos en las entidades del Gobierno
Central deberá realizar el control y seguimiento de este derecho.
Para todas las evaluaciones constantes en este decreto la Subsecretaría
de Informática establecerá los parámetros y metodología obligatorias.
Art. 7.- Encárguese de la ejecución de este decreto los señores Ministros
Coordinadores y el señor Secretario General de la Administración Pública
y Comunicación.
58
HIPÓTESIS
¿Si al menos el 70% de la población encuestada tiene problemas con el
manejo de varias claves para el acceso a las aplicaciones web, es
necesario que la UG cuente con un Sistema Centralizado de
Autenticación?
¿Si al menos el 50% de la población encuestada indica que no memoriza
las credenciales de autenticación de las diferentes aplicaciones web, es
necesaria la implementación de un Sistema Centralizado de
Autenticación?
¿Si al menos el 50% de la población está de acuerdo que con una única
autenticación se pueda acceder a las diferentes aplicaciones web de la
Universidad de Guayaquil, valida que es necesario tener un Sistema
Centralizado de Autenticación?
VARIABLES DE LA INVESTIGACIÓN
Variable independiente
Servicio de autenticación centralizada.
Variable dependiente
Las aplicaciones web de la Universidad de Guayaquil.
59
DEFINICIONES CONCEPTUALES
Login: Proceso mediante el cual un usuario accede a sus cuentas, este
tipo de proceso va acompañado de un previo registro y segundo por el
ingreso de un nombre de usuario y contraseña. (Alegsa, 2017a)
Credenciales: Identificador que permite validar la autenticidad de un
usuario para obtener acceso a un recurso. (GlosarioIT, 2017)
Autenticación del usuario: Proceso mediante el cual se confirma que el
usuario es quien dice ser. (IBM, 2013)
Control de acceso: Es el acto de permitir o restringir el acceso de un
usuario a un sistema o servicio. (IBM, 2012)
Servidor de autenticación: Es un equipo o arquitectura de seguridad
para los sistemas o servicios, cuya función específica es autenticar a los
usuarios. (Microsoft, 2017c)
Protocolo de autenticación: Conjunto de reglas para la comunicación
segura de entidades, usuarios y sistemas. Estos protocolos se negocian
entre sí para establecer un vínculo. (Microsoft, 2017)
Protocolo de autorización: Conjunto de reglas que sirve para conceder
permisos a un usuario o entidad, permitiendo o negando el consumo de
un servicio. (Microsoft, 2017)
Implementación: Es la instalación, configuración y puesta en marcha de
un sistema o servicio. (Voigtmann, 2017)
Proveedor de servicios: Es un equipo o entidad que brinda servicios a
otras entidades que son de necesidad para estos. (Alegsa, 2017b)
60
Gestión de identidades: Sistemas de políticas que permiten controlar a
los usuarios, sistemas o entidades mediante su identificación,
concediéndoles o no acceso a los servicios o recursos. (IBM, 2017)
Credenciales del usuario: Identificativos del usuario para acceder a los
sistemas. (Microsoft, 2017)
Tokens de seguridad: Cadena de caracteres para realizar transacciones
o comunicación en los sistemas, asegura la autenticación de los usuarios
cuando se utilizan contraseñas, almacenando en ellos datos de acceso.
(Azaustre, 2015)
Aplicaciones de escritorio: Es aquella aplicación que se encuentra
instalada en el computador, que se puede ejecutar con o sin internet.
(Velázquez, 2017)
Aplicaciones móviles: Son programas instalados en los dispositivos
móviles como teléfonos, tablet entre otros. (Rosso, 2005)
Aplicaciones web: Son aplicaciones a las que podemos acceder
mediante un navegador web, haciendo uso de internet o intranet.
(EcuRed, 2017)
Cifrado de datos: Método que aumenta la seguridad de los datos,
escribiéndolos con letras, símbolos o números que serán comprendidos
por parte de quien tenga la llave para descifrarlos. (Microsoft, 2017)
Open Source: También conocido como código abierto, es la expresión
con la que se conoce al software distribuido y desarrollado libremente. Se
enfoca más en los beneficios prácticos como acceso al código fuente que
61
en aspectos éticos y libres que son relevantes en el Software libre.
(Andrearrs, 2017)
Microsoft Azure: Es una colección de servicios en la nube integrados
que los desarrolladores y profesionales de TI utilizan para crear,
implementar y administrar aplicaciones en una red global de centro de
datos, utilizando las herramientas, aplicaciones y marcos que prefieran.
(Microsoft, 2017)
Microsoft Office 365: Es un servicio que ofrece las herramientas web
que permiten el acceso al correo, documentos, contactos y calendarios,
facilitando un buen control de la información tanto personal como
profesional. (Microsoft, 2017)
Scrum: Es un proceso aplicado de manera regular, siendo un conjunto de
buenas prácticas para trabajar de manera colaborativa en equipo para
obtener el mejor resultado posible en un proyecto, estas prácticas se
apoyan unas a otras. Scrum se aplica en entornos complejos en los que
se necesita obtener resultados pronto. (ProyectosAgiles, 2017)
62
CAPITULO III
METODOLOGÍA DE LA INVESTIGACION
DISEÑO DE LA INVESTIGACIÓN
Modalidad de la Investigación
Cuantitativo
Busca recopilar datos específicos sobre la aceptación de este sistema
propuesto, en donde se logrará determinar resultados reales en este
proyecto.
En la investigación cuantitativa solo se reúne información que puede ser
medida con el fin de explicar lo que se observa, esta investigación hace
uso de herramientas tales como cuestionarios, encuestas y otros equipos
para recoger información. (Shuttleworth, 2017)
Tipos de Investigación
El tipo de investigación que se implementa en este trabajo es una
investigación aplicada y de campo.
Investigación aplicada
“Se caracteriza por su interés en la aplicación, utilización y consecuencias
prácticas de los conocimientos. La investigación aplicada busca el
conocer para hacer, para actuar, para construir, para modificar”. (Muños &
Lara, 2013).
Como el objetivo principal es implementar un prototipo de Sistema de
Autenticación Centralizada para los usuarios de las aplicaciones web de
63
la UG con el que se podrá acceder al SIUG, por medio de la investigación
aplicada se pudo obtener conocimientos de la herramienta
IdentityServer4, que tiene como finalidad es mejorar el control de acceso
y gestión de identidades de los usuarios. En este caso, aplica el sistema
de autenticación mencionado en el Capítulo II.
Investigación de Campo
“La investigación de campo es la que se efectúa en el lugar y tiempo en
que ocurren los fenómenos objeto de estudio” (Muños & Lara, 2013).
Para poder implementar el sistema de autenticación centralizado para los
usuarios de las aplicaciones web de la UG, requerimos de una
investigación de campo que nos ayude a tener contacto con los usuarios
para saber su opinión con la propuesta de este proyecto.
Para esto realizamos encuestas a los estudiantes y docentes de la
Universidad de Guayaquil para conocer si nuestra propuesta de
implementación es viable para la universidad.
POBLACIÓN Y MUESTRA
Población
Para la realización de la investigación, se tomó como población a todos
los estudiantes y docentes de todas las facultades de la UG, con sede
principal en la ciudadela Salvador Allende ubicada en entre la Av. Delta y
Av. Kennedy.
64
Muestra
Para la muestra se ha desarrollado encuesta orientada a los estudiantes y
docentes de la Universidad de Guayaquil, constará de 8 preguntas de las
cuales se busca obtener información acerca de su percepción e interés en
la propuesta de implementación que estamos proponiendo.
Los datos recopilados a través de la encuesta serán tabulados.
Para obtener la muestra se ha utilizado la siguiente fórmula.
FÓRMULA DE MUESTRA
𝒏 =𝒎
𝒆𝟐(𝒎 − 𝟏) + 𝟏
Dónde:
n = Tamaño de la muestra
e = Error de estimación
m = Tamaño de la población
Datos:
n = ?
e = 0.05
m = 77298
65
𝒏 =𝟕𝟕𝟐𝟗𝟖
𝟎. 𝟎𝟓𝟐(𝟕𝟕𝟐𝟗𝟖 − 𝟏) + 𝟏
𝒏 =𝟕𝟕𝟐𝟗𝟖
𝟎. 𝟎𝟓𝟐(𝟕𝟕𝟐𝟗𝟕) + 𝟏
𝒏 =𝟕𝟕𝟐𝟗𝟖
𝟏𝟗𝟑. 𝟐𝟒 + 𝟏
𝒏 =397.95
CUADRO N° 5 CUADRO DISTRIBUTIVO DE LA POBLACIÓN
Población Cantidad
POBLACIÓN TOTAL DE
ESTUDIANTES Y PROFESORES
77298
TOTAL 77298
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
CUADRO N° 6 CUADRO DISTRIBUTIVO DE LA MUESTRA
Muestra Cantidad
ESTUDIANTES Y PROFESORES 398
TOTAL 398
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
66
INSTRUMENTOS DE RECOLECCIÓN DE DATOS
Técnica
“Las técnicas, son los medios empleados para recolectar información
entre las que destacan la observación, cuestionario, entrevistas,
encuestas” (Málaga, 2017).
En base a esto, la investigación se llevará a cabo en las instalaciones de
la Universidad de Guayaquil, se ha tomado en cuenta tanto a los
estudiantes y docentes de todas las facultades.
La técnica que se emplean en esta investigación de campo, estará
basada en la encuesta.
Instrumentos de la Investigación
Técnica cuantitativa
Encuesta
Con la encuesta podemos conocer el grado de satisfacción o
insatisfacción de las personas involucradas, nos permite obtener
respuestas que interesan al investigador, por medio de un cuestionario de
preguntas dirigidas a una parte representativa de los estudiantes y
docentes de la UG.
Recolección de la información
Para realizar la recolección de la información y analizar los requerimientos
del proyecto, se realizaron las siguientes actividades:
Se hicieron encuestas a los estudiantes y docentes de la UG todo
el mes de julio del 2017 en varias facultades.
67
Se utilizaron preguntas técnicas, pero de fácil entendimiento a los
estudiantes y docentes encuestados.
Para la obtención de las respuestas se utilizó preguntas objetivas.
Procesamiento y Análisis
El análisis y procesamiento de información será ordenada y representada
mediante cuadros sumatorios estadísticos y gráficas que representan el
porcentaje obtenida de los datos, en la encuesta realizada para el
proyecto de titulación “Implementación de un Sistema Centralizado de
Autenticación para los usuarios de las diferentes aplicaciones web de la
UG”
Análisis e Interpretación de Datos
A continuación, se muestran los resultados de la encuesta en cuadros, los
cuales contienen la frecuencia y el porcentaje de la cantidad de usuarios
que eligieron dicha respuesta.
68
Encuestas
Pregunta 1.- Rango de edad (Seleccione una sola opción).
CUADRO N° 7 MEDICIÓN DE RESULTADOS – PREGUNTA 1
Alternativas de respuesta Alternativas marcadas Porcentaje de alternativas marcadas
Menor o igual a 20 48 12%
21 – 25 105 26%
26 – 30 118 30%
31 – 35 34 9%
36 – 40 52 13%
41 o más 41 10%
Total
398
100%
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Gráfico 13 Medición De Resultados – Pregunta 1
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Descripción:
Se observa que más de la mitad de la población encuestada se encuentra
en el rango de los 21 a 30 años.
12%
26%
30%
9%
13%
10%
Menor o igual a 20 21 - 25 26 - 30
31 - 35 36 - 40 41 o más
69
Pregunta 2.- ¿Cree usted que es tedioso memorizar un usuario y
contraseña diferente para cada aplicación web de la Universidad de
Guayaquil? (Seleccione una sola opción).
CUADRO N° 8 MEDICIÓN DE RESULTADOS – PREGUNTA 2
Alternativas de respuesta Alternativas marcadas Porcentaje de alternativas marcadas
Totalmente de acuerdo 215 54%
Parcialmente de acuerdo 75 19%
Me es indiferente 47 12%
Parcialmente en desacuerdo
43 11%
Totalmente en desacuerdo 18 4%
Total 398 100%
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Gráfico 14 Medición De Resultados – Pregunta 2
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Descripción: Del 100% de los encuestados, el 54% está totalmente de acuerdo que es tedioso memorizar credenciales para diferente aplicativo web, el 19% está parcialmente de acuerdo, el 12% le es indiferente, el 11% está parcialmente en desacuerdo y el 4% restante está totalmente en desacuerdo.
54%
19%
12%
11%4%
Totalmente de acuerdo Parcialmente de acuerdo
Me es indiferente Parcialmente en desacuerdo
Totalmente en desacuerdo
70
Pregunta 3.- ¿Ud ha tenido problemas al olvidar sus usuarios y
contraseñas de las aplicaciones web de la Universidad de Guayaquil?
(Seleccione una sola opción).
CUADRO N° 9 MEDICIÓN DE RESULTADOS – PREGUNTA 3
Alternativas de respuesta Alternativas marcadas Porcentaje de alternativas marcadas
Si
283
71%
No
115
29%
Total
398
100%
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Gráfico 15 Medición De Resultados – Pregunta 3
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Descripción:
Del 100% de los encuestados, el 71% tuvo problemas al olvidar su
usuario y contraseña de las aplicaciones web de la Universidad de
Guayaquil y el 29% restante no ha tenido inconvenientes.
71%
29%
Si No
71
Pregunta 4.- ¿Cómo fue el proceso de recuperación de contraseña de las
aplicaciones web de la Universidad de Guayaquil? (Seleccione una opción).
CUADRO N° 10 MEDICIÓN DE RESULTADOS – PREGUNTA 4
Alternativas de respuesta Alternativas marcadas Porcentaje de alternativas marcadas
Mediante un administrador de sistema
258 65%
Vía web 21 5%
Otro 4 1%
No lo he requerido 115 29%
Total
398
100%
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Gráfico 16 Medición De Resultados – Pregunta 4
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Descripción:
Del 100% de los encuestados, el 65% ha recurrido a un administrador de
sistema para recuperar su contraseña, el 5% lo ha realizado vía web, el
1% ha utilizado otro recurso y el 29% restante no lo ha requerido.
65%5%1%
29%
Mediante un administrador de sistemaVía webOtro
72
Pregunta 5.- ¿Dónde guarda usualmente sus usuarios y contraseñas de las
aplicaciones web de la Universidad de Guayaquil? (Seleccione una sola
opción).
CUADRO N° 11 MEDICIÓN DE RESULTADOS – PREGUNTA 5
Alternativas de respuesta Alternativas marcadas Porcentaje de alternativas marcadas
La memoriza 197 50%
Libro o cuaderno 19 5%
Celular o Tablet 24 6%
Laptop 88 22%
Computadora de escritorio
49 12%
Otros 21 5%
Total 398 100%
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Gráfico 17 Medición De Resultados – Pregunta 5
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Descripción:
Del 100% de los encuestados, el 50% memoriza sus credenciales y el
otro 50% necesita guardarlas en un objeto para recordarlas.
50%
5%6%
22%
12%5%
La memoriza Libro o cuaderno
Celular o Tablet Laptop
Computadora de escritorio Otros
73
Pregunta 6.- ¿Cree ud que es una buena práctica el tener una autenticación
independiente para cada servicio web de la Universidad de Guayaquil?
(Seleccione una sola opción).
CUADRO N° 12 MEDICIÓN DE RESULTADOS – PREGUNTA 6
Alternativas de respuesta Alternativas marcadas Porcentaje de alternativas marcadas
Totalmente de acuerdo 67 7%
Parcialmente de acuerdo 10 2%
Me es indiferente 74 19%
Parcialmente en desacuerdo
94 24%
Totalmente en desacuerdo 153 38%
Total 398 100%
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Gráfico 18 Medición De Resultados – Pregunta 6
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Descripción:
Del 100% de los encuestados, el 17% cree que es una buena práctica
tener una autenticación diferente para cada servicio web, el 2% está
parcialmente de acuerdo, el 19% le es indiferente, el 62% está en
desacuerdo.
17%
2%
19%
24%
38%
Totalmente de acuerdo Parcialmente de acuerdo
Me es indiferente Parcialmente en desacuerdo
Totalmente en desacuerdo
74
Pregunta 7.- ¿Qué opina sobre la posibilidad de que con una única
autenticación pueda acceder a todas las aplicaciones web de la
Universidad de Guayaquil?? (Seleccione solo una opción).
CUADRO N° 13 MEDICIÓN DE RESULTADOS – PREGUNTA 7
Alternativas de respuesta
Alternativas marcadas
Porcentaje de alternativas marcadas
Totalmente de acuerdo 260 65%
Parcialmente de acuerdo 89 23%
Me es indiferente 37 9%
Parcialmente en desacuerdo
8 2%
Totalmente en desacuerdo 4 1%
Total 398 100%
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Gráfico 19 Medición De Resultados – Pregunta 7
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Descripción:
Del 100% de los encuestados, el 65% está totalmente de acuerdo, el 23%
muestra estar parcialmente de acuerdo, el 9% de personas le es indiferente,
mientras que el 2% dice estar parcialmente en desacuerdo, y el 1% restante está
totalmente en desacuerdo.
65%
23%
9%2%
1%
Totalmente de acuerdo Parcialmente de acuerdo
Me es indiferente Parcialmente en desacuerdo
Totalmente en desacuerdo
75
Pregunta 8.- ¿Estaría de acuerdo con la utilización de su usuario de correo
institucional para autenticarse con las aplicaciones web de la Universidad
de Guayaquil? (Seleccione una sola opción).
CUADRO N° 14 MEDICIÓN DE RESULTADOS – PREGUNTA 8
Alternativas de respuesta
Alternativas marcadas Porcentaje de alternativas marcadas
Totalmente de acuerdo 278 70%
Parcialmente de acuerdo 82 20%
Me es indiferente 23 6%
Parcialmente en desacuerdo
7 2%
Totalmente en desacuerdo
8 2%
Total 398 100%
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Gráfico 20 Medición De Resultados – Pregunta 8
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Descripción: El 70% de los encuestados están totalmente de acuerdo con la utilización de sus credenciales office 365 como único medio de autenticación a los servicios web de la Universidad de Guayaquil, el 20% está parcialmente de acuerdo, el 6% le es indiferente, mientras que el 2% dice estar parcialmente en desacuerdo y el 2% restante muestra estar totalmente en desacuerdo.
70%
20%
6%2%2%
Totalmente de acuerdo Parcialmente de acuerdo
Me es indiferente Parcialmente en desacuerdo
Totalmente en desacuerdo
76
Validación de la Hipótesis
Tras la recolección de los datos con las encuestas en las diferentes
facultades de la UG, se validan las hipótesis
Hipótesis I
¿Si al menos el 70% de la población encuestada tiene problemas con el
manejo de varias claves para el acceso a las aplicaciones web, es
necesario que la UG cuente con un Sistema Centralizado de
Autenticación?
Validación
Basados en la respuesta de la pregunta 3, el 71% de la población
encuestada indica que tiene problemas al manejar varias credenciales de
autenticación para las diferentes aplicaciones web, con ese resultado se
valida la primera hipótesis demostrando que es necesario un Sistema
Centralizado de Autenticación en la Universidad de Guayaquil.
Hipótesis II
¿Si al menos el 50% de la población encuestada indica que no memoriza
las credenciales de autenticación de las diferentes aplicaciones web, es
necesaria la implementación de un Sistema Centralizado de
Autenticación?
Validación
Basados en la respuesta de la pregunta 5, el 50% de la población
encuestada dio a conocer que no memoriza la contraseña y requiere
anotarlas en algún objeto para recordarla, validando la segunda hipótesis
77
y demostrando que es necesaria la implementación de un Sistema
Centralizado de Autenticación en la Universidad de Guayaquil.
Hipótesis III
¿Si al menos el 50% de la población está de acuerdo que con una única
autenticación se pueda acceder a las diferentes aplicaciones web de la
Universidad de Guayaquil, valida que es necesario tener un Sistema
Centralizado de Autenticación?
Validación
Basados en la respuesta de la pregunta 7, el 65% de la población
encuestada dio a conocer que está totalmente de acuerdo que con una
única autenticación se pueda acceder a todas las aplicaciones web de la
Universidad de Guayaquil, validando la tercera hipótesis y demostrando
una vez más la necesidad de contar con un Sistema Centralizado de
Autenticación en la UG.
78
CAPÍTULO IV
PROPUESTA TECNOLÓGICA
Esta propuesta tecnológica surge del estudio previo de las necesidades
que tienen los usuarios de las aplicaciones web de la UG y la
inconformidad que les ocasiona el tener un usuario y contraseña diferente
para cada aplicación web.
En este proyecto se quiere demostrar que se puede eliminar aquella
inconformidad mediante la implementación de un piloto de Sistema
Centralizado de Autenticación que utilizará la plataforma Microsoft Office
365 para extraer las credenciales de los usuarios, además para demostrar
el acceso con una única autenticación se integrará con dos aplicaciones
que son de desarrollo propio.
Se intentó integrar una de las aplicaciones web de la universidad de
Guayaquil con el sistema Centralizado de Autenticación, pero se tuvo
inconvenientes en el proceso de obtención de permisos debido a que se
realizó un cambio de autoridad en el centro de cómputo de la UG.
Factibilidad operacional
El proyecto se considera factible debido a que los usuarios participaron en
las encuestas y dieron a conocer que están de acuerdo con poder
acceder a todas las aplicaciones web con una única identificación y
contraseña, demostrando con este sistema que será de fácil uso para el
79
usuario final y de gran ayuda para evitar que posean varias credenciales
de autenticación.
Este sistema al estar estructurado por capas es fácil de modificar e
intuitivo para realizar cambios cuando se lo requiera.
Factibilidad técnica
Este proyecto es factible técnicamente ya que utiliza la herramienta
IdentityServer4 la cual es fácil de conseguir y es de código abierto, por lo
que es libre de ser modificada dependiendo de las necesidades de la UG,
desarrollado en un lenguaje popular como lo es C#.
Se eligió la herramienta IdentityServer4 para que autentique a los
usuarios de las aplicaciones web de la UG, porque cumple con funciones
necesarias para satisfacer las necesidades actuales y las que se puedan
presentar a futuro como la integración de nuevas aplicaciones.
Este sistema se encuentra instalado en una cuenta gratuita de Microsoft
Azure en la nube, se lo puede instalar en uno de los servidores que posee
la universidad, ya que no realizará gran funcionamiento al sólo ser un
servidor transaccional, por lo que el hardware es fácil de conseguir.
Factibilidad legal
Este proyecto es factible en lo legal ya que se está usando software de
licencia libre y no hay ley que impida utilizar este tipo de desarrollo en una
institución educativa, por lo consiguiente no evade ningún tipo de ley. En
la fundamentación legal, en el capítulo II se detallan todas las leyes y
80
reglamentos alineados a este proyecto.
Factibilidad económica
Para la implementación de este proyecto se está haciendo uso de una
herramienta Open Source como lo es IdentityServer4, el cual controlará la
autenticación y acceso de los usuarios hacia las aplicaciones web, por lo
consiguiente no es necesario pagar por una licencia para la herramienta.
Otro punto para recalcar es que este proyecto no tendrá costo monetario
para los usuarios ya que para ingresar a los aplicativos e identificarse por
IdentityServer4 lo realizaran mediante un navegador web utilizando un
dispositivo móvil, laptop o PC. Los costos que se emplearán en el
proyecto serán los siguientes.
CUADRO N° 15 CUADRO DE COSTOS
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
RUBROS
FUENTES
TOTAL
CANTIDAD HORAS VALOR POR
HORA
Estudiantes 2 100 $20 $2000
Profesionales 1 50 $40 $2000
Software
“Identity Server4”
1 - - $0
Viajes y Salidas de
Campo
- 10 $10 $100
Impresión de hojas 1 - - $50
TOTAL - - - $4150.00
81
Etapas de la metodología del proyecto
Para la elaboración del proyecto se utilizará la metodología SCRUM.
considerada como una metodología de desarrollo ágil, que estima el uso
de 6 Sprints.
En el cuadro 12 se puede observar los objetivos de cada Sprint.
CUADRO N° 16 SPRINT DEL PROYECTO
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
SPRINT
OBJETIVOS
1 Adquisición de equipos y sistemas necesarios para diseñar
un esquema de comunicación para desarrollar el proyecto.
2 Investigar todo lo necesario de las herramientas que se van a
utilizar para autenticar a los usuarios y permitir la integración
con las aplicaciones clientes.
3 Instalar el sistema de autenticación, realizar las pruebas
necesarias para eliminar todas las fallas posibles.
4 Elaborar el anteproyecto con la problemática, objetivos
específicos y alcances del proyecto lo cuales serán
asignados a cada integrante del grupo de implementación.
5 Adquisición del API de Microsoft Office 365 y autenticar al
usuario contra el mismo.
6 Integración del sistema de autenticación con los aplicativos
clientes.
82
Cada Sprint tiene actividades a desarrollar las cuales son las siguientes:
Sprint 1 Adquisición de equipos y sistemas necesarios para diseñar un
esquema de comunicación para desarrollar el proyecto.
Análisis de los equipos que se van a utilizar.
Comparación de las diferentes alternativas de sistemas para que
realice el proceso de Autenticación Centralizada.
Crear cuenta en Microsoft Azure para montar el sistema y
comenzar a realizar pruebas.
Sprint 2 Investigar todo lo necesario de las herramientas que se van a
utilizar para autenticar a los usuarios y permitir la integración con las
aplicaciones clientes.
Se eligió la herramienta IdentityServer4 para implementarlo como
sistemas de autenticación, el cual se encargará de autenticar a los
usuarios para el acceso a las aplicaciones.
Investigación de la configuración de IdentityServer4.
Investigar como IdentityServer envía y recibe los Tokens de acceso
y seguridad.
Sprint 3 Instalar el sistema de autenticación, realizar las pruebas
necesarias para eliminar todas las fallas posibles.
Instalar IdentityServer4 en Microsoft Azure.
Configuración de IdentitySever4 para que pueda ser accedido
desde internet.
83
Realizar las pruebas necesarias y correcciones.
Sprint 4 Elaborar el anteproyecto con la problemática, objetivos
específicos y alcances del proyecto lo cuales serán asignados a cada
integrante del grupo de implementación.
Reunión con asesores de vicerrectorado académico para proponer
la implementación del prototipo del sistema.
Reunión para compartir las tareas y temas a desarrollar por cada
integrante del proyecto y personal del centro de cómputo de la UG.
Ejecución de cada tema definido en el anteproyecto y que fue
designado a cada implicado del proyecto.
Sprint 5 Adquisición del API de Microsoft Office 365 y autenticar al
usuario contra el mismo.
Investigación de cómo obtener el Api de comunicación de Microsoft
Office 365.
Obtención de permisos para acceder al panel de administración de
office 365 de la UG.
Extracción del Api de Office 365.
Configuración para comunicar IdentityServer4 con Microsoft Office
365 mediante el uso de la Api y así autenticar a los usuarios
Sprint 6 Integración del sistema de autenticación con los aplicativos
clientes.
84
Configuración e integración de IdentityServer4 con los aplicativos
clientes.
Realizar pruebas de funcionamiento y comunicación entre los
sistemas.
Verificar el acceso de los usuarios a los aplicativos clientes cuando
realicen el proceso de autenticación.
Entregables del proyecto
Los entregables del proyecto será la implementación de un prototipo de
Sistema Centralizado de autenticación, demostrando que se puede
centralizar la autenticación para el acceso a las aplicaciones web de la
UG.
Procesos Funcionales: Esto se define a que el prototipo Sistema
Centralizado de Autenticación este trabajando correctamente donde se
puede hacer las pruebas respectivas.
En la página principal del sistema de autenticación el usuario se podrá
autenticar utilizando su correo institucional de office 365 con la respectiva
contraseña y podrá acceder a las aplicaciones clientes.
En el gráfico 21 se observa el flujo que se realiza cuando un usuario se
autentica en este sistema.
85
Gráfico 21 Proceso de Inicio de Sesión
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
86
Procesos de diseño: Se entregará la página de login como en el gráfico
22 en la que los usuarios se podrán autenticar para acceder a los
servicios protegidos.
Gráfico 22 Página de login
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Una vez que el usuario se autentique, por primera vez será redirigido al
formulario del gráfico 23 en el que deberán actualizar los datos solicitados
de forma obligatoria.
87
Gráfico 23 Actualizar datos
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Una vez que actualice los datos tendrá acceso a los recursos protegidos,
para los siguientes ingresos en que el usuario se autentique con el
Sistema Centralizado de Autenticación ya no tendrán que actualizar estos
datos.
Adjunto a este proyecto de titulación se entregará un manual técnico, ver
anexo 2.
88
Criterios de validación de la propuesta
CUADRO N° 17 CRITERIOS DE VALIDACIÓN DE LA PROPUESTA
Aplicaciones web
Se pudo integrar al sistema de
autenticación
Se puede autenticar usando las
credenciales de office 365
SI NO SI
NO
Office 365 X - -
Aplicación 1 X X
Aplicación 2 X X
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
Se validó la propuesta realizando pruebas al implementar y publicar el
sistema en internet en el que los usuarios acceden al Sistema
Centralizado de Autenticación. Mediante estas pruebas se pudo
demostrar que se puede acceder a diferentes aplicaciones web realizando
una única autenticación.
Por medio de esta implementación demuestra que se puede dar solución
al problema de autenticación que tienen los usuarios al tener que recordar
diferentes credenciales para el acceso a las aplicaciones web de la UG,
utilizando sólo el correo institucional con su respectiva contraseña para
autenticarse.
89
Se entrevistó a uno de los administradores de sistemas de centro de
cómputo de la UG para validar este proyecto.
Pregunta 1.- ¿Cree ud conveniente la Implementación de un Sistema
de autenticación Centralizado escalable en el que se pueda incluir
nuevos aplicativos y no se tenga que desarrollar nuevos formularios
de login?
Sí, sería de gran ayuda para evitarnos desarrollar nuevos formularios de
autenticación.
Pregunta 2.- ¿Considera conveniente que exista un servicio dedicado
para el control de acceso e identidades de los usuarios para las
aplicaciones web de la Universidad de Guayaquil?
Sí, hay que mejorar continuamente los mecanismos de seguridad en la
autenticación de los usuarios.
Pregunta 3.- ¿Le gustaría tener un único sistema en el que se facilite
la tarea de la gestión de credenciales de los usuarios de las
aplicaciones web de la Universidad de Guayaquil?
Si, así administraríamos a los usuarios en un único sistema.
90
Pregunta 4.- ¿Qué opina sobre la posibilidad de que se implemente
un Sistema Centralizado de Autenticación, en el que se integren
todos los servicios web de la Universidad de Guayaquil?
Sería una buena opción para realizar el proceso de autenticación de los
usuarios, ya que así no tendrían que recordar diferentes cuentas de
usuarios para varias aplicaciones.
Pregunta 5.- ¿Estaría de acuerdo con la utilización de las
credenciales de office 365 como el único medio de autenticación a
los servicios web de la Universidad de Guayaquil?
Sí, así se obligaría a las personas a utilizar el correo institucional y no
deberían memorizar un nuevo usuario.
91
Criterios de aceptación del producto o servicio
CUADRO N° 18 CRITERIOS DE ACEPTACIÓN DEL PRODUCTO O SERVICIO
REQUERIMIENTOS
ACEPTACIÓN
Software necesario Utilización de Sistema operativo
Open Source. Reducción de
costos en la implementación de
este sistema en la UG.
Hardware necesario Se lo puede instalar en una
máquina virtualizada en la nube o
en uno de los servidores que
posea la universidad.
Fácil configuración Es un sistema amigable de fácil
administración y configuración. Es
escalable pensado para futuras
integraciones de aplicaciones.
Interfaz gráfica de fácil manejo
para el usuario.
Fácil acceso a las aplicaciones
para los usuarios de las
aplicaciones web de Universidad
de Guayaquil.
Comprobar mediante el
prototipo el funcionamiento del
sistema.
Las pruebas realizadas mostraron
buen funcionamiento del prototipo.
Disponibilidad de la nube Continuidad operacional del
servicio en la nube hasta el mes
de diciembre para las respectivas
demostraciones.
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
92
Con el cumplimiento de las tareas planteadas para el desarrollo del
proyecto se logró tener un Sistema Centralizado de Autenticación,
integrados con recursos web que se encuentran protegidos, además de
tener un servicio seguro, escalable y confiable por parte de los usuarios y
administradores. Mediante pruebas realizadas se demuestra que se
puede centralizar la autenticación de las aplicaciones web de la
Universidad de Guayaquil.
93
CUADRO N° 19 SPRINT REALIZADOS DURANTE EL PROYECTO
SPRINT OBJETIVOS DE SPRINT
REALIZADOS
PORCENTAJE DE
CUMPLIMIENTO
1 Adquisición de equipos y sistemas
necesarios para diseñar un
esquema de comunicación para
desarrollar el proyecto.
100%
2 Investigar todo lo necesario de las
herramientas que se van a utilizar
para autenticar a los usuarios y
permitir la integración con las
aplicaciones clientes.
100%
3 Instalar el sistema de
autenticación, realizar las pruebas
necesarias para eliminar todas las
fallas posibles.
100%
4 Elaborar el anteproyecto con la
problemática, objetivos
específicos y alcances del
proyecto lo cuales serán
asignados a cada integrante del
grupo de implementación.
100%
5 Adquisición del API de Microsoft
Office 365 y autenticar al usuario
contra el mismo.
100%
6 Integración del sistema de
autenticación con los aplicativos
clientes.
100%
Fuente: Datos de la Investigación
Elaborado por: Dayana Villafuerte – Carlos Peñarrieta
94
CONCLUSIONES Y RECOMENDACIONES
Conclusiones
Una vez cumplido y analizado todos los requerimientos para la
implementación de un Sistema Centralizado de Autenticación para los
usuarios de las diferentes aplicaciones web de la UG se llega a las
siguientes conclusiones:
1) Es factible centralizar la autenticación de las aplicaciones web de la
Universidad de Guayaquil con el sistema elegido, utilizando
Microsoft Office 365 para extraer las credenciales de los usuarios.
2) Los usuarios encuestados tuvieron una gran aceptación con la
propuesta de implementar un sistema centralizado de
autenticación.
3) Con esta implementación se consigue depender sólo de Identity
Server para realizar el proceso de autenticación de las
aplicaciones.
95
Recomendaciones
Una vez concluido este proyecto de titulación se recomienda que:
1) El sistema implementado debe trabajar con el protocolo https para
mantener la integridad y confidencialidad de los datos de los
usuarios.
2) Que este proyecto continúe en una segunda fase para que sea
implementado en un ambiente de producción, haciendo el análisis
de la red de la Universidad de Guayaquil y el tiempo de respuesta
de la misma.
3) Otra opción sería implementar integrando el sistema centralizado
de autenticación con aplicaciones móviles y de escritorio.
96
BIBLIOGRAFÍA
Alegsa. (2017a). DICCIONARIO DE INFORMÁTICA Y TECNOLOGÍA.
Retrieved from http://www.alegsa.com.ar/Dic/login.php
Alegsa. (2017b). DICCIONARIO DE INFORMÁTICA Y TECNOLOGÍA.
Retrieved from
http://www.alegsa.com.ar/Dic/proveedor_de_servicio_de_aplicacione
s.php
Allen, B., & Baier, D. (2017). IdentityServer4. Retrieved from
http://docs.identityserver.io/en/release/
Alvarado, C. (2015). Middleware para un sistema de gestión de identidad
en telefónica chile. Universidad de Chile. Retrieved from
http://repositorio.uchile.cl/bitstream/handle/2250/135134/Middleware-
para-un-sistema-de-gestion-de-identidad-en-Telefonica-
Chile.pdf;sequence=1
Andrearrs. (2014). Diferencias entre Software Libre y Open Source.
Retrieved from https://hipertextual.com/archivo/2014/05/diferencias-
software-libre-y-open-source/
Apereo. (2017). CAS. Retrieved from https://www.apereo.org/projects/cas
Azaustre, C. (2015). ¿Qué es la autenticación basada en Token?
Retrieved from https://carlosazaustre.es/que-es-la-autenticacion-con-
token/
Cano, J. (2014). Implementación del sistema centralizado de
autenticación y autorización para las aplicaciones web del centro de
97
cálculo e investigación de la facultad de ingeniería de la universidad
de san carlos de guatemala. Universidad San Carlos de Guatemala.
Retrieved from http://biblioteca.usac.edu.gt/tesis/08/08_0817_CS.pdf
CATechnologies. (2014). Estrategia de autenticación. Retrieved from
https://www.ca.com/content/dam/ca/es/files/ebook/intelligent-
authentication-balancing-security-and-convenience.pdf
Chakray. (2017). QUÉ ES UN IDENTITY SERVER Y CUÁL NECESITAS
HOY EN DÍA. Retrieved from http://www.chakray.com/que-es-un-
identity-server-y-cual-necesitas-hoy-en-dia/
Díaz, O., Cohn, D., & Rios, G. (2015). Implantación de un servicio de
autenticación basado en Shibboleth en la PUCP - Caso de Estudio.
Tical 2015, 15. https://doi.org/10.13140/RG.2.1.3224.0088
EcuRed. Aplicación web (2017). Retrieved from
https://www.ecured.cu/Aplicación_web
GlosarioIT. (2017). Credencial - Sección Redes. Retrieved from
http://www.glosarioit.com/#!Credencial
Gonzáles, S. (2010). Implementación de un sistema unificado de
autenticación de usuarios aplicado a los diferentes servicios de la
Universidad Tecnológica de Bolívar. UNIVERSIDAD TECNOLÓGICA
DE BOLÍVAR.
González, A. (2012). The Game of Code. Retrieved from
http://www.thegameofcode.com/2012/07/conceptos-basicos-de-
oauth2.html
98
Holguín, A. (2012). Autenticación Centralizada Con Tecnología Ldap.
Retrieved from
http://52.1.175.72/portal/sites/all/themes/argo/assets/img/Pagina/ldap.
doc
IBM. (2012). Definición de grupos de control de acceso. Retrieved from
https://www.ibm.com/support/knowledgecenter/es/SSLVY3_10.0.0/co
m.ibm.pim.dev.doc/pim_con_arc_definingacgs.html
IBM. (2013). Identificación y autenticación de usuarios. Retrieved from
https://www.ibm.com/support/knowledgecenter/es/SSFKSJ_7.1.0/com
.ibm.mq.doc/zs00080_.htm
IBM. (2017). Gestión de accesos e identidades. Retrieved from
http://www-03.ibm.com/software/products/es/category/identity-access-
management
Lang, J., & Lang, P. (2009). ESOE. Enterprise Sign-On Engine. Retrieved
from http://esoeproject.qut.edu.au/
Lozano, C. (2013). Sistema Centralizado de Autenticación de Usuarios
para la Subdirección de Seguridad de la información UNAM-CERT.
UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO. Retrieved
from
https://www.google.com.ec/url?sa=t&rct=j&q=&esrc=s&source=web&
cd=2&cad=rja&uact=8&ved=0ahUKEwir2sTgloDVAhWM4iYKHQbhD
a4QFggrMAE&url=http%3A%2F%2Fwww.ptolomeo.unam.mx%3A80
80%2Fxmlui%2Fbrowse%3Fvalue%3DSistema%2Bcentralizado%2B
99
de%2Bautenticaci%25C3%25B3n%2Bd
Málaga, U. de. (2017). Técnicas e instrumentos de Investigación. In
Enciclopedia virtual.
Marrero, R. (2014). Sistema centralizado de gestión de usuarios para
Innova7. Universidad de la Laguna. Retrieved from
https://riull.ull.es/xmlui/bitstream/handle/915/191/Sistema
Centralizado de Gestion de Usuarios para
Innova7..pdf?sequence=1&isAllowed=y
Merino, M. (2014). ticbeat. Retrieved from
http://www.ticbeat.com/tecnologias/que-es-una-api-para-que-sirve/
Microsoft. (2007). Credenciales de usuario y acceso a orígenes de datos
en el Explorador de servidores/Explorador de bases de datos.
Retrieved from https://msdn.microsoft.com/es-
es/library/3whw1cac%28v=vs.90%29.aspx?f=255&MSPPError=-
2147217396
Microsoft. (2017a). ¿Qué es Azure? Retrieved from
https://azure.microsoft.com/es-es/overview/what-is-azure/
Microsoft. (2017b). ¿Qué es Office 365? Retrieved from
https://blogs.technet.microsoft.com/microsoftlatam/2011/05/05/qu-es-
office-365/
Microsoft. (2017c). Acerca de los servidores de autenticación. Retrieved
from https://technet.microsoft.com/es-
ec/library/cc441703.aspx?f=255&MSPPError=-2147217396
100
Microsoft. (2017d). Cifrado de datos. Retrieved from
https://technet.microsoft.com/es-es/library/dn531199.aspx
Microsoft. (2017e). Office 365 API reference. Retrieved from
https://msdn.microsoft.com/en-us/office/office365/api/api-catalog
Microsoft. (2017f). Protocolo de autorización de credenciales de host.
Retrieved from https://technet.microsoft.com/es-
es/library/cc732681%28v=ws.11%29.aspx?f=255&MSPPError=-
2147217396
Microsoft. (2017g). Protocolos de autenticación. Retrieved from
https://technet.microsoft.com/es-es/library/dd197565(v=ws.10).aspx
Muños, E., & Lara, M. (2013). Tipos de Investigación. In A. Herrera (Ed.),
Fundamentos de Investigación 2da edición (Alfaomega, p. 440).
MéxicoD.F., México.
OpenID. (2017). OpenID Connect FAQ and Q&As. Retrieved from
http://openid.net/connect/faq/
Parecki, A. OAuth, OAuth 2.0 § (2017). Retrieved from https://oauth.net/
ProyectosAgiles. (2017). Proyectos Agiles. Retrieved from
https://proyectosagiles.org/que-es-scrum/
Restrepo, S. (2015). Implementación de un sistema proveedor de
identidad para ofrecer servicios de autenticación mediante Inicio de
Sesión Único en una universidad de tamaño grande. Universidad
Internacional de la Rioja. Retrieved from
http://reunir.unir.net/bitstream/handle/123456789/3512/RESTREPO
101
GUZMAN%2C SANTIAGO.pdf?sequence=1
Rosso, E. (2005). Aplicaciones móviles. Retrieved from
http://www.mailxmail.com/curso-aplicaciones-moviles/concepto
Sánchez, J. (2011). Sistemas De Autenticación Y Autorización En
Internet. Universidad de Lleida. Retrieved from
https://jordisan.net/proyectos/Autent_y_auth-J_Sanchez.pdf?3eb125
Shibboleth. (2017). Shibboleth. Retrieved from
https://www.shibboleth.net/products/identity-provider/
Shuttleworth, M. (2017). Investigación Cuantitativa y Cualitativa. Retrieved
from https://explorable.com/es/diseno-de-la-investigacion-cualitativa
Ulpgc. (2017). CAS. Retrieved from
https://www.si.ulpgc.es/sites/default/files/images/stories/SIC/Jornadas
/Jornada11/2_Estudio_CAS.pdf
Velázquez, D. (2017). Aplicaciones web vs aplicaciones de escritorio.
Retrieved from https://www.webprogramacion.com/356/blog-
informatica-tecnologia/aplicaciones-web-vs-aplicaciones-de-
escritorio.aspx
Voigtmann, G. Implementación (2017). Retrieved from
http://www.voigtmann.de/es/desarrollo-de-software/implementacion/
Wikiwand. (2017). Enterprise Sign On Engine. Retrieved from
http://www.wikiwand.com/en/Enterprise_Sign_On_Engine
ANEXOS
Anexo 1
ENCUESTA SOBRE SISTEMA CENTRALIZADO DE AUTENTICACIÓN
La siguiente encuesta es un elemento diseñado para recopilar información de aporte para el desarrollo del proyecto de titulación “IMPLEMENTACIÓN DE UN SISTEMA CENTRALIZADO DE AUTENTICACIÓN PARA USUARIOS DE LAS DIFERENTES APLICACIONES WEB DE LA UG”. Se agradece su contribución y seriedad de las respuestas.
1. ¿Cuál es su edad?
o Menor o igual a 20
o 21-25
o 26-30
o 21-35
o 36-40
o 41 o más
2. ¿Cree usted que es tedioso memorizar un usuario y contraseña diferente para
cada aplicación web de la Universidad de Guayaquil? (Seleccione una sola
opción).
о Totalmente de acuerdo
о Parcialmente de acuerdo
о Me es indiferente
о Parcialmente en desacuerdo
о Totalmente en desacuerdo
3. ¿Usted ha tenido problemas al olvidar sus usuarios y contraseñas de las
aplicaciones web de la Universidad de Guayaquil? (Seleccione solo una
opción).
о Si
о No
4. ¿Cómo fue el proceso de recuperación de contraseña de las aplicaciones web
de la Universidad de Guayaquil? (Seleccione solo una opción).
о Mediante un administrador de sistemas
о Vía web
о Otro
о No lo he requerido
5. ¿Dónde guarda sus usuarios y contraseñas de las aplicaciones web de la
Universidad de Guayaquil? (Seleccione solo una opción).
о La memoriza
о Libro o cuaderno
о Celular o tablet
о Laptop
о Computadora de escritorio
о Otros
6. ¿Cree usted que es una buena práctica el tener una autenticación
independiente para cada aplicación web de la Universidad de Guayaquil?
(Seleccione una sola opción).
о Totalmente de acuerdo
о Parcialmente de acuerdo
о Me es indiferente
о Parcialmente en desacuerdo
о Totalmente en desacuerdo
7. ¿Qué opina sobre la posibilidad de que con una única autenticación pueda
acceder a todas las aplicaciones web de la Universidad de Guayaquil?
(Seleccione solo una opción).
о Totalmente de acuerdo
о Parcialmente de acuerdo
о Me es indiferente
о Parcialmente en desacuerdo
о Totalmente en desacuerdo
8. ¿Estaría de acuerdo con la utilización de su usuario de correo institucional para
autenticarse con las aplicaciones web de la Universidad de Guayaquil?
(Seleccione una sola opción).
о Totalmente de acuerdo
о Parcialmente de acuerdo
о No me parece relevante
о Parcialmente en desacuerdo
о Totalmente en desacuerdo
Anexo 2
Manual técnico
“IMPLEMENTACIÓN DE UN SISTEMA CENTRALIZADO DE
AUTENTICACIÓN PARA USUARIOS DE LAS DIFERENTES
APLICACIONES WEB DE LA UG”
El siguiente manual técnico tiene como objetivo mostrar la estructura del
programa, así como las configuraciones que se deben realizar para integrar
aplicaciones clientes con el sistema de autenticación del proyecto de
titulación “Implementación de un Sistema Centralizado de Autenticación
para los usuarios de las diferentes aplicaciones web de la UG”.
Arquitectura de N capas
El desarrollo de programas por capas es una arquitectura de programación
cuyo objetivo primordial es la separación de la lógica de negociación con la
lógica del diseño.
Esta arquitectura tiene como ventaja que, al realizar el desarrollo en varios
niveles, y en el caso que se tenga que realizar un cambio, solo se
modificará la capa requerida sin tener que modificar el resto de la
programación. Además, al tener varias capas se puede distribuir el trabajo
de desarrollo por niveles obteniendo varios grupos de trabajo, y para
comunicar los niveles bastará con conocer las Apis de comunicación por
niveles.
Manual Técnico
La arquitectura más utilizada es la siguiente:
1. Capa de Presentación: Es la parte que el programa presenta al
usuario, es decir la interfaz gráfica, presentará o capturará la
información solicitada por el usuario. Esta capa sólo se comunicará
con la capa de negocio.
2. Capa de Negocio: Es la lógica del negocio donde se alojan los
programas que se ejecutan, realiza los procesos de comunicación.
Se comunica con la capa de presentación para recibir lo solicitado y
enviar la información, también se comunica con la capa de datos
para guardar o recuperar información del gestor de base de datos.
3. Capa de Datos: Es donde se alojan los datos o información y es la
que se encarga del acceso de los mismos. Se comunica con la capa
de negocio para recibir solicitud de almacenamiento o recuperar
información.
Arquitectura de capas del Sistema Centralizado de
Autenticación de la Universidad de Guayaquil
El sistema de autenticación de este proyecto se desarrolló siguiendo la
arquitectura N capas.
Para el desarrollo del Sistema Centralizado de Autenticación se hace uso
de Identity Server4 como sistema de autenticación.
Este sistema está compuesto por 4 capas que son las siguientes:
1. Capa de Presentación
2. Capas de Servicios
3. Capa de Dominio
4. Capa de Infraestructura
Además, dos capas adicionales que son:
5. Capa de Integración: Es la que contendrá los servicios de
aplicaciones externas que se pueden integrar con este sistema
de autenticación.
6. Capa Transversal: Se encuentras clases que serán utilizadas
por el programa.
1. Capa de presentación
Es la capa donde interactúa el usuario, en la programación web es la parte
HTML o conocida como la parte visual. Tiene una lógica interna que no es
la lógica de negocio, pero tiene una lógica para manejar todo lo que recibe
de la capa de negocio, maneja la información para presentársela al usuario
de una forma que sea entendible e interpretable.
Esta capa contiene los siguientes archivos:
1.1. Constants.cs:
Son Constantes usadas en el proyecto.
1.2. Program.cs:
Es el que inicializa la aplicación.
1.3. Startup.cs:
Es el punto de partida de ASP.NET, aquí se configuran todos
los servicios que se utilizan en la aplicación, se debe tener
estas configuraciones para integrar una aplicación cliente en
el servidor de autenticación.
Dentro de ConfigureServices(IServiceCollection services) están
declarados los servicios siguiendo la siguiente estructura:
Autenticación
La autenticación se configura en services.AddAuthentication
Cookies
Los cookies son configurados en AddCookie
IdConnect
Para permitir el acceso al aplicativo se debe configurar.
AddOpenIdConnect
Al final publicamos el servicio de autenticación.
2. Capa de Servicios
Puede considerarse como la primera parte de una capa de negocio, es la
capa que expone los servicios, pero no realiza todo el negocio hacia el
cliente, se encarga de manejar las peticiones del cliente.
Contiene los siguientes archivos:
2.1. Services.IdentityServer: Es una página web, pero que no está
en la capa de presentación porque el usuario no interactúa con
esta, sino que es un servicio ofrecido a la capa de presentación,
en este caso el login. Esta capa solo expone la lógica de
negocio, pero aquí no está la lógica de negocio. Se encarga del
ingreso de la autorización, pero el manejo de la autorización no
se realiza aquí, sino que en las capas más bajas.
2.1.1. appsettings.json
Es el archivo de configuración del servicio, cuando se lo
modifica se debe reiniciar el servicio.
Dentro de este archivo hay un segmento llamado
IdentityServerConfig en donde se deben configurar:
ApiResources
Son los servicios que son protegidos por el servidor de
autenticación, son servicios Rest.
El campo que se debe llenar es Name el cual contiene el nombre del
recurso y creará un scope del mismo nombre, los nombres que se usen
aquí se deben poner en los clientes que tienen permisos a estos recursos.
Aquí se configuran las Apis que puede otorgar Identity Server4, pero para
las aplicaciones web no se las está utilizando.
Clients
Es donde se definen las aplicaciones clientes que pueden hacer uso de los
servicios de Identity Server. Estas configuraciones son esenciales para que
una aplicación pueda usar los servicios de este sistema de autenticación.
ClienID: Es el Id para la aplicación cliente.
AllowedGrandTypes: Valores fijos de OpenAuth.
RequireConsent: Página de consentimiento si es que se la usa,
por lo que no la usamos queda en falso.
ClientSecrets: Es la contraseña para la aplicación cliente.
AccessTokenLifetime: Es el tiempo de vida del token que se
otorgará al usuario para el acceso a la aplicación cliente.
AllowedScopes: Son los recursos a los cuales tiene permisos la
aplicación cliente.
RedirecUrls: Son las URls a las que se puede redirigir el
aplicativo cliente cuando se autentica.
PostlogoutRedirectUrls: Son las urls a las que se pude redirigir
el aplicativo cliente cuando cierra sesión.
AllowOfflineAccess: Para permitir el acceso fuera de línea.
Enable: Si está habilitado el aplicativo cliente podrá integrarse
con IdentityServer4.
3. Capa de dominio
Puede considerarse en sí como la capa de negocio, donde se encuentra
toda la lógica del programa. Tiene que utilizar todas las conexiones a los
datos, está dividido en una abstracción y en una implementación.
3.1. Domain.Base: Es la abstracción de la lógica de negocio, aquí
están todas las interfaces conocidas como servicios a nivel de
programación llamados Services, los cuales son la lógica de
negocio, estos servicios no están expuestos a nivel web, más
bien realiza una tarea específica. Dentro de Domain.Base se
encuentran el siguiente servicio, en forma modular, son los
módulos de seguridad
3.1.1. ISecurityService.cs: Funciona como módulo de
seguridad, aquí se encuentran todos los métodos los cuales son:
GetUserById: Obtiene a un usuario por su Id.
GetUserByUsername: Obtiene a un usuario por su nombre de
usuario.
Authenticate: Autentica al usuario recibiendo un comando y
retornando una respuesta.
RegisterUser: Registra a un usuario recibiendo un comando y
retornando una respuesta.
UpdateUserInfo: Actualiza la información de un usuario
ClearUserSession: Borra el inicio de una sesión.
3.2. Domain.MainModule:
Donde está la implementación de la lógica de negocio.
3.2.1. SecurityService.cs:
Es la implementación del módulo de seguridad en donde se
incluye el manejo de usuarios y perfiles.
4. Capa de infraestructura
Es la capa que accede a la información almacenada.
4.1. Infraestructure.Base:
Es la abstracción de los repositorios.
4.2. Infraestructure.Siug:
Es la implementación de las abstracciones de los repositorios.
5. Capa de Integración:
Es el cliente de integración de los servicios que son otorgados por la
universidad de Guayaquil.
5.1. Integration.SiugApi:
Es el cliente de integración de los servicios.
6. Transversal
Sólo son clases definidas que van a ser utilizadas por todas las capas, aquí
no hay métodos ni lógica de negocio con propiedades. Se creó estas
clases para no recrearlas en todas las capas, sino que sólo se hagan una
referencia a estas clases.
6.1. Transversal.ApplicationCodes:
Son los códigos de error.
6.2. Transversal.Encryption:
Es la librería de encriptación.
6.3. Transversal.Extensions:
Librería de extensiones.
6.4. Transversal.Models:
Las clases compartidas.
6.5. Transversal.ResourceLibrary:
Clases de librerías.