Per ragioni di sicurezza qualora si decide di rendere una risorsa disponibile su indirizzo pubblico, le porte che vengono aperte sono le porte 80 e 443, rispettivamente responsabili delle risorse in chiaro e delle risorse criptate in ssl. Le porte 80 e 443 sono porte di sistema dedicate al protocollo http e su un server linux sono assegnate al demone httpd.

La configurazione standard di liferay prevede la sua esposizione su porta 8080, porta tipica di un server tomcat. Pertanto non possiamo accedere direttamente a liferay ma dobbiamo mettere in piedi una infrastruttura che ci consenta di farlo.

Per gestire questo scenario possiamo avvalerci dell’http server di apache opportunamente configurato come proxy. Configuriamo Apache in modo tale da veicolare le richieste che arrivano verso liferay.

Sono presenti 2 possibili approcci:

1. usare mod_jk
2. configurare un reverse proxy

La configurazione basata su mod_jk è sicuramente la scelta più indicata: la configurazione standard di liferay presenta il modulo ajp in ascolto sulla porta 8009, pertanto dobbiamo solo configurare apache per configurare il modulo mod_jk.so.

Il modulo mod_jk.so non è disponibile nella configurazione standard di Apache, a seconda della versione linux è possibile installarla tramite il gestore dei pacchetti oppure scaricando i sorgenti dal sito e compilandoli. Una volta installato il modulo mod_jk.so occorre configurare il file httpd.conf per abilitare il modulo tramite le direttive

LoadModule jk_module   <path>/mod_jk.so –> indica dove è presente il mod_jk.so
JkWorkersFile percorso <path>/workers.properties –> indica dove si trova il file workers.properties
JkLogFile   <path>/mod_jk.log –> indica il file di log
JkLogLevel    <level> –> indica il livello di log
JkMount  /* worker1 –> indica il livello

Resta da configurare opportunamente il file workers.properties, dove definiamo le regole di integrazione con liferay, tramite le direttive

worker.list=worker1
worker.worker1.port=8009
worker.worker1.host=<ip di liferay>
worker.worker1.type=ajp13

A questo punto riavviamo apache e proviamo ad accedere all’indirizzo pubblico, se abbiamo operato bene verremo rediretti su liferay.

Qualora non possiate usare mod_jk (non mi viene in mente nessun motivo) usate l’approccio 2. Per configurare il reverse proxy usate le seguenti direttive

ProxyPass /liferay http://x.x.x.x:8080/  –> redirige le chiamate verso il server liferay
ProxyPassReverse /liferay http://x.x.x.x:8080/

Non è sufficiente, poichè con questa configurazione avremmo accesso alla home page di liferay ma non a tutte le risorse, poichè liferay restituisce le url alle risorse della pagina in formato assoluto.

Per ovviare all’inconveniente ci viene in soccorso il modulo mod_proxy_html che consente di implementare delle regole di sostituzione all’interno delle pagine html restituite da liferay tramite la direttiva

LoadModule proxy_html_module modules/mod_proxy_html.so
LoadModule xml2enc_module modules/mod_xml2enc.so
ProxyHTMLURLMap http://x.x.x.x:8080/ /app<Location /app1/>
ProxyPassReverse /
ProxyHTMLEnable On
ProxyHTMLURLMap  /      /app1/
RequestHeader    unset  Accept-Encoding
</Location>

Il modulo mod_proxy_html non è presente nella distribuzione standard di Apache, a carico vostro installazione e configurazione reperibile sul sito

Per le versioni 6.x e 5.2.x la configurazione del mail server può essere effettuata tramite interfaccia grafica, andando sotto la sezione Control Panel -> Server Administration -> Mail. Siccome una immagine vale più di mille parole, osservate lo screenshot successivo:

Potete configurare il mail server e i parametri di connessione tramite il file portal-xxx.properties. Le variabili da usare sono

mail.session.mail.imap.host=xxxx
mail.session.mail.pop3.host=xxxx
mail.session.mail.smtp.host=xxxx
mail.session.mail.smtp.password=xxx
mail.session.mail.smtp.user=yyyy
mail.session.mail.store.protocol=xxxx
mail.session.mail.transport.protocol=smtp

Per le versioni precedenti e per gli amanti dei file di configurazione dovete modificare il file ROOT.xml disponibile al path $tomcat_home\conf\Catalina\localhost\ROOT.xml

In questo file dovete aggiungere la risorsa che descrive i paramatri di accesso al db

<Resource
name="mail/MailSession"
auth="Container"
type="javax.mail.Session"
mail.imap.host="localhost"
mail.pop.host="localhost"
mail.store.protocol="imap"
mail.transport.protocol="smtp"
mail.smtp.host="smtp.gmail.com"
mail.smtp.port="465"
mail.smtp.auth="true"
mail.smtp.starttls.enable="true"
mail.smtp.user="username"
password="password"
mail.smtp.socketFactory.class="javax.net.ssl.SSLSocketFactory" />

Per verificare il corretto funzionamento provate a registrare un nuovo utente, se avete fatto tutto bene dovreste ricevere la mail di avvenuta registrazione.

Buona sperimentazione

Se avete seguito i passi del precedente articolo dovreste avere la vostra istanza liferay attiva e funzionante con il meccanismo di autenticazione demandato al CAS, che si preoccupa di verificare se username e password sono uguali.

Nell’articolo precedente abbiamo usato la versione CAS messa a disposizione da Liferay, che è ferma alla versione 3.0.5 e pertanto installiamo la versione nuova 3.5.0 disponibile qui, che risulta essere più stabile e anche più esaustiva dal punto di vista dei log.

Scaricato il file sostituiamo, rinominiamo il file war in cas-web.war, in modo da non dover cambiare le impostazioni effettuate precedente su liferay.

Una volta attivo accediamo alla cartella webapp/cas-web/WEB-INF sotto la directory del tomcat e analizziamo il file deployerConfigContext.xml: in questo file sono definite le regole di autenticazione e nella configurazione di default troviamo il bean

<bean class="org.jasig.cas.authentication.handler.
support.SimpleTestUsernamePasswordAuthenticationHandler">
</bean>

che come già detto applica come meccanismo di autenticazione che username e password coincidano.

Sostituiamo il bean con quello responsabile di implementare il meccanismo di autenticazione. Il cas mette a disposizione 3 implementazioni differenti:

1. BindModeSearchDatabaseAuthenticationHandler (responsabile di verificare l’accesso ad uno schema db con una coppia username/password)
2. QueryDatabaseAuthenticationHandler (responsabile di verificare l’autenticazione tramite una query sql)
3. SearchModeSearchDatabaseAuthenticationHandler ( responsabile di verificare  l’autenticazione  partendo dalla tripletta tabella utente, username e password, opportunamente mappati)

Per integrare il bean occorre definire il datasource, tramite la seguente configurazione

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
      <property name="driverClassName">
        <value>com.mysql.jdbc.Driver</value>
      </property>
      <property name="url">
        <value>jdbc:mysql://localhost:3306/lportal</value>
      </property>
      <property name="username"><value>lportal</value></property>
      <property name="password"><value>lportal</value></property>
 </bean>

e successivamente potete scegliere liberamente tra il secondo e il terzo bean, da sostituire al bean SimpleTestUsernamePasswordAuthenticationHandler.

<bean class="org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler">
    <property name="dataSource" ref="dataSource" />
    <property name="sql" value="select password_ from user_ where lower(emailAddress) = lower(?)" />
</bean>

Nel caso del bean QueryDatabaseAuthenticationHandler  dovremo definire la query per ottenere la password da confrontare con quella inserita dall’utente.

<bean class="org.jasig.cas.adaptors.jdbc.SearchModeSearchDatabaseAuthenticationHandler">
            <property name="tableUsers"><value>user_</value></property>
            <property name="fieldUser"><value>emailAddress</value></property>
            <property name="fieldPassword"><value>password_</value></property>
            <property name="dataSource" ref="dataSource"/>
 </bean>

Nel caso del bean SearchModeSearchDatabaseAuthenticationHandler dovremo specificare la tabella coinvolta e i campi su cui mappare username e password inseriti nel login del CAS.

Entrambi i bean considerano il caso di password salvate in chiaro. Siccome Liferay di default applica la codifica SHA dovete allineare il comportamento e avete di fronte due possibilità:

1. configurare liferay in modo che salvi in chiaro le password, tramite la direttiva passwords.encryption.algorithm=NONE
2. configurare i bean del CAS in modo da applicare l’algoritmo SHA. Per farlo occorre sfruttare il bean org.jasig.cas.authentication.handler.DefaultPasswordEncoder, scegliere la codifica desiderata e innestarli nel nostro bean.

Prima di tutto scarichiamo il progetto dalla sezione download del sito principale di liferay. Nel momento in cui scrivo è disponibile la versione 6.1 che promette grandi migliorie e tra le tante disponibili scegliamo la versione integrata con Tomcat.

Una volta scaricato il file zip scompattatelo (usate 7zip, alcuni file hanno nomi molto lunghi e l’utility di windows va in errore).

Avviamo tomcat e restiamo in attesa, fino a quando non viene aperta la finestra di configurazione del wizard. Con il Wizard possiamo configurare il nome del sito, la lingua di default e i dati di accesso dell’amministratore. Inoltre possiamo scegliere di modificare la base dati cui appoggiare il nostro portale. Di default è configurato HSQL, che va bene per un’installazione di prova, ma è sconsigliato per un’installazione di produzione.

In questo articolo integreremo MySQL:

1. cambiamo la configurazione
2. scegliamo come tipo di base dati MySQL
3. impostiamo l’url di accesso
4. impostiamo i dati di autenticazione
5. confermiamo

• data (dedicata contenere i dati del database embedded HSQL, i dati di JackRabbit e Lucene)
• deploy (dedicata a contenere i plugin da installare)
• tomcat (contiene l’application server scelto)
• logs (contiene i log generati da LIFERAY)
• license ( contiene le licenze delle librerie contenute nel rilascio)