On Dec 5, 2007 1:54 PM, Asdtaker <[EMAIL PROTECTED]> wrote: > Estimados, mi ultima consulta aqui fue respecto de un cliente para jabber (y > ya vieron lo que ocurrio (y esta ocurriendo)). Finalmente, se opto por > openfire y spark como cliente, lejos las discusiones respecto a la > performance del modelo, ya esta implementado y camina /de pelos/. Gracias a > todos lo que dieron sus opiniones. > > Esta vez, los molesto con otra cosa que me aflije. Tengo algunos servicios > con db (mysql, db2, sql server) y existe un gran cuestionamiento: ¿como > escondo las password (y usuarios) de las db a los programas y usuarios?. Es > decir, pe. al configurar el acceso a mysql para un servicio web (LAMP), > necesariamente debo configurar en un file la passwordm user y database que > utilizare. Otro problema, y mas grande aun, en cuando tenemos aplicaciones > cliente-servidor, con archivos de configuracion en cada cliente, o bien (en > el caso sql server) odbc, en ese caso no existe manera de encriptar las > password, y al menos debe conocerla el desarrollador/analista de la > aplicacion y configurarla (digitarla) bien en el codigo (ejecutable) o en un > archivo de configuracion. Mi problema es que necesito que estas password no > sean conocidas por nadie, ni siquiera el admin del sistema (password > bipartida) y el dia de mañana poder cambiarlas de manera transparente para > los usuarios. > > He hecho monos, tirado lineas y buscado en san google, pero ando medio > perdido. Espero me puedan orientar. > > Mis ideas me llevan a pensar que debe haber /algo/ en medio que permita la > autenticacion, es decir: > > SERVER(user, pass)<:::::::::>**ALGO**<:::::::::>CLIENTE(user, _clave_) > > donde clave, es una llave, un id de instalacion, la ip de mi LAN, el usuario > de dominio, etc.
Tienes un problema de arquitectura o disen~o, algunos tips te dio Franco. Esto se resuelve implementando servicios y creando una capa de acceso a el (bus de servicios). El bus se encarga de la seguridad, acceso, enrutamiento, excepciones, auditoria, etc. Puedes implementarlo con muchas tecnologias y maneras, varias ya estan hechas. Luego, lo que le das a tu desarrollador es una API o framework que encapsula el acceso al bus y lo mas importante, a los servicios que tiene acceso (esto independiza la tecnologia usada). Los accesos (permisos) los defines en el servidor o en el bus. Cualquier otro chamullo no te asegura nada. Si creas una DLL que "encripta" la password por otra, es lo mismo, igual estas dando full acceso a la base de datos (basta descompilar la dll o revisar el stream a la conexion para saber que user/pass estas usando). Si creas una DLL que realiza el servicio, estas duplicando codigo y eso lo hace inmantenible, la logica del servicio tiene que estar donde se provee (en el servidor) y el cliente solo debe tener una API para accesar a el, que depende de la tecnologia usada. Hay muchas otras razones para implementar esta arquitectura (un unico punto con la logica, tienes un mecanismo de auditoria, generalmente el bus te garantiza que no se pierden los datos, permite especializar los sistemas, integrar sistemas antiguos y mejorar la performance ya que los servidores trabajan en base a eventos en vez de a full conexiones, ...); pero en particular resuelve tu problema de acceso a los datos, ya que no abres de patas la base de datos, sino que solo a servicios bien conocidos y definidos. Puedes encontrar un monton de buzzwords al respecto, estoy buscando alguna literatura que te pueda ayudar a entender un poco el asunto.... Creo que este link te servira: http://www-306.ibm.com/software/info1/websphere/index.jsp?tab=landings/esbbenefits Saludos, -- Aldrin Martoq
