2011-10-16 11 views
18

Sto provando a proteggere la mia applicazione che è costruita usando JSF2.0.Quando passare dalla sicurezza gestita da Container a alternative come Apache Shiro, Spring Security?

Sono confuso su quando le persone scelgono di andare con alternative di sicurezza come Shiro, Spring Security o esapi di owasp che lasciano la sicurezza gestita dal container. Avendo visto alcuni di related questions su Stack Overflow, mi sono reso conto che la sicurezza basata su container era stata preferita dagli sviluppatori JSF in passato. Ma ho anche raccomandato vivamente di usare Apache Shiro. Sono alle prime armi in termini di problemi di sicurezza e non ho idea di quali potrebbero essere i problemi rilevanti & come gestirli. Quindi sto cercando qualcosa che gestisca la maggior parte dei problemi di sicurezza attraverso le sue impostazioni predefinite/da solo.

In termini di requisiti dell'applicazione, dispongo di un'applicazione social in cui utenti con ruoli diversi hanno accesso a diversi set di pagine e possono utilizzare diversi livelli di funzionalità in tali pagine in base ai rispettivi ruoli.

In tal caso, cosa pensi che potrebbe essere una buona opzione per me?

Personalmente sono stato convinto di optare per Shiro poiché è facile da usare e si prende cura della maggior parte delle cose per i principianti.

+4

Chi lo ha consigliato e quali motivi hanno dato? – EJP

+1

ragioni erano: "con shiro è abbastanza facile configurare la sicurezza, shiro si prende cura della maggior parte dei problemi attraverso le sue impostazioni predefinite, i meccanismi di sicurezza Java esistenti come JAAS sono troppo confusi ecc ecc. Ed è più adatto per un novizio come io che non so molto sui problemi di sicurezza " –

+2

Bene, quindi assumendo tutto ciò che è vero, qual è esattamente la tua domanda? – EJP

risposta

4

Non so esattamente nulla di Apache Shiro eccetto quanto segue, ma quello che hai citato viene praticamente dalla loro , che contiene diverse dichiarazioni errate come "[JAAS] richiede definizioni statiche che solo i programmatori potrebbero cambiare", e "JAAS è legato troppo pesantemente alle preoccupazioni a livello di macchina virtuale" e l'implicazione che JAAS non riguardi utenti e ruoli, il che è semplicemente falso. Vorrei molto convincere ad allontanarmi dalla sicurezza gestita dal container. Fa parte della specifica servlet, quindi deve essere supportato da qualsiasi contenitore; è ben compreso; è supportato da classi JDK senza terze parti; ... e funziona per me ;-)

+2

ma * da quanto ho sentito, * la sicurezza gestita dal container non copre tutto ciò che può soddisfare la richiesta di sicurezza di un'app Web e non è molto semplice per i principianti (nel dominio di sicurezza Web) configurare? Immagino che questi siano i limiti/gli svantaggi degli stessi !? –

+1

@Marcos, è vero, stai indovinando. Vorrei iniziare definendo le tue reali esigenze e poi vedendo quali sistemi possono supportarle. Al momento stai solo ripetendo la pubblicità. – EJP

+0

potrebbe essere .. ma volevo solo sentire l'opinione di esperti su questo prima di iniziare con qualcosa di particolare. –

17

Quello che mi piace di Shiro è che è davvero semplice impostare la sicurezza basata sui permessi. JAAS è fortemente basato sul ruolo che è una granularità che ironicamente è più utile per le applicazioni web dei consumatori rispetto alle app aziendali (come possiamo notare dalle vostre esigenze).

  • E 'comune per un application server per fornire alcuni servizi in cima JAAS, come Single Sign-On, costruita nel LoginModules, ecc, in modo a volte, quando il permesso granularità non è un requisito, si dovrebbe andare per JAAS.

  • L'ultima volta che ho controllato Shiro inoltre, non ha supportato l'autenticazione reciproca SSL (usando i certificati digitali), ma probabilmente non sarebbe utilizzando quel ...

  • Se si utilizza Shiro vostra applicazione sarà probabilmente più portabile tra i server delle applicazioni/i contenitori servlet (oh, l'ironia!), poiché la configurazione della sicurezza JavaEE tende a essere specifica del fornitore per la maggior parte delle configurazioni non banali.

Tutto sommato, in base alle esigenze specificate:

  • Utilizzando un AppServer (GlassFish, JBoss): JAAS (OOTB authc/AuthZ, built-in LoginModules)
  • Utilizzando un servlet container (Molo/Tomcat): Shiro (più facile da installare ed usare)

Speranza che aiuta :)

1

Ho deciso che SpringSecurity (SS) sarà il nostro framework di autenticazione e autorizzazione. Soprattutto perché SS fa OpenID e OAuth. Dovrò personalizzarlo però per il sistema permessi/gruppo/utente/entità piuttosto un po '. Pianifico di eseguire l'autorizzazione a livello di EntityManager/Entity, livello di servizio e livelli Web/API. "Chiudi la porta, ma conserva i tuoi gioielli in una cassaforte da 3 tonnellate nella stanza sul retro" Un sacco dell'ultimo mezzo Shiro gestisce MOLTO meglio. Ma non mi sono sentito a mio agio nel cercare di integrare Openid4j/openauth4j in Shiro.

Sarebbe VERAMENTE bello scegliere e selezionare le funzionalità di entrambi, senza interferenze o codice gonfiato. QUELLA è la scelta migliore

PS, Spring porta molte altre cose alla piastra, inoltre, come l'integrazione con JSF, quindi ha un sacco di fascino.