Informazioni sull'autenticazione in un Java Application Server

Question

Attualmente sto lavorando a un progetto in esecuzione su JBoss AS 7 che richiede l'autenticazione da una varietà di fonti. Sto cercando di ottenere una comprensione dei vari componenti che si combinano per fornire l'autenticazione.

Ho alcune supposizioni/ipotesi su come tutto questo combaci, ma devo assicurarmi che la mia comprensione sia corretta. Quindi di seguito è quello che ho capito di essere il processo di autenticazione per JBoss AS7.

---

Si dispone di un ambito di sicurezza che definisce il modo in cui gli utenti sono autenticati. Questo dominio viene quindi esposto alla tua applicazione per proteggerne alcuni o tutti. In AS7 questo è configurato nel sottosistema < xmlns = "urn: jboss: domain: security: 1.0" > element.

Il dominio può essere configurato per autenticare gli utenti da una varietà di fonti utilizzando i moduli di accesso, come un database, LDAP, un file locale o altro. È possibile definire più moduli di accesso e è possibile specificare una combinazione di moduli di accesso che devono "riuscire" per consentire l'autenticazione.

Il nome utente e le password effettivi vengono inoltrati tramite un meccanismo definito nel file web.xml (per servlet), definito nell'elemento di login-config <.

---

Supponendo che il processo di cui sopra è corretto (e non potrebbe essere):

• Ha tutta questa caduta processo di autenticazione in una specifica come JAAS, o è JAAS solo una parte piccola o facoltativa del questa procedura?
• Tutti i tipi di < metodi di autenticazione > (cioè BASIC, DIGEST e FORM) funzionano con tutti i tipi di moduli di accesso? This page sembrerebbe suggerire di no, ma non ho visto alcuna documentazione chiara corrispondente allo < login-module > opzioni < login-config > opzioni.
• Il flusso di nome utente e password da un login-config a un modulo di accesso sembra abbastanza semplice, ma cosa succede con sistemi come OpenID o OAuth dove ci sono passaggi intermedi (come il reindirizzamento a pagine di accesso esterne)?
• Come si adattano a questa immagine progetti come Seam 3 Security, Apache Shiro e Spring Security?

Answer 1

Le specifiche di sicurezza JavaEE lasciano molto spazio agli implementatori di container, quindi mi concentrerò sull'implementazione di JBoss per rispondere.

implementazione della sicurezza JBoss

JBoss si basa su autenticazione JAAS per implementare la sicurezza JavaEE. In questo modo prende benefici da un'API stabile e può utilizzare existing LoginModule implementations. I moduli di login sono utilizzati per autenticare un soggetto, ma anche per aggiungere ruoli a Subject. JAAS fornisce meccanismi per l'autorizzazione, il controllo dei permessi e JBoss lo utilizza internamente.

JAAS LoginModule non supporta solo l'autenticazione basata su password ma anche l'autenticazione basata su token.

token basato autenticazioni

Un buon esempio di ciò che può essere fatto in JBoss grazie alla JAAS è la HTTP Negotiation support for Kerberos SPNEGO: un ulteriore auth-method nome SPNEGO è implementato grazie ad un Tomcat Authenticator e convalida del token utilizza JavaSE standard Kerberos LoginModule.

A proposito, l'API LoginModule non è un requisito, potrebbe anche essere troppo complessa per alcuni protocolli. Ad esempio, l'implementazione per supportare OpenID with PicketLink utilizza solo l'API servlet.

librerie di protezione di terze parti

Queste librerie spesso forniscono livelli di sicurezza per un'applicazione in esecuzione un JavaEE o contesto Java puro, anche se non ci vuole beneficia di specifiche JavaEE per l'autenticazione o autorizzazione basata sui ruoli.

Spring Security fornisce altre astrazioni rispetto alla sicurezza JavaEE per gli sviluppatori di applicazioni che implementano l'autenticazione e l'autorizzazione, principalmente grazie a ServletFilter quando si tratta di un'applicazione Web. Un ampio pannello di scelte è disponibile per proteggere la sua applicazione: è possibile combinare più opzioni come: uso di JAAS, utilizzo della sicurezza del contenitore JavaEE o implementazioni specifiche di Spring Security (il caso di OpenID e OAuth). Non esiste alcuna dipendenza da JavaEE, quindi può essere utilizzato quasi in qualsiasi situazione durante l'esecuzione su JavaSE. La maggior parte degli architetti sceglie di creare la sicurezza delle applicazioni su Spring Security per avere la libertà di cambiare implementazioni specifiche in futuro.

Apache Shiro è molto simile a Spring Security ma è più giovane e probabilmente più facile da configurare.

La sicurezza Seam non si basa sulla sicurezza JavaEE o su JBoss ma solo sulle API Servlet e JSF. È ovviamente l'opzione più semplice per l'applicazione web basata su JSF/Seam. Dietro la scena, utilizza le implementazioni PicketLink.

In conclusione, la domanda da utilizzare librerie di terze parti in aggiunta o in sostituzione alla sicurezza JavaEE dipende da scelte architettoniche: la complessità delle applicazioni, l'indipendenza del fornitore e la portabilità, il controllo sulle implementazioni per correzioni di bug o miglioramenti. Nel tuo contesto specifico, avere più fonti di autenticazione richiede una soluzione flessibile come Spring Security che supporta authentication provider chaining (o Shiro).