[J2EE] Richiedere autenticazione accedendo ai Bean con EJB

[magnus]

Ciao ragazzi,
sto tentando di proteggere un EJB in questo modo:

@Stateless
public class MySessionBean implements MySessionBeanRemote, MySessionBeanLocal {

@Resource SessionContext context;

public MySessionBean() {
// TODO Auto-generated constructor stub
}

@RolesAllowed("MAGNUS")
public long getTime() throws SecurityException{
return System.currentTimeMillis();
}
}

Ma utilizzando un client del tipo:

context = new InitialContext(properties);
MySessionBeanRemote bean = (MySessionBeanRemote)context.
lookup("MySessionBean/remote");
long time=bean.getTime();
System.out.println("MySessionBean.getTime() dice: " + new Date(time));

Non ho nessuna difficoltà ad utilizzare il metodo senza autenticazione.

Come fare per richiedere l'autenticazione all'accesso del bean?

Ciao!

[magnus]

up!

[Santinizer]

Originariamente inviato da magnus
Non ho nessuna difficoltà ad utilizzare il metodo senza autenticazione.

puoi verificare se effettivamente non sei autenticato attraverso i metodi context.getCallerPrincipal() e context.isCallerInRole(roleName);

@Resource SessionContext context;     
public long getTime() throws SecurityException{         
    String role = context.getCallerPrincipal().getName();;
    boolean iaCallerInRole = context.isCallerInRole("MAGNUS");
    ....
} 

Per capire meglio la natura del problema, io proverei anche ad applicare temporaneamente @RolesAllowed("MAGNUS") a tutta la classe e/o ad usare @DenyAll. Considera inoltre che dovresti dichiarare tutte le rule utilizzate all'interno della classe prima della firma della classe mediante @DeclareRoles("MAGNUS", ...), anche se in assenza di @DeclareRoles il container in maniera automatica ricava le rule a partire dalle varie @RolesAllowed.
Infine prova ad applicare la 'Sicurezza programmatica' invece della 'Sicurezza dichiarativa'. Non ho mai usato meccanismi di sicurezza a livello di EJB e ho reperito alcune informazioni al link http://www.giuseppesicari.it/articol...javabeans-ejb/.
Ciao.

[magnus]

Originariamente inviato da Santinizer
puoi verificare se effettivamente non sei autenticato attraverso i metodi context.getCallerPrincipal() e context.isCallerInRole(roleName);

@Resource SessionContext context;     
public long getTime() throws SecurityException{         
    String role = context.getCallerPrincipal().getName();;
    boolean iaCallerInRole = context.isCallerInRole("MAGNUS");
    ....
} 

Per capire meglio la natura del problema, io proverei anche ad applicare temporaneamente @RolesAllowed("MAGNUS") a tutta la classe e/o ad usare @DenyAll. Considera inoltre che dovresti dichiarare tutte le rule utilizzate all'interno della classe prima della firma della classe mediante @DeclareRoles("MAGNUS", ...), anche se in assenza di @DeclareRoles il container in maniera automatica ricava le rule a partire dalle varie @RolesAllowed.
Infine prova ad applicare la 'Sicurezza programmatica' invece della 'Sicurezza dichiarativa'. Non ho mai usato meccanismi di sicurezza a livello di EJB e ho reperito alcune informazioni al link http://www.giuseppesicari.it/articol...javabeans-ejb/.
Ciao.

Sia @RolesAllowed("MAGNUS") che @DenyAll sembra che vengano ignorati

Con context.isCallerInRole("MAGNUS") invece ottengo una NULL Pointer exception.

Nota: sto utilizzando la Sicurezza dichiarativa.

[Santinizer]

Originariamente inviato da magnus
Con context.isCallerInRole("MAGNUS") invece ottengo una NULL Pointer exception.

Non dovrebbe succedere, visto che la creazione di context viene gestita dal container (tramite la Resource Injection).Quindi context non dovrebbe essere null a meno di problemi in fase di avvio del server o deploy dell'applicazione.
Io ti consiglierei di spegnere il server, ripulire i log, avviare il server, deployare l'applicazione e controllare se nei log appare qualche messaggio sospetto. Prova a documentarti con ricerche tipo ' SessionContext NullPointerException '.
Come altra alternativa potresti reistallare l'application server.
Ciao.

[magnus]

Originariamente inviato da Santinizer
Non dovrebbe succedere, visto che la creazione di context viene gestita dal container (tramite la Resource Injection).Quindi context non dovrebbe essere null a meno di problemi in fase di avvio del server o deploy dell'applicazione.
Io ti consiglierei di spegnere il server, ripulire i log, avviare il server, deployare l'applicazione e controllare se nei log appare qualche messaggio sospetto. Prova a documentarti con ricerche tipo ' SessionContext NullPointerException '.
Come altra alternativa potresti reistallare l'application server.
Ciao.

Beh in realtà il context ( creato con @Resource SessionContext context; ) nei watch esiste e non è nullo.

Indagherò.