Hola Dos comentarios:
Sobre el software: ¿Has mirado el Request Tracker? http://www.bestpractical.com/rt/ Sobre autenticación: ¿Has pensado en openid? Quizás la siguiente presentación te aclare cómo usar openid de manera sencilla: http://www.rediris.es/difusion/eventos/foros_movilidad-identidad/2011/ponencias/doc/MiguelMacias-openID.pdf Lo que he entendido es quieres es delegar la autenticación fuera de la aplicación (no sé si la autorización también), es decir que la aplicación se comporte como un SP que se conecte a un IDP. Lo que no me queda claro es en qué IDP estas pensando, ¿en el de la EHU?, ¿en uno propio?, ¿en uno externo (por ejemplo, google como idp)?,.. Saludos Libo El 23/01/2013, a las 17:10, Javier Domingo <[email protected]> escribió: > Buenas, > > Me llamo Javier Domingo, soy alumno de ETSIB (Teleco telemática), miembro del > CEC y me falta el PFC para acabar la carrera. > > Estoy intentando poner en marcha un método que facilite la comunicación entre > alumnos y consejos de estudiantes, al menos de momento solo me centro en eso, > si sale bien, mi idea es conseguir incluir también el sector de PAS/PDI. > En estos momentos, estoy centrando mi trabajo en conseguir hacer un FAQ para > que los alumnos puedan encontrar soluciones a diferentes dudas que se nos > plantean a menudo de una forma informatizada y automática. > > Para ello, he creado un blog de wordpress, e instalando unos plugins, he > creado el FAQ. De momento no lo he publicado, ya que quiero probarlo de > diferentes maneras a ver si es una plataforma efectiva. > > De esta manera, conseguiría hacer llegar a los alumnos respuestas a preguntas > frecuentes. > > Pero con esto no basta. En un principio había pensado en solicitar acceso por > parte de los CEC a las listas de distribución de correo que tienen los > profesores para cada asignatura, para posibilitar enviar correos de una forma > que no nos dejaramos a nadie, por ejemplo, para avisar de una solicitud de > cambio de horario, etc. > Ya que actualmente, los delegados tienen serias dificultades para ponerse en > contacto con sus representados, también había pensado en hacerlo todo junto. > > El problema con esto era conseguir evitar un uso ilícito del acceso al > servicio de distribución de correo por parte del delegado. Además, requeriría > contactar con los técnicos informáticos para cambiarlos todos los años, y > formar a los delegados, en caso de dárseles acceso. > Viendo que la solución de la lista de distribución no es óptima, tras > reportar un bug, me di cuenta de que un bug tracker sería perfecto en este > caso, además recordé la interfaz de lagun.ehu.es. > El problema con esto, es que requeriría maquillar la interfaz para eliminar > la palabra bug (por ejemplo), además de adaptar el funcionamiento para que > cualquiera pudiera crear un ticket, y fuera el CEC el encargado de asignarlo > al que correspondiera, además de suscribir a los alumnos que fuera necesario. > Con esto empecé poco a poco, instalé el bugzilla, y tras varias pruebas y > echar un vistazo al código, migré a eventum (plataforma de mysql). También he > probado otras plataformas de gestión de tickets, pero ninguna acababa > adaptandose perfectamente. > Por lo que una pregunta tras toda esta explicación es, ¿Conocéis alguna > plataforma (opensource y gratuita) que se adapte a las > necesidades/funcionamiento que he descrito, o al menos, sabéis de alguna que > se acerque más que eventum? > Otra de las cosas que he ido haciendo paralelamente ha sido la autenticación > de los usuarios. Uno de los problemas que me planteaba era que tenía que > registrar (u obligarles a registrarse) a los usuarios que quisieran utilizar > la plataforma. > > A través del funcionamiento de los ordenadores de los centros de cálculo, > aprendí a autenticar usuarios, e incluso, a hacer un filtrado por centros. > > Configuré bugzilla para que autenticara usuarios primero contra el LDAP y > luego contra la BBDD local, pero por diseño, está preparado para además de > autenticarlos, guardar la contraseña. Y esto definitivamente no podía ser > (aún estando en hash). > > En ese momento me pasé a Eventum, y empecé a modificarlo para que apache se > encargara de autenticar usuarios, evitando así que la contraseña pasara por > el programa. > > El problema con esto era que las contraseñas seguían pasando por el servidor, > cosa que yo definitivamente no veo bien (estoy más a favor de las plataformas > OAuth), y me puse a buscar sobre otros métodos que utiliza la universidad > para autenticar usuarios. > Buscando, dí con esta página[1], que se utiliza para autenticar usuarios > utilizando algo parecido al OAuth, pero bastante más trivial. > > Empecé a explorar como tiene la universidad montada la autenticación de un > servicio externo. En la página[1] se redirige a la página de rediris para > identificar el servicio que se quiere autenticar[2]. > > Mirando en la página de SIR de rediris, y mirando el código que se provee a > las entidades, pude identificar que utiliza PAPI. Por lo tanto, ya solo me > falta conseguir la clave pública del servidor de login para poder comprobar > la firma del servidor. > > La verdad es que todavía no me he puesto a diseñar ni modificar el software > que irá por debajo para poder autenticar usuarios, ya que primero quería > preguntaros si conocéis algún método más estandar que esté implantado en la > universidad. > > Si tenéis alguna sugerencia, idea o información que me podría ayudar a poner > en marcha este proyecto, estaré encantado de leerlas, > > Un saludo, > > Javier Domingo > > P.D.: Siento haberme extendido tanto, pero creo que ahorra más pasos si se > explica la problemática al completo > > [1] msdn e-academy: http://msdn30.e-academy.com/upv_ehu > > [2] sir rediris eacademy, ehu: > https://sir.rediris.es/msdnaa/?hli=EHUsirAS&action=signin > > [3] SIR rediris: http://www.rediris.es/sir/ > > [4] EHU login: https://login.ehu.es/login/formLogin.php > > Esta cabecera ha sido añadida automáticamente por la Vicegerencia de las TIC: > -------------------------------------------------------------------------------- > ATENCION!! Este correo contiene la palabra "contraseña" y puede tratarse de > un fraude. > No proporcione nunca sus credenciales por correo electrónico. > Si tiene alguna duda consulte con el CAU (154400). > UPV/EHU, Vicegerencia de las TIC > > ERNE!! Mezu honek "contraseña" hitza dauka eta iruzurrezko mezua izan daiteke. > Ez eman inoiz zure pasahitza posta elektronikoaren bidez. > Zalantzarik izanez gero deitu BAZren telefonora (154400) > UPV/EHU, IKT Gerenteordetza > -------------------------------------------------------------------------------- > · > _______________________________________________ > ITSAS mailing list > [email protected] > http://list.ehu.es/mailman/listinfo/itsas
_______________________________________________ ITSAS mailing list [email protected] http://list.ehu.es/mailman/listinfo/itsas
