Differenze tra le versioni di "Tomcatxx"

Da WikiSitech.
Vai alla navigazioneVai alla ricerca
m (Mazzotti ha spostato la pagina Tomcat55 a Tomcat: Rinominata la pagina per renderla maggiormente generica)
m (Mazzotti ha spostato la pagina Tomcat a Tomckatxx)
(Nessuna differenza)

Versione delle 15:50, 19 ago 2022

TOMCAT - Appunti di gestione/configurazione

Configurazione tramite file parametri JNDI

<Environment description="Cartella file di configurazione ..." 
			 name="url/com.netsitech.myapp.urlConfig"
			 type="java.lang.String"
			 value="file:///C:/Programmi/Sitech/myapp/config"/>

o in caso di architettura *nix

<Environment description="Cartella file di configurazione ..." 
			 name="url/com.netsitech.myapp.urlConfig"
			 type="java.lang.String"
			 value="file:///etc/myapp/config"/>


Esempio di configurazione per l'autenticazione LDAP

La sezione di configurazione seguente, ma messa all'interno del tag <Engine> del file server.xml.

<!-- Autenticazione Ldap Sitech -->
<Realm className="org.apache.catalina.realm.JNDIRealm"
	debug="99"
	connectionName="account-per-bind"
	connectionPassword="password-account-per-bind"
	connectionURL="ldap://ldap.server.dominio:389"
	referrals="follow"
	userBase="DC=2ndlevel-domain,DC=domain,DC=toplevel"
	userSearch="(sAMAccountName={0})"
	userSubtree="true"
	userRoleName="memberOf" />


E' importante ricordare che, nel caso particolare di ActiveDirectory, in corrispondenza della voce memberOf, verranno elencati solo i gruppi secondari per l'utente. Come conseguenza di questo comportamento, è importante che il gruppo principale di assegnazione di ogni account, sia diverso da quello utilizzato per verificare le crednziali di autenticazione.

Nel caso di faccia uso del canale protetto (LDAPS), è importante che nel keystore della JVM su cui viene eseguito TOMCAT sia inserito il certificato del server LDAPS.

La configurazione per ottenere l'autenticazione va completata con alcune righe nel descrittore (file web.xml) della web application.
In particolare vanno aggiunte le seguenti righe:

<security-constraint>
	<web-resource-collection>
		<web-resource-name>Accesso all'area protetta del sito</web-resource-name>
		<url-pattern>/areaprotetta/*</url-pattern>
	</web-resource-collection>
	<auth-constraint>
		<!-- NOTE:  This role is not present in the default users file -->
		<role-name>CN=Utenti area protetta,OU=unita-organizzativa,DC=2ndevel-domain,DC=domain,DC=topleve</role-name>
	</auth-constraint>
</security-constraint>

<login-config>
	<auth-method>BASIC</auth-method>
	<realm-name>Descrizione del realm</realm-name>
</login-config>

<!-- Security roles referenced by this web application -->
<security-role>
	<description>
		Ruolo richiesto per l'accesso all'area protetta del sito
	</description>
	<role-name>CN=Utenti area protetta,OU=ufficio sviluppo,DC=2ndevel-domain,DC=domain,DC=topleve</role-name>
</security-role>


Le righe sopra esposte, fanno si che il sito pubblico in questione, contenga una cartella protetta individuata dal prefisso /areaprotetta all'interno della quale, ogni file (/*) è soggetto al controllo di autenticazione.
Saranno ammessi a quest'area tutti gli utenti per i quali esiste una definizione in AD (ldap) che preveda l'appartenenza al gruppo di protezione Utenti area protetta, dell'unità organizzativa ufficio sviluppo appartenente al dominio 2ndlevel.domain.toplevel.

Errore durante la convalida di un certificato (ad esempio per autenticazione LDAPS)

Nel caso di presente l'errore:

javax.net.ssl.SSLHandshakeException: No subject alternative DNS name matching ......

oppure:

java.security.cert.CertificateException: No subject alternative DNS name matching .....

ed in ogni caso nell'eccezione sollevata comparisse come causa: No subject alternative DNS name matching ....., la soluzione è nell'includere la seguente definizione nel file di impostazione delle variabili di ambiente utilizzata all'avvio di TOMCAT:

CATALINA_OPTS="-Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true"

Solitamente il file in cui includere questa definizione è:

setenv.sh

la cui collocazione fisica sul file system dipende dalla versione e tipologia di JVM/distribuzione di TOMCAT utilizzata.
Di seguito due casi diversi:

/var/lib/tomcat9/bin/setenv.sh

e

/usr/share/tomcat9/bin/setenv.sh

Abilitare/Disabilitare il Directory Listing

Accedere al file web.xml presente nella cartella di configurazione dell'installazione Tomcat e impostare il valore del parametro listings al valore true o false.

Proteggere una cartella

Per proteggere una cartella è necessario creare un security-descriptor nel file web.xml.
Ecco un esempio di security descriptor

  <!-- Define a Security Constraint on this Application -->
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>Descrizione della cartella da proteggere</web-resource-name>
      <url-pattern>/cartella-da-proteggere/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>reserved</role-name>
    </auth-constraint>
  </security-constraint>

  <!-- Define the Login Configuration for this Application -->
  <login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>Messaggio che vogliamo che compaia nella dialog di logon</realm-name>
  </login-config>

  <!-- Security roles referenced by this web application -->
  <security-role>
    <description>Ruolo necessario per accedere alla cartella protetta</description>
    <role-name>reserved</role-name>
  </security-role>

Questo va bene nel caso in cui la cartella da proteggere appartenga ad un contesto (Context) già definito.
Nel caso invece in cui si possa definire un contesto specifico per la cartella da proteggere, si può procedere come segue:

  1. Creare il nuovo Context
<Context path="/cartella-da-proteggere" docBase="${catalina.home}/folder-da-proteggere" privileged="true" allowLinking="true" >
  <!-- Definizione facoltativa solo se è necessario restringere l'accesso ad un certo numero di IP -->
  <Valve className="org.apache.catalina.valves.RemoteAddrValve"
    allow="172.16.0.*, 10.*" deny="10.172.16.*"/>
</Context>
  1. Posizionarsi nella cartella identificata da ${catalina.home}/folder-da-proteggere
  2. Creare una cartella di nome WEB-INF
  3. Creare all'interno di questa un file web.xml il cui contenuto è il seguente:
<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID"
         version="2.4"
         xmlns="http://java.sun.com/xml/ns/j2ee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

  <display-name>Nome-Contesto</display-name>
  <description>Breve descrizione del contesto</description>

  <!-- Define a Security Constraint on this Application -->
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>Descrizione del contesto da proteggere</web-resource-name>
      <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>reserved</role-name>
    </auth-constraint>
  </security-constraint>

  <!-- Define the Login Configuration for this Application -->
  <login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>Messaggio che vogliamo che compaia nella dialog di logon</realm-name>
  </login-config>

  <!-- Security roles referenced by this web application -->
  <security-role>
    <description>Ruolo necessario per accedere al contesto protetto</description>
    <role-name>reserved</role-name>
  </security-role>
</web-app>