JAVA,  Programmazione,  Vetrina

Implementare una nuova modalità di autenticazione per JBoss (parte 1)

JBoss, non supporta “out of the box”, l’integrazione con prodotti di web access management, metteremo quindi a frutto le conoscenze dei meccanismi di autenticazione di questo JEE Container, sviluppando un Authenticator ed un Login Module ad-hoc, definendo una nuova modalità di autenticazione.

Prima di iniziare a vedere l’implementazione vera e propria, è d’obbligo fare un overview sui meccanismi di autenticazione di JBoss, per poter meglio comprendere quali sono le componenti che dovremo sviluppare per arrivare all’obbiettivo che ci siampo posti.

Quando una web application viene “protetta” utilizzando la “Declarative Security”, nel suo deployment descriptor (il file web.xml), vengono aggiunti alcuni blocchi di codice XML che indicano al JEE Container quali sono le risorse protette dell’applicazione e quali particolari gruppi di utenti, denominati “Roles” sono abilitati all’accesso per quelle risorse.

Inoltre è necessario inserire un ulteriore blocco di codice XML, che indica al JEE Container le modalità con cui dovrà autenticare le credenziali degli utenti dell’applicazione.

La mappatura delle risorse protette sui diversi Roles dell’applicazione, avviene inserendo tra i due tag:

facciamo un esempio:


   
      Risorsa Protetta 1
      /path/subpath/*
      GET
      POST
   
   
      Role1
   


.
.
.


   
      Risorsa2
      /other-resource-path/*
      GET
      POST
   
   
      Role2
   

Mentre il blocco XML che configura le modalità di acquisizione ed autenticazione delle credenziali utente è recchiuso tra i due tag:

ed è composto come mostrato di seguito:


   BASIC

Una richiesta HTTP verso una delle risorse protette, elencata nel deployment descriptor, causerà l’apertura di un box di richiesta di credenziali, da parte del browser internet dell’utente, come configurato dal blocco <login-config> dell’esempio, credenziali che verranno autenticate mediante la BASIC Authentication.

A questo punto sorgono spontanei due quesiti… come vengono autenticate le credenziali acquisite? e su quale back-end?

JBoss implementa la fase di autenticazione mediante l’uso di due “oggetti” gli “Authenticators” ed i “Login Modules” ad essi relativi, entrambe le tipologie di oggetti sono implementate da classi JAVA.

Con JBoss viene fornito un set di Authenticators di base accompagnati dai relativi Login Modules, tale insieme di oggetti permette di utilizzare le principali modalità di autenticazione sui più comuni back-end, come ad esempio la BASIC Authentication già vista, la CLIENT-CERT, o la FORM, su back-end quali LDAP, RDBMS o semplici files di testo.

Un Authenticator si occupa di acquisire le credenziali dell’utente, di invocare i Login Modules configurati per l’applicazione che si sta accedendo e di registrare, al termine dalla fase di autenticazione, se andata a buon fine, nella “Request HTTP” un’istanza della classe:

org.jboss.web.tomcat.security.JBossGenericPrincipal

che incapsula correttamente, cioè come JBoss se le aspetta, le informazioni di identità dell’utente che è stato autenticato, quindi è nei Login Modules che avviene effettivamente l’autenticazione delle credenziali, sono questi oggetti che si interfacciano fisicamente con il o i back-end di autenticazione, ciò rende indipendente la web application dai meccanismi di autenticazione, ragione per cui esiste la JAAS e le librerie PAM UNIX di cui JAAS è l’implementazione JAVA.

Si è parlato di Login Modules al plurale, non a caso, visto che un Authenticator può invocare una catena di Login Modules associati ad una web application, in modo che l’autenticazione sia il risultato di una serie di verifiche addirittura su più back-end diversi.

Le catene di Login Modules vengono definite in un apposito file XML di configurazione di JBoss, denominato login-config.xml, una catena è costituita raggruppando i diversi Login Modules che la compongono attraverso un nome logico, tale nome verrà poi indicato in un file specifico della web application denominato jboss-web.xml presente nella directory WEB-INF della web application stessa, in modo che JBoss possa associare la catena alla web application per poterla poi invocare al momento dell’autenticazione.

Per chiarire meglio le idee vediamo un esempio:

jboss-web.xml


   WebAppContextName
   java:/jaas/LoginModuleChainName

login-config.xml


   
      
         option1-value
         option2-value
	  ...
         optionn-value
      

      
         option1-value
         option2-value
	 ...
         optionn-value
      

      ...

      
         option1-value
         option2-value
	 ...
	 optionn-value
      

   

A questo punto, fatta questa rapida panoramica, sui meccanismi di autenticazione di JBoss, torniamo allo scopo principale di questo articolo, cioè l’implementazione di una nuova modalità di autenticazione.

Supponiamo di dover effettuare il deploy della nostra web application, in un ambiente enterprise, in cui tutte le web application dell’azienda sono configurate per supportare il single sign-on implementato utilizzando il web access manager open source di JA-SIG; CAS (Central Authentication Service).

Il funzionamento di CAS è relativamente semplice, la richiesta HTTP dell’utente verso una web application protetta tramite CAS, viene intercettata, e girata verso una pagina di accesso del web access manger, qui l’utente fornisce le proprie credenziali che vengono autenticate da CAS sul back-end configurato per il prodotto, solitamente un LDAP, dopo l’autenticazione la richiesta viene girata da CAS verso la URL originaria richiesta dal browser dell’utente, aggiungendo però alla query string un ticket generato in seguito all’autenticazione andata a buon fine, tale richiesta prima di arrivare alla web application, viene trattata dal JEE Container, come nella norma.

Ci sono due modalità di integrazione con tale modalità di autenticazione, la prima è gestita a livello applicativo, cioè dalla web application stessa e normalmente viene attuata utilizzando dei servlet filter, sviluppati da JA-SIG stessa, l’altra implementando l’integrazione a livello di JBoss.

La prima modalità di integrazione non è attuabile nei casi in cui viene adottata la “Declarative Security”, visto che presuppone l’uso dei Servlet Filters, la request non potrebbe mai arrivare ad attraversare questi oggetti perchè verrebbe inevitabilmente bloccata da JBoss a causa della mancanza un oggetto correttamente popolato con l’identità di un utente autenticato ed associato al ruolo autorizzato ad accedere alle risorse protette della web application.

Quindi necessariamente l’integrazione deve essere gestita prima che la richiesta HTTP arrivi alla web application.

JBoss, non supporta “out of the box”, l’integrazione con tale prodotto, metteremo quindi a frutto le conoscenze descritte all’inizio dell’articolo, sviluppando un Authenticator ed un Login Module ad-hoc, definendo così una nuova modalità di autenticazione che chiameremo appunto CAS.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *