Configurar CAS en Tomcat
CAS?Principio y protocolo
Estructuralmente, CAS?se compone de dos partes: CAS?Servidor y CAS?Cliente. El servidor CAS debe implementarse de forma independiente y es el principal responsable de la autenticación del usuario; el cliente CAS es responsable de procesar las solicitudes de acceso a los recursos protegidos del cliente y redirigir al servidor CAS al iniciar sesión. La Figura 1 es el proceso de protocolo más básico de CAS:
Figura 1. Protocolo básico de CAS
El cliente CAS se implementa con la aplicación cliente protegida y protege los recursos protegidos en modo de filtro. Para cada solicitud web que accede a un recurso protegido, el Cliente CAS analizará si la solicitud Http contiene un Ticket de servicio. De lo contrario, significa que el usuario actual no ha iniciado sesión, por lo que la solicitud será redirigida para especificar la dirección de inicio de sesión del servidor CAS. pasar el Servicio (es decir, la dirección del recurso de destino al que se accederá) para que pueda transferirse nuevamente a esta dirección después de iniciar sesión correctamente. El usuario ingresa la información de autenticación en el paso 3. Si el inicio de sesión es exitoso, el servidor CAS genera aleatoriamente un ticket de servicio de longitud considerable, único e imposible de falsificar, y lo almacena en caché para verificación futura, después de lo cual el sistema lo redirige automáticamente a la dirección de servicio. y configure una Cookie concedida de ticket (TGC) para el navegador del cliente. Después de que el Cliente CAS obtenga el Servicio y el Ticket recién generado, en los pasos 5 y 6, asegúrese de que la identidad sea apropiada con el Servidor CAS para garantizar la legitimidad del Ticket de servicio.
En este protocolo, todas las interacciones con CAS utilizan el protocolo SSL para garantizar la seguridad de ST y TGC. Habrá dos procesos de redirección durante el proceso de trabajo del protocolo, pero el proceso de verificación del ticket entre el cliente CAS y el servidor CAS es transparente para el usuario.
Además, el protocolo CAS también proporciona un modo Proxy para adaptarse a escenarios de aplicaciones más avanzados y complejos. Para una introducción detallada, consulte los documentos relevantes en el sitio web oficial de CAS.
Trabajo de preparación
Los ejemplos de este artículo toman ?tomcat5.5? como ejemplo, dirección de descarga:
¿plicados?como?escanear?el ?información?contenida?en?el?objeto *?Credenciales?.? *?@param?credenciales?Las?credenciales?a?verificar *?@return?true?si?el?controlador?admite?las?Credenciales,? false?othewrise. */
boolean?supports(Credentials?credentials);
}
Esta interfaz define ?2? El método support?() se utiliza para comprobar si las Credenciales dadas que contienen información de autenticación son compatibles con el medio actual que almacena la información de autenticación legal y devuelve un valor de tipo "booleano" que significa que la verificación ha pasado. , falso? significa que la verificación ha fallado.
CAS3 también proporciona algunas implementaciones abstractas de la interfaz AuthenticationHandler. Por ejemplo, es posible que necesite realizar otras operaciones antes y después de ejecutar el método authenticate(), para poder extender su propia clase de autenticación. el manifiesto? Clase abstracta en 2:
Listado 2. Definición de AbstractPreAndPostProcessingAuthenticationHandler
¿public?abstract?class?AbstractPreAndPostProcessingAuthenticationHandler?
implementos?AuthenticateHandler{
protected?Log?log?=?LogFactory.getLog(this.getClass());
protected?boolean?preAuthenticate(final?Credentials?credentials)?{
return?true;
}
¿protegido?booleano?postAuthenticate(¿final?Credenciales?credenciales,
¿final?booleano?autenticado)?{
return?authenticate;
}
public?final?boolean?authenticate(final?Credentials?credentials)
lanza?AuthenticationException?{< / p>
if?(!preAuthenticate(credenciales))?{
return?false;
}
final?boolean?authentiated?= ? doAuthentication(credenciales);
return?postAuthenticate(credenciales,?authenticado);
}
protegido?abstracto?booleano?doAuthentication(final?Credenciales? credenciales )?
throws?AuthenticationException;
}
La clase AbstractPreAndPostProcessingAuthenticationHandler? define recientemente el método preAuthenticate() y el método postAuthenticate(), y el trabajo de autenticación real es realizado por el método doAuthentication(). Por lo tanto, si necesita realizar algunas operaciones adicionales antes y después de la autenticación, puede extender los métodos preAuthenticate() y ppstAuthenticate() respectivamente, y doAuthentication() reemplaza a authenticate() como un método que las subclases deben implementar.
Dado que en las aplicaciones reales, el método de autenticación más utilizado es el nombre de usuario y la contraseña, CAS3 proporciona una implementación para este método, como se muestra en el Listado 3:
Listado 3.?AbstractUsernamePasswordAuthenticationHandler ?Definición
¿pública?abstracta?clase?AbstractUsernamePasswordAuthenticationHandler?extiende?
AbstractPreAndPostProcessingAuthenticationHandler{
... protected?final?boolean?doAuthentication( final?Credentials? credenciales) throws?AuthenticationException?{ return?authenticateUsernamePasswordInternal((UsernamePasswordCredentials)?credentials); } protected?abstract?boolean?authenticateUsernamePasswordInternal(
final?UsernamePasswordCredentials?credentials)?throws?AuthenticationException;
protected?final?PasswordEncoder?getPasswordEncoder()?{ return?this.passwordEncoder }
public?final?void?setPasswordEncoder(final?PasswordEncoder?passwordEncoder)?{ this.passwordEncoder ?=?passwordEncoder ;
}
...
}
¿El método de autenticación basado en el nombre de usuario y la contraseña se puede extender directamente desde AbstractUsernamePasswordAuthenticationHandler, la operación específica de verificar el nombre de usuario y la contraseña se logra implementando el método ?authenticateUsernamePasswordInternal()? Además, la contraseña generalmente está cifrada y el método setPasswordEncoder()?
Como puede ver en la lista anterior, los parámetros del método doAuthentication() son del tipo Credenciales. Esta es una interfaz que contiene información de autenticación de usuario. Para información de autenticación de tipo de nombre de usuario y contraseña, puede. Úselo directamente. ?UsernamePasswordCredentials. Si necesita ampliar otros tipos de información de autenticación, debe implementar la interfaz Credentials e implementar la interfaz ?CredentialsToPrincipalResolver? Los métodos específicos se pueden aprender de ?UsernamePasswordCredentials?
¿JDBC? ¿Método de autenticación?
La información de autenticación del usuario generalmente se almacena en la base de datos, por lo que este artículo utilizará este caso para presentarla.
Después de descomprimir el paquete cas-server-3.1.1-release.zip descargado anteriormente, puede encontrar el paquete cas-server-support-jdbc-3.1.1.jar en el directorio de módulos, que proporciona la implementación predeterminada de ?JDBC ? conectarse a la base de datos para la autenticación. Según el soporte de este paquete, solo necesitamos realizar algunos trabajos de configuración para lograr la "autenticación JDBC".
El método de autenticación JDBC admite una variedad de bases de datos, incluidas DB2, Oracle, MySql, Microsoft SQL Server, etc. Aquí, se utiliza DB2 como ejemplo. Y supongamos que el nombre de la base de datos DB2: ?CASTest, el nombre de usuario de inicio de sesión de la base de datos: ?db2user, la contraseña de inicio de sesión de la base de datos: ?db2password, la tabla de información del usuario es: ?userTable, la tabla contiene dos elementos de datos de nombre de usuario y contraseña, ? nombre de usuario? y contraseña.
1. Configurar DataStore
Abra el archivo %CATALINA_HOME%/webapps/cas/WEB-INF/deployerConfigContext.xml y agregue una nueva etiqueta de bean para ?DB2, el contenido es el mismo. se muestra en el Listado ?4:
Listado?4.?Configuring?DataStore
El atributo ?id? es la identificación del ?DataStore?, y el ?AuthenticationHandler se configurará más adelante, además. , debe proporcionar el controlador de la base de datos, la dirección de conexión, el nombre de usuario de inicio de sesión de la base de datos y la contraseña de inicio de sesión necesarios para DataStore.
2. Configurar AuthenticationHandler
En el paquete cas-server-support-jdbc-3.1.1.jar, 3 ?AuthenticationHandler basados en JDBC, respectivamente?BindModeSearchDatabaseAuthenticationHandler,?QueryDatabaseAuthenticationHandler,? SearchModeSearchDatabaseAuthenticationHandler.
Entre ellos, ?BindModeSearchDatabaseAuthenticationHandler? utiliza el nombre de usuario y la contraseña proporcionados para establecer una conexión a la base de datos y determina si la autenticación es exitosa o no en función de si la conexión se estableció correctamente; y coincide con la contraseña proporcionada; SearchModeSearchDatabaseAuthenticationHandler? Verifique configurando la tabla, el campo de nombre de usuario y el campo de contraseña que almacenan la información de verificación del usuario y construyendo una declaración de consulta.
Qué AuthenticationHandler usar debe configurarse en desplegarConfigContext.xml. De forma predeterminada, CAS usa un AuthenticationHandler simple con nombre de usuario=contraseña. La siguiente línea se puede encontrar en el archivo: < bean?class="org. .jasig.cas.authentication.handler.support.SimpleTestUsernamePassword
AuthenticationHandler"?/>, ¿podemos comentarlo y reemplazarlo con el que queramos? AuthenticationHandler, por ejemplo, use QueryDatabaseAuthenticationHandler o SearchModeSearchDatabaseAuthenticationHandler puede seleccionar la configuración del Listado 5 o Listado 6 respectivamente.
Listado 5. Uso de QueryDatabaseAuthenticationHandler
value="select?password?from?userTable?where?lower(userName)?=?lower(?) "?/ Listado 6. Uso de SearchModeSearchDatabaseAuthenticationHandler autowire="default"?dependency-check="default" > Además, dado que las contraseñas almacenadas en la base de datos generalmente están cifradas, ?AuthenticationHandler? necesita conocer el método de cifrado utilizado al hacer coincidir, en el archivo desplegarConfigContext.xml. podemos configurar una propiedad para una clase AuthenticationHandler específica y especificar la clase de cifrado. Por ejemplo, para QueryDatabaseAuthenticationHandler, se puede modificar como se muestra en el Listado 7: Lista 7.?Add?passwordEncoder valor="seleccionar?contraseña?de?tabla de usuario?dónde?inferior( userName)?=?lower(?)"?/> dónde?myPasswordEncoder ?es una referencia a la clase de cifrado real establecida en el Listado?8?: Listado?8.?especifica la clase de cifrado específica class="org.jasig.cas.authentication.handler.MyPasswordEncoder"/> Aquí?MyPasswordEncoder?es un cifrador autodefinido basado en la situación real, que implementa?PasswordEncoder ?interfaz y su método "encode()". 3. ¿Implementar paquetes dependientes? Una vez completada la configuración anterior, debe copiar varios paquetes dependientes a la aplicación cas. Incluyendo: ¿Copiar ?cas-server-support-jdbc-3.1.1.jar? al directorio ?%CATALINA_HOME%/webapps/cas/?WEB-INF/lib? Controlador de base de datos, ya que aquí se usa DB2, copie db2java.zip (renombrado a db2java.jar), db2jcc.jar, db2jcc_license_cu.jar en el directorio %DB2_HOME%/java a %CATALINA_HOME%/webapps/cas/WEB-. Directorio INF/lib? Para otras bases de datos, copie también el controlador de base de datos correspondiente. DataStore? depende de ?commons-collections-3.2. , commons-pool-1.3.jar, debe descargar los 3 paquetes anteriores del proyecto Commons del sitio web de Apache y colocarlos en el directorio %CATALINA_HOME%/webapps/cas /WEB-INF/lib? Interfaz?CAS?Servidor?extendida CAS?proporciona?2?conjuntos de páginas predeterminadas, a saber, "?default?" y "?simple?", respectivamente en los directorios "?cas/WEB -INF/view/jsp/default?" y "?cas/WEB-INF/view/jsp/simple?". La página "predeterminada" es un poco más compleja que utiliza "CSS", mientras que la "simple" es la página más simple que permite que "CAS" funcione correctamente. Antes de implementar CAS, es posible que necesitemos personalizar una nueva página del servidor CAS y agregar contenido personalizado. La forma más sencilla es copiar un archivo "predeterminado" o "simple" al directorio "?cas/WEB-INF/view/jsp?", por ejemplo, asígnele el nombre ?newUI. ?Se requieren 4? páginas: casConfirmView.jsp:?La interfaz de confirmación que se verá cuando el usuario seleccione "?advertir?" casGenericSuccess.jsp:? ¿Interfaz que aparecerá cuando el usuario pase exitosamente la autenticación sin el servicio de destino? casLoginView.jsp:?¿La interfaz que aparecerá cuando se le solicite al usuario que proporcione información de autenticación? casLogoutView.jsp:? ¿La interfaz que aparece cuando el usuario finaliza la sesión del sistema de inicio de sesión único de CAS? La página de CAS está escrita utilizando el marco Spring Para usuarios que no están familiarizados con Spring. , debe modificarlo antes de familiarizarse con el marco. Después de personalizar la página, aún necesita realizar alguna configuración para permitir que ?CAS encuentre la nueva página. Copie "?cas/WEB-INF/classes/default_views.properties?" a "?cas /WEB-INF/classes/?newUI_views.properties?" y modifique todos los valores que contiene a la nueva página correspondiente. El último paso es actualizar viewResolver en el archivo "cas/WEB-INF/cas-servlet.xml" y modificarlo al contenido del Listado 9. ¿Lista?9.?Especificar?CAS?page Implementación de aplicaciones cliente El propósito del inicio de sesión único es permitir que múltiples aplicaciones relacionadas utilicen el mismo proceso de inicio de sesión. Este artículo construye?2 durante el proceso de explicación. Una aplicación sencilla, tomando como ejemplos ?casTest1? y ?casTest2? Cada uno tiene una sola página, que muestra el mensaje de bienvenida y el nombre de usuario de inicio de sesión actual. Estas dos aplicaciones utilizan el mismo conjunto de información de inicio de sesión y solo pueden acceder a ellas los usuarios que han iniciado sesión. A través de la configuración de este artículo, se logra el inicio de sesión único, es decir, solo necesita iniciar sesión una vez para acceder a estas dos. aplicaciones. Establezca una relación de confianza con el servidor CAS Suponga que el servidor CAS está implementado en una máquina A separada y que la aplicación cliente está implementada en la máquina B. Desde la comunicación entre la aplicación cliente y el servidor CAS usa SSL, se debe establecer una relación de confianza entre los JRE de A y B. Primero, al igual que la máquina A, debe generar un certificado en la máquina B y configurar el protocolo SSL de Tomcat. En segundo lugar, descargue ?InstallCert.java desde /andreas/entry/no_more_unable_to_find , ejecute el comando "?java?InstallCert?compA:8443?" e ingrese ?1 en la siguiente consulta. De esta manera, ?A? se agrega al ?almacén?de confianza? de ?B?. Si se implementan varias aplicaciones cliente en diferentes máquinas, cada máquina debe establecer una relación de confianza con la máquina donde se encuentra el servidor CAS. Configurar ?CAS?Filter Después de prepararse para aplicar ?casTest1? y ?casTest2?, impleméntelos en las máquinas ?B? y ?C? , B? y ?C? Introduciremos la configuración de ?casTest1? en la máquina ?B? Cambie el nombre de ?cas-client-java-2.1.1.zip? a ?cas-client-java-2.1.1.jar? y cópielo en el directorio ?casTest1/WEB-INF/lib. Modifique el archivo web.xml y agregue el filtro CAS, como se muestra en el Listado 10: Listado 10. Agregue el filtro CAS Al acceder a todos los recursos que cumplen con la ruta de casTest1/protected-pattern/, debe iniciar sesión en el servidor CAS. Si necesita proteger todo casTest1, puede especificar el patrón de URL para "/*". Como se puede ver en el Listado 10, podemos especificar algunos parámetros para CASFilter, y algunos son obligatorios y los parámetros opcionales de las Tablas 1 y 2, respectivamente: Table?1. .?CASFilter?Parámetros requeridos ¿Nombre del parámetro?Función? edu.yale.its.tp.cas.client.filter .loginUrl?Specify?CAS?Provide?URL? edu.yale.its.tp.cas.client.filter.validateUrl?Specify?CAS?Provide?service?ticket?or?proxy? La URL del servicio de autenticación de tickets edu.yale.its.tp.cas.client.filter.serverName especifica el nombre de dominio y el puerto del cliente, que se refiere a la máquina donde se encuentra la aplicación cliente en lugar de CAS. La máquina donde se encuentra el ?Servidor? ¿Se debe especificar al menos uno de estos parámetros o ?serviceUrl? edu.yale.its.tp.cas.client.filter.serviceUrl? Después de especificar este parámetro, se sobrescribirá el parámetro ?serverName? , se convierte en la dirección de destino para la redirección después de iniciar sesión correctamente? ¿Tabla?2.?CASFilter?Parámetros opcionales ¿Nombre del parámetro?Función? edu. its.tp.cas.client.filter.proxyCallbackUrl? se utiliza para obtener la dirección del ticket de concesión de proxy cuando la aplicación actual necesita servir como proxy para otros servicios. edu.yale. tp.cas.client.filter.authorizedProxy? se utiliza para permitir que la aplicación actual obtenga tickets de proxy del proxy. Este parámetro acepta múltiples URL de proxy separadas por espacios, pero solo se requiere un éxito para el uso real. Después de especificar este parámetro, debe modificar la URL de validación a proxyValidate en lugar de serviceValidate edu.yale.its.tp.cas.client.filter.renew si se especifica como verdadero, entonces el recurso protegido requerirá el ¿El usuario debe volver a autenticarse cada vez que se accede, independientemente de si se ha pasado antes? edu.yale.its.tp.cas.client.filter.wrapRequest?Si lo especificado es verdadero, entonces CASFilter Volverá a empaquetar HttpRequest y utilizará el método getRemoteUser() para devolver el nombre de usuario del usuario que ha iniciado sesión actualmente. edu.yale.its.tp.cas.client.filter .gateway? ¿Especificar el atributo de puerta de enlace? Pase el nombre de usuario de inicio de sesión CAS? Después de iniciar sesión correctamente, devolverá una cookie al navegador y configurará el nuevo servicio ?Ticket. Pero la aplicación cliente tiene su propia sesión. ¿Cómo obtenemos el nombre de usuario del usuario que ha iniciado sesión actualmente en cada aplicación? El ?Filtro? de CAS?Cliente? se ha procesado después de iniciar sesión correctamente, se puede obtener directamente de las propiedades de ?Sesión?, como se muestra en el Listado ?11?: Listado ? Obtenga el nombre de usuario de inicio de sesión a través de ?Session? en ?Java? //?Se pueden usar ambos de los siguientes session.getAttribute(CASFilter.CAS_FILTER_USER); session.getAttribute("edu.yale.its.tp.cas.client.filter.user"); El método para obtener el nombre de usuario en JSTL es como se muestra en el Listado 12: Listado 12. Obtención del nombre de usuario de inicio de sesión a través de JSTL Además, CAS proporciona una clase CASFilterRequestWrapper, que hereda de HttpServletRequestWrapper y principalmente anula el método getRemoteUser(). Siempre que configure el archivo "edu.yale.its. tp.cas.client.filter.wrapRequest?" en verdadero al configurar CASFilter anteriormente, puede obtener el nombre de usuario de inicio de sesión a través del método getRemoteUser(). El método específico se muestra en el Listado 13: Listado 13. Obtenga el nombre de usuario de inicio de sesión a través de CASFilterRequestWrapper CASFilterRequestWrapper?reqWrapper=new?CASFilterRequestWrapper(request); out.println("The?logon?user:"?+?reqWrapper .getRemoteUser());