Rubycas-Server Implementación de código abierto de un servidor JA-SIG CAS para autenticación de inicio de sesión único para aplicaciones web empresariales
Descargar ahora

Rubycas-Server Clasificación y resumen

Rubycas-Server Etiquetas

servidor Aplicación Web autenticar servidor CAS Autenticación de la aplicación web Autenticación CAS

Rubycas-Server Descripción

Implementación de código abierto de un servidor JA-SIG CAS para autenticación de inicio de sesión único para aplicaciones web empresariales RUBYCAS-Server proporciona una solución de inicio de sesión única para aplicaciones web, implementando el extremo del servidor del protocolo CAS de JA-SIG. CAS permite la autenticación de inicio de sesión de una sola y central para múltiples aplicaciones web que se ejecutan en varios marcos (Java, Rails, PHP, etc.), la idea es similar a la forma en que Yahoo, Google y otros sitios principales del portal permiten al usuario autenticarse usando usando Una página de bienvenida central. Del mismo modo, su servidor CAS proporciona la página de inicio de sesión donde el usuario ingresa su nombre de usuario y contraseña. Después de la autenticación exitosa, el servidor elimina 'Boletos de servicio' que otorgan acceso a los diversos servicios protegidos por CAS. Sus servicios protegidos por CAS nunca ven las credenciales reales del usuario, y el inicio de sesión en un servicio otorga acceso a todos los demás servicios. El usuario solo ve la página de inicio de sesión una vez, por lo que el "inicio de sesión único" .Rubycas-Server está diseñado para ser fácil de configurar y personalizar. No necesita saber nada de Ruby para ejecutar el servidor. El extremo frontal (la página de inicio de sesión central) se puede desollar utilizando CSS, y el método de autenticación de back-end para validar los nombres de usuario y las contraseñas se puede configurar para usar una base de datos SQL existente, Active Directory, LDAP Server, etc. para obtener más información sobre el Protocolo CAS, eche un vistazo a la página oficial de JA-SIG CAS.En para que sus servicios (es decir, sus aplicaciones web) protegidas contra CAS, cada servicio requerirá alguna configuración. En general, esto se hace instalando una biblioteca de clientes CAS. Por ejemplo, para una aplicación Ruby On Rails, tendrá que instalar Rubycas-Client, que esencialmente actúa como un filtro de controlador estándar. Para PHP, instale ESUP-PHPCAS e incluya un pequeño bloque de código en la parte superior de sus páginas PHP protegidas por CAS. Para los marcos basados ​​en Java, tendrá que instalar el cliente Java CAS y agregar un número XML a la configuración del servidor de la aplicación. Eche un vistazo a la página JA-SIG CAS LISTENTS para obtener información sobre los clientes para otros marcos (.NET, Perl, Zope, ColdFusion, etc.). ¿Qué hay de nuevo en este lanzamiento: Nueva funcionalidad: · Implementada funcionalidad de inicio de sesión único como se especifica en CAS 3.3. Consulte http://www.ja-sig.org/wiki/display/casum/single+sign+out. · Ahora es posible configurar autenticadores para devolver los atributos adicionales a los clientes de CAS junto con el nombre de usuario. Para un ejemplo de cómo hacer esto, vea el autenticador SQL incluido. También eche un vistazo a: http://groups.google.com/group/rubycas-server/browse_thread/thread/5edee3793cb590e9 Tenga en cuenta que los atributos adicionales del tipo que no sean cadena o numéricos sean serializados en formato YAML antes de enviarlo al cliente. . · Se agregó una versión MD5-contraseña del autenticador SQL para Drupal y cualquier otra base de datos que almacene sus contraseñas en formulario hash (gracias Malcolmm). · Se agregó un nuevo autenticador de Google para autenticar las cuentas de Google / Gmail. Cambios en la funcionalidad existente: · El servicio URIS ahora se normalizan automáticamente. Por ejemplo, si el Servicio URI dado al servidor tiene un parámetro 'Ticket', el boleto ahora se eliminará automáticamente. Esto es para evitar cualquier problema posible planteado por mal comportamiento de los clientes CAS (el boleto CAS nunca debería ser parte del Servicio URI). Lo mismo ocurre con otros parámetros relacionados con CAS como 'Service', 'Renovación', y 'Gateway'. Además, el arrastre '/' y '?' Los caracteres se eliminan automáticamente de las URL, ya que, por ejemplo, "http://google.com/" es casi seguramente equivalente a "http://google.com". · La variable de configuración de Expire_Sessions ahora se respeta: las cookies de tickets de otorgamiento de boletos se establecen con un datetime de caducidad, de modo que la sesión de la SSO se termina efectivamente una vez que se alcanza el período Ticket_Granting_Ticket_Expiry. · Si está presente, el encabezado http_x_forwarded_for se usa para registrar la dirección del cliente. Esto es útil cuando el servidor se está ejecutando detrás de un proxy inverso, pero no debe considerarse autoritario, ya que se puede falsificar fácilmente. · El campo 'Servicio' en la tabla 'Casserver_st' se ha cambiado de VarChar (255) a texto para acomodar a URI de servicio a más de 255 caracteres (Corrige el problema # 46). · Las respuestas CAS XML ya no están formateadas en el espacio en blanco (es decir, la autoindenación automática de Markaby se ha desactivado). Al parecer, el espacio en blanco estaba causando problemas con MOD_AUTH_CAS. Ver: http://groups.google.com/group/rubycas-server/browse_thread/thread/e482fe09999b73d3 · Cuando se usa sin la autenticación previa, el autenticador LDAP ahora intenta enlazar buscando el nombre de usuario dado en el directorio LDAP según el Username_Attribute configurado. Antes de este cambio, el autenticador intentó enlazar con el servidor LDAP asumiendo que la credencial de nombre de usuario coincide con la CN del usuario. Este ya no es el caso. · Respuestas CAS a solicitudes no válidas (por ejemplo, donde faltan los parámetros requeridos o incorrectos) ahora tendrá un código de estado HTTP 422. Los errores internos del servidor (donde el servidor en lugar del cliente tiene la culpa). HAY ERROR 500. Anteriormente, la mayoría de las respuestas tenían un código de error 200, independientemente de sus contenidos. Corrección de errores: . · Cuando se ejecuta bajo Mongrel, la señal USR2 ahora debe reiniciar el servidor como se esperaba, sin embargo, actualmente esto funciona solo cuando el servidor se está ejecutando en la anterior. Cuando Daemonized, USR2 cerrará el servidor sin reiniciar (consulte el número 58). · Problemas fijos de carga de ACTIVERECORD / ACTIVESUPPORT GEM, con suerte de una vez por todas (sin embargo, ahora se requiere Picnic-0.7.0).

Rubycas-Server Software relacionado