Apache Shiro su un client Swing - Caso EJB 3.1 per autorizzazione dell'autenticazione

Question

Caso generale: Una semplice applicazione che espone i suoi servizi tramite EJB (3.1) - la maggior parte dei bean di Stateless Sessions (nulla funziona qui) e client basati su SWING questo, chiama attraverso le interfacce remote questi servizi e fai quello che devono fare.

Sicurezza: Voglio autenticare/autorizzare questo ciclo di chiamate e, naturalmente, proteggere i miei servizi. La risposta ovvia sarebbe utilizzare JAAS nel server e qualsiasi configurazione di cablaggio personalizzata sul server sottostante. Che è ancora un'opzione

Apache Shiro: Così un sacco di gente parla di Apache Shiro e in effetti offre un API molto semplice e il meccanismo - che potrebbe essere potenzialmente application server indipendenti.

Domande tecniche:

1. Sessione: Nel mio caso io non sono una sessione HTTP - e da quello che ho capito Shiro almeno bisogno di una sorta di ID di sessione che ho bisogno di passare intorno. Un modo carino per iniettare le credenziali utente nelle mie chiamate RMI/IIOP al server senza interferire con la mia API aziendale?

2. applicazione lato server: Per le poche risorse che ho vissuto credo di poter implementare uno Shiro DefaultSecurityManager da 'riferimento e' da un 3.1 fagioli Singleton EJB. Altre idee? Quindi posso facilmente creare un intercettore e aggiungerlo alle mie chiamate remote - così quando una nuova chiamata passa attraverso il mio metodo EJB remoto - lo Shiro Intereceptor per convalidare il mio utente o verificare i diritti specifici.

Eventuali commenti/suggerimenti/esempi?

Molte grazie

Answer 1

Da shiro, provare a utilizzare un modello ServiceLocator. La ricerca di EJB è diversa tra i contenitori (JBoss, Netweaver, Weblogig, ecc.).

In Application Server, provare a utilizzare i vincoli di sicurezza basati sul contenitore (@RolesAllowed, @PermitAll, @Deny ...). JAAS creerà l'oggetto con i principal dell'utente, quindi usa semplicemente l'autorizzazione del contenitore (@RolesAllowed, @PermitAll, @Deny ...). Può essere migliore quando si esegue la migrazione da un contenitore all'altro.