Accès à des EJB3 déployé sous JBoss

Bonjour,

J'essai d'écrire un client distant utilisant des EJB 3 (sur un serveur JBoss). J'ai passé l'étape de la persistence, et je me cogne maintenant à la phase d'authentification.
J'ai déjà réussit à faire un petit client qui accède à bean session protégé par l'annotations @RolesAllowed.
Cependant les seul exemples que j'ai trouvé sur le net font référence à l'annotation @SecurityDomain (apparemment une annotation propre à JBoss) avec l'attribut "other", indiquant à JBoss que les login / mdp et les roles sont stocké dans de simples fichiers properties.
Je voudrais donc pouvoir récupérer ses infos à partir d'une BD Relationnelle (la même que celle utilisée par les bean entités).

Si vous avez des exemples, des tuts, des liens ...

Merci d'avance,

Bruno

- coté serveur: utiliser org.jboss.security.auth.spi.DatabaseServerLoginModule
et préciser les requtes SQL pour aller chercher les info user/pass/roles dans le config.xml
si ca marche, conseil de le coder toi meme

- coté client: utiliser ClientLoginModule pour passer les Credential (ne pas utiliser jndi) et parametrer un ficher client-auth.xml par ex pour définir la politique a propoager vers le seveur, suivant le modele jaas:
politique{
module;
}

plein de tuto sur jboss.com, jbossSX

Super merci !
J'essai tout ça ...

Voilà un petit bilan suivit de questions :

* Côté serveur :

J'ai modifié le fichier login-config.xml (situé dans le rep. server/xxx/conf) pour y ajouter ceci :

Citation:

---

<application-policy name="wiskee">
<login-module code="org.jboss.security.ClientLoginModule" flag="required">
</login-module>
<login-module code = "org.jboss.security.auth.spi.DatabaseServerLoginModule"
flag = "required">
<!-- A quoi sert cette option ?
<module-option name = "unauthenticatedIdentity">guest</module-option> -->
<module-option name = "dsJndiName">java:/DefaultDS</module-option>
<module-option name = "principalsQuery">SELECT mdp FROM utilisateur WHERE id=?</module-option>
<module-option name = "rolesQuery">SELECT role, roleGroup FROM role WHERE id_utilisateur=?</module-option>
</login-module>
</authentication>
</application-policy>

---

* Mes bean session utilisent alors le domain wiskee avec l'annotation @SecurityDomain("wiskee")

- Question :

* Dans le tutorial JAAS de sun la partie client de connexion ressemble à ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

try { SecurityAssociationHandler handler = new SecurityAssociationHandler(); Principal user = new SimplePrincipal("bruno"); handler.setSecurityInfo(user, "lemdp"); LoginContext loginContext = new LoginContext("wiskee", (CallbackHandler)handler); loginContext.login();   Subject subject = loginContext.getSubject(); Set<Principal> principals = subject.getPrincipals(); principals.add(user); }catch(LoginException e) { e.printStackTrace(); }

---

J'utilise le CallbackHandler fournit par JBoss pour simplifier.

Je me pose donc la question suivante : en quoi cette étape est-elle nécessaire ? Le bout de code suivant marche trés bien sans:

Code:

---

1 2 3 4 5 6 7 8

Properties env = new Properties(); env.setProperty(Context.SECURITY_PRINCIPAL, "bruno"); env.setProperty(Context.SECURITY_CREDENTIALS, "lemauvaismdp"); env.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.security.jndi.JndiLoginInitialContextFactory"); InitialContext context = new InitialContext(env);   Massifs massifs = (Massifs) context.lookup(Massifs.class.getName());

---

Je récupère mon bean de session, le serveur va chercher dans la BD le login et le mot de passe sans problème.
Sinon comment utiliser le Subject obtenu avec le LoginContext dans le InitialContext (au lieu d'utiliser un objet Properties) ?

tout d'abord le clientloginmodule n'est pas spécialement utile coté serveur
- le required signifie simplement qu'il est nécessaire de réusiir cette autehentification, meme si l'autehntification a reussi pour d'autres module defini dans ta politique

Citation:

---

je me pose donc la question suivante : en quoi cette étape est-elle nécessaire ? Le bout de code suivant marche trés bien sans:
Code:

Properties env = new Properties();
env.setProperty(Context.SECURITY_PRINCIPAL, "bruno");
env.setProperty(Context.SECURITY_CREDENTIALS, "lemauvaismdp");
env.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.security.jndi.JndiLoginInitialContextFactory");
InitialContext context = new InitialContext(env);

Massifs massifs = (Massifs) context.lookup(Massifs.class.getName());

---

--> a rien, c'est ce que je te precisais en disant ed ne rien passer via jndi. Pour la ptite explication, le contexte que tu positionne est le contexte client , contexte que ne peut pas voir le serveur...

Citation:

---

Sinon comment utiliser le Subject obtenu avec le LoginContext dans le InitialContext (au lieu d'utiliser un objet Properties) ?

---

g pas bien sais ta question, par conter tu peux acceder au subject dasn tes ejb si tu initialise le Context dasn ejbLoad()

Citation:

---

tout d'abord le clientloginmodule n'est pas spécialement utile coté serveur

---

OK j'avait cru comprendre en lisant un post qu'il le fallait. Effectivement ça marche sans.

Citation:

---

--> a rien, c'est ce que je te precisais en disant ed ne rien passer via jndi. Pour la ptite explication, le contexte que tu positionne est le contexte client , contexte que ne peut pas voir le serveur...

---

Attention je vais peut-être dire une connerie :oops: ...

D'après le bout de code précédent (env.setProperty(...CREDENTIALS,"lemdp")) j'utilise JNDI. Alors comment faire pour "ne rien passer via jndi" ?

En fait je pensais que pour ne pas utiliser JNDI il fallait passer par cette phase de login avec JAAS. Et qu'a la suite de cette étape on obtenait un objet (contenant login/mdp) permettant à JNDI de prendre la suite. Car c'est grâce à JNDI que j'obtient mes références distantes (apparemment JBoss utilise CORBA pour la communication client/serveur ?).

Citation:

---

par conter tu peux acceder au subject dasn tes ejb si tu initialise le Context dasn ejbLoad()

---

J'utilise les EJB 3 donc pas de ejbLoad()

autant pour moi!
je croyais que tu parlai de la méthode env.setProperty(...)
mais je crois que cette facon de faire est déconseillée
préfere la méthode avec jass