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

[email protected] [email protected]

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



CARRERA DE INGENIERÍA EN NETWORKING Y

TELECOMUNICACIONES




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:




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



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”

mailto:[email protected]

mailto:[email protected]

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° 10 MEDICIÓN DE RESULTADOS – PREGUNTA 4 ...........71





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 21 Proceso de Inicio de Sesión ...................................................85

Gráfico 22 Página de login .......................................................................86

Gráfico 23 Actualizar datos ......................................................................87

XXI


FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS CARRERA DE INGENIERÍA EN NETWORKING Y

TELECOMUNICACIONES

IMPLEMENTACIÓN DE UN SISTEMA CENTRALIZADO DE


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


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.



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



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


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



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



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)


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)


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)


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)


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)


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)


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



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



(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



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



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.

http://ec2-54-149-21-181.us-west-2.compute.amazonaws.com/

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

https://servicioenlinea.ug.edu.ec/SIUG/Default.aspx

49

Gráfico 12 Página SIUG



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



CUADRO N° 6 CUADRO DISTRIBUTIVO DE LA MUESTRA

Muestra Cantidad

ESTUDIANTES Y PROFESORES 398

TOTAL 398



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%



Gráfico 13 Medición De Resultados – Pregunta 1



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).



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%






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).



Si

283

71%

No

115

29%

Total

398

100%






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).



Mediante un administrador de sistema

258 65%

Vía web 21 5%

Otro 4 1%

No lo he requerido 115 29%

Total

398

100%






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).



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%






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?








94 24%


Total 398 100%






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%




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).


Alternativas de respuesta

Alternativas marcadas

Porcentaje de alternativas marcadas





8 2%


Total 398 100%






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%




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).


Alternativas de respuesta

Alternativas marcadas Porcentaje de alternativas marcadas





7 2%


8 2%

Total 398 100%






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%




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


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


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



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



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



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



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



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



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.



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


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%



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?







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).






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?




о No me parece relevante



Anexo 2

Manual técnico




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.

UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS...

Documents

Transcript of UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS...