LinuxParty

Una vez que haya establecido su realm y el método de autenticación, tendrá que lidiar con el actual proceso de registro el usuario. En la mayoría de las veces, ingresar en una aplicación es una molestia para el usuario final, y es necesario reducir al mínimo el número de veces que debe autenticarse. De forma predeterminada, una aplicación web le pedirá al usuario iniciar sesión la primera vez que el usuario solicita un recurso protegido. Esto puede parecer una molestia para los usuarios si ejecutan varias aplicaciones web y cada aplicación pide al usuario identificarse. Los usuarios no pueden saber cuántas aplicaciones diferentes hay en un sitio web único, por lo que no se sabe cuando se está haciendo una petición que cruza un límite del contexto, y se preguntan por qué se le está constantemente solicitando en reiteradas ocasiones logearse

La característica "single sign-on" de Tomcat 4 permite a los usuarios autenticarse una sola vez para acceder a todas las aplicaciones web cargadas bajo un host virtual. Para utilizar esta característica, sólo tiene que añadir un elemento SingleSignOn Valve a nivel de host. Esto se parece a lo siguiente:

 <Valve className="org.apache.catalina.authenticator.SingleSignOn"
       debug="0"/>

El fichero por defecto server.xml de la distribución Tomcat contiene un salida comentada de single SingleSignOn Valve en la configuración de ejemplo que podrá descomentar y utilizar. Entonces, cualquier usuario que se considere válido en un contexto del host virtual configurado se considerará válido en todos los otros contextos para ese mismo host.

Hay varias restricciones importantes para el uso del inicio de sesión usando single sign-on valve:

• La valve debe estar configurado y anidado en el mismo Host que las aplicaciones web (representado por Context elementos) se anidan en su interior.

• El Realm que contiene la información de usuario compartido debe estar configurado ya sea en el nivel del mismo Host o en una anidación exterior.

• El Realm no puede ser anulado en el nivel Context.

• Las aplicaciones Web que utilizan inicio de sesión único deben utilizar uno de los built-in Tomcat autenticadores (en el elemento <auth-method>  de web.xml), en lugar de un autenticador personalizado. Los métodos integrados son basic , digest , form y client-cert.

• Si utiliza inicio de sesión único y desea integrar otras aplicaciones web de terceros en su sitio web, y la nueva aplicación web utiliza sólo su código de identificación propio que no utiliza el gestor de seguridad, básicamente está atascado . Los usuarios tendrán que iniciar sesión una vez para todas las aplicaciones web que utilizen single sign-on, y luego una vez más si hacen una petición a la nueva aplicación web de terceros. Por supuesto, si tienes el código fuente y si eres un desarrollador, puedes arreglarlo, pero no creo que sea tan fácil de hacer.

• El inicio de sesión único de la valve requiere el uso de cookies HTTP.

7. Configurar directorios de usuario personalizadas

Algunos sitios permiten que los usuarios individuales publiquen en un directorio de páginas web en el servidor. Por ejemplo, un departamento de la universidad que desee dar a cada estudiante un área pública, o un ISP ceda un poco de espacio web disponible en uno de sus servidores a los clientes que no disponen de un servidor web alojado virtualmente. En tales casos, es típico utilizar el carácter de tilde (~) más el nombre del usuario como la ruta de acceso virtual de sitio web de dicho usuario:

http://www.cs.myuniversity.edu/~username
http://members.mybigisp.com/~username

Tomcat le ofrece dos maneras de correlacionar esto sobre una base per-host, usando un par de especiales elementos Listener. los atributos Listener's className deben ser org.apache.catalina.startup.UserConfig, con el atributo userClass que especifica una de las clases de mapeo varios. Si su sistema ejecuta Unix, tiene un estándar de archivo /etc/passwd es legible por la cuenta que ejecuta Tomcat, y ese archivo especifica los directorios home de los usuarios, utilice la clase PasswdUserDatabase de mapeo:

<Listener className="org.apache.catalina.startup.UserConfig" 
directoryName="public_html" 
userClass="org.apache.catalina.startup.PasswdUserDatabase"/>

Los archivos Web tendrían que estar en directorios como /home/users /ian/public_html/ o  /home/jasonb/public_html. Por supuesto, puede cambiar public_html por el subdirectorio en el cual los usuarios tengan sus páginas web personales.

De hecho, los directorios no tienen que estar dentro del directorio principal de un usuario en absoluto. Si usted no tiene un archivo de contraseña pero desea asignar un nombre de usuario a un subdirectorio de un directorio padre común, como /home, utilice la clase HomesUserDatabase:

<Listener className="org.apache.catalina.startup.UserConfig" 
directoryName="public_html" homeBase="/home" 
userClass="org.apache.catalina.startup.HomesUserDatabase"/>

En este caso, los archivos Web estarían en directorios como  /home/ian/public_html o /home/jasonb/public_html. Este formato es más útil en Windows, donde probablemente tendría que utilizar un directorio como C:\home.

Estos elementos Listener, si están presentes, deben estar dentro de un elemento Host, pero no dentro de un elemento Context, que se aplican a la Host en sí.

8. Uso de scripts CGI con Tomcat

Tomcat está principalmente destinado a ser un contenedor servlet / JSP, pero tiene muchas capacidades que rivalizan con un servidor web tradicional. Uno de ellos es el soporte para la (Common Gateway Interface) (interfaz de pasarela común) o simplemente (CGI), que proporciona un medio para ejecutar un programa externo en respuesta a una petición del navegador, típicamente para procesar un formulario basado en la web. CGI se llama "common" porque puede invocar a los programas en casi cualquier lenguaje de programación o de scripting: Perl, Python, awk , Unix shell scripting, y Java, incluso son todas las opciones soportadas. Sin embargo, es probable que no se ejecute una aplicación Java como un CGI debido a la sobrecarga de puesta en marcha, la eliminación de esta carga fue lo que llevó al diseño original de la especificación de servlet. Los servlets son casi siempre más eficaces que los CGIs porque no comienzan un nuevo sistema operativo a nivel de proceso cada vez que alguien hace clic en un enlace o botón.

Tomcat incluye un servlet CGI opcional que le permite ejecutar scripts CGI existentes, la hipótesis es que la mayor parte nueva del back-end de procesamiento estará hecho por user-defined servlets y JSPs.

Para habilitar servlet Tomcat CGI, debe hacer lo siguiente:

1. Cambie el nombre del archivo de servlets-cgi.renametojar (que se encuentra en CATALINA_HOME/server/lib/) a servlets-cgi.jar, para que el servlet que procesa los scripts CGI será el Tomcat CLASSPATH .

2. En el fichero  CATALINA_BASE/conf/web.xml, descomente la definición del servlet llamado cgi (esto está próximo a la línea 241 en la distribución).

3. También en web.xml de Tomcat, descomente servlet mapping para el cgi servlet (alrededor de la línea 299 en el archivo distribuido). Recuerde, esto especifica los hipervínculos a la secuencia de comandos CGI.

4. Coloque los scripts CGI en el directorio WEB-INF/cgi (recuerda que WEB-INF es un lugar seguro para ocultar las cosas que usted no desea que el usuario sea capaz de ver, por razones de seguridad), o colocarlos en algún otro directorio dentro de su contexto y ajuste el  parámetro cgiPathPrefix de inicialización de la CGIServlet para identificar el directorio que contiene los archivos. Esto especifica la ubicación real de los scripts CGI, que normalmente no será la misma que la URL en el paso anterior.

5. Reinicie Tomcat, y el procesamiento de CGI ahora debería estar en funcionamiento.

El directorio predeterminado para el servlet para localizar las secuencias de comandos reales es WEB-INF/cgi. Como se ha señalado, el directorio WEB-INF se protege a los curiosos de los navegadores, por lo que este es un buen lugar para colocar los scripts CGI, que pueden contener contraseñas u otra información sensible. Para la compatibilidad con otros servidores, sin embargo, es posible que prefiera mantener las secuencias de comandos en el directorio tradicional, /cgi-bin, pero tenga en cuenta que los archivos de este directorio pueden ser visible para el internauta curioso. Además, en Unix, asegúrese de que los archivos de script CGI son ejecutables por el usuario con cuando se está ejecutando Tomcat.

9. Cambiando el compiladorJSP de Tomcat

En Tomcat 4.1 (y superiores, presumiblemente), la compilación de JSP se realiza mediante el controlador del programa Ant directamente desde dentro de Tomcat. Esto suena un poco extraño, pero es parte para lo que Ant estaba destinado, hay una API documentada que permite a los desarrolladores utilizar Ant sin poner en marcha una nueva JVM. Esta es una ventaja de tener Ant escrita en Java. Además, significa que se puede utilizar cualquier compilador con el apoyo de la javac dentro de Ant, que se enumeran en la página javac del manual Ant de Apache. Es fácil de usar, ya que sólo necesita un <init-param> con el nombre del "compilador" y un valor de uno de los nombres de los compiladores soportados:

<servlet>
    <servlet-name>jsp</servlet-name>
    <servlet-class>
      org.apache.jasper.servlet.JspServlet
    </servlet-class>
    <init-param>
      <param-name>logVerbosityLevel</param-name>
      <param-value>WARNING</param-value>
    </init-param>
    <init-param>
      <param-name>compiler</param-name>
      <param-value>jikes</param-value>
    </init-param>
    <load-on-startup>3</load-on-startup>
</servlet>

Por supuesto, dado que el compilador debe estar instalado en su sistema, y el CLASSPATH puede que sea necesario establecer, en función del compilador que usted elija.

10. Restringir el acceso a determinados hosts

A veces sólo querrá restringir el acceso a la aplicación web de Tomcat únicamente a direcciones IP o nombres de host especificado. De esta manera, sólo los clientes de esos sitios especificados se les servirá contenido. Tomcat viene con dos Valves que se pueden configurar y utilizar con este fin: RemoteHostValve y RemoteAddrValve .

Estas Valve s le permiten filtrar las solicitudes de nombres de host o dirección IP, y para permitir o denegar hosts, similar al Allow / Deny de las directivas de Apache httpd. Si ejecuta la aplicación de administración, es posible que desee permitir el acceso sólo a él desde localhost, como sigue:

<Context path="/path/to/secret_files" ...>
  <Valve className="org.apache.catalina.valves.RemoteAddrValve"
         allow="127.0.0.1" deny=""/>
</Context>

Si el patron allow no es configurado, entonces los patrones que coincidan con el atributo deny niegan y será rechazado, y todos los demás se les permitirá. Del mismo modo, Si el patron deny no es configurado, los patrones que coinciden con el atributo allow será permitido, y todos los demás serán rechazados.

 Proviene de:

Top 10 de la configuración en Tomcat, 1 de 2