[EJB3] [LDAP] Sécurisation des EJB3, quelque chose m'échappe.

**balibalo** · 20/11/2007, 09h06

Bonjour,

Je rencontre de grosse difficulté à mettre en place un système d'EJB3 sécurisé via JAAS. Sachant que toute mes données utilisateur sont dans une "base" LDAP.

Pour info: j'utilise JBOSS-4.2.1-GA sous Linux avec NetBeans 5.5 comme IDE.

Mon application EJB est accessible via une servlet, cette dernière reçoit les requêtes HTTP et selon les paramètres et la session elle sait quoi faire.

Tel que j'ai compris le concept j'ai implémenté ceci, pour la requête login:
- la servlet utilise une méthode appellée login
- à l'intèrieur, elle va appeller une méthode de classe qui va authentifier le user/pass (donné en paramètre). Cette méthode renvoit un LoginContext:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
    public static LoginContext authenticate(String username, String password)
    {
        UsernamePasswordHandler handler = 
            new UsernamePasswordHandler(username, password.toCharArray());
 
        LoginContext lc = null;
        try
        {
            lc = new LoginContext("monapp", handler);
            lc.login();        
        } 
        catch (LoginException ex)
        {
            ex.printStackTrace();
            return null;
        }        
 
        return lc;
    }

"monapp" renvoyant à la configuration application-policy correspondante, celle ci appelle le module org.jboss.security.auth.spi.LdapExtLoginModule avec les bons paramètres qu'il faut pour LDAP...

- si le LoginContext renvoyé est différent de null alrs je charge mon EJB :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
Context context = new InitialContext();
AppRemoteIFace app = (AppRemoteIFace)context.lookup("appli/app/remote");
//et je met app dans la session http, mais là déjà j'imagine que c'est pas la bonne chose à faire, si?
HttpSession session = req.getSession();
session.setAttribute(SESSION_APP_BEAN, app);

- à la requete suivante, je fais bêtement:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
AppRemoteIFace as = (appRemoteIFace)getFromSession(req, SESSION_APP_BEAN);
try
 {   
   app.foo();
 }
catch (Exception e)
  {
    System.err.println("app.foo failed");
    e.printStackTrace();
  }

Le problème:
le login se passe bien, il utilise bien le module, l'authentification passe etc... Et si je test app.foo() dans la foulée ça fonctionne bien, (ou app.fooAdmin(), si l'utilisateur n'a pas le role admin: j'ai bel est bien une exception du au manque de droits etc...)

MAIS: à la requête suivante, impossible de lancer app.foo() ou autre, on dirait que l'EJB perd le contexte et qu'il sait pas quoi faire.

Le seul hack tout moche qui résout ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
SecurityAssociation.setPrincipal(new SimplePrincipal((String)getFromSession(req, SESSION_USERNAME)));
SecurityAssociation.setCredential((String)getFromSession(req, SESSION_PASSWORD));

avant app.foo(); et là ça fonctionne.

Mais je sais que c'est pas la bonne manière, il y a quelque chose qui m'échappe. Ai-je oublié quelque chose côté EJB? C'est plus que probable, voilà le code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
@Stateless
public class App implements AppRemoteIFace, AppLocalIFace
{
 
   @RolesAllowed({"admin"})
   public String fooAdmin()
   {
      return "fooAdmin";
   }
 
   @RolesAllowed({"user"})
   public String foo()
   {
      return "foo";
   }
}

Et les deux interfaces:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
@Remote
public interface AppRemoteIFace
{
   public String fooAdmin();
   public String foo();
}

et:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
@Local
public interface AppLocalIFace
{
   public String fooAdmin();
   public String foo();
}

Je suis perdu.

Le gros soucis que j'ai c'est aussi de trouver de la bonne documentation à jour, je trouve des tas d'exemples complet pour ejb2 mais pas ejb3 (or il y a de sacrées différences!). Si vous en avez à me proposer qui parle d'un exemple identique (ejb3+jaas+ldap ça "devrait être" assez commun non?) je suis preneur.

Merci de votre aide!

**OButterlin** · 20/11/2007, 09h32

Comme l'attribut l'indique, @Stateless signifie "sans état" donc pas de conservation...
Tu devrais essayer avec @Statefull, ça devrait règler ton problème...

A+

**balibalo** · 20/11/2007, 09h45

Envoyé par OButterlin

Tu devrais essayer avec @Statefull, ça devrait règler ton problème...

Même erreur, le stack trace me donne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

10:34:47,794 ERROR [STDERR] javax.ejb.EJBAccessException: Authentication failure

**manblaizo** · 20/11/2007, 11h09

Envoyé par balibalo

Le gros soucis que j'ai c'est aussi de trouver de la bonne documentation à jour, je trouve des tas d'exemples complet pour ejb2 mais pas ejb3 (or il y a de sacrées différences!).

Non, je ne pense pas qu'il y ait une sacrée différence entre ejb2 et ejb3 sur le plan de la sécurité. Si tu trouves quelque chose qui fonctionne bien pour ejb2, ça devrait fonctionner de la même manière pour ejb3, car ejb3 a apporté des changements sur le modèle de programmation et de déploiement, mais pas sur l'architecture, sinon tous les modules des serveurs d'applications seraient à réécrire totalement, ce qui n'est pas le cas. Il faudrait donc essayer d'adapter les exemples que tu as pour ejb2 vers ejb3.

**balibalo** · 20/11/2007, 11h09

Dans le e-book sur les EJB3 (voir en post-it) il est dit au chapitre 11 Security: " Authentication must be performed before any EJB method is called. Authorization, on the other hand, occurs at the beginning of each EJB method call."

Je pensais que l'authentification survenait une seule fois, permettant alors de récupérer les rôles (si succès) et d'instancier l'EJB. Après, à chaque appel de méthode, l'autorisation est faite selon le contexte de cette instance (si le rôle nécessaire est présent ou non).
Il semblerait que j'ai faux donc. Dans ce cas: où l'EJB est censé trouver les informations nécessaire à l'authentification à chaque fois qu'une méthode de ce dernier est appelé?
Est-ce dans le LoginContext? (ce qui voudrait dire qu'à l'instanciation de l'EJB ce LoginContext viens s'ajouter à l'InitialContext et que l'EJB se l'approprie, non? oui?)
Dans ce cas, est ce que le LoginModule utilisé doit garder l'information quelque part (Principal, Credentials)?

**balibalo** · 20/11/2007, 12h18

Voilà le LoginModule:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
 
public class AppLoginModule
    extends UsernamePasswordLoginModule
{
 
    /**
     * Creates a new instance of AppLoginModule
     */
    public AppLoginModule()
    {
        super();
    }
 
    private transient SimpleGroup userRoles = new SimpleGroup("Roles");
 
	public boolean validatePassword(String inputPassword, String expectedPassword)
        {		
            boolean result = false;
            UserDTO user = new UserDTO(this.getUsername(), inputPassword);
            UserDAO userDao = DAOFactory.getFactory(DAOFactory.TYPE_LDAP).getUserDAO();
 
                System.err.println("Attempting to validate user "+getUsername()+", password: "+inputPassword);
                result = userDao.validateUser(user);                
 
            if(result)
            {
                PasswordCredential pc = new PasswordCredential(getUsername(),inputPassword.toCharArray());
 
                subject.getPrivateCredentials().add(pc);
            }
 
            System.err.println("Subject : "+subject.getPrivateCredentials().toString());
 
            System.err.println("validatePassword result: "+result);
            return result;
	}
 
 
	public String getUsersPassword() throws LoginException {
		return "";
	}
 
	public Group[] getRoleSets() throws LoginException 
        {
            System.err.println("called getRoleSets");
 
            List<RoleDTO> list = new ArrayList<RoleDTO>();
 
            RoleDAO roleDao = DAOFactory.getFactory(DAOFactory.TYPE_LDAP).getRoleDAO();
 
                list = roleDao.getRolesForUsername(this.getUsername());		
 
            Iterator it = list.iterator();
 
            while(it.hasNext())
            {
                    RoleDTO role = (RoleDTO) it.next();
                    userRoles.addMember(new SimplePrincipal(role.getRoleName()));
            }					
 
            Group[] roleSets = {userRoles};
 
            System.err.println("list of roles: "+roleSets);
 
            return roleSets;
	}    
 
    public boolean logout() throws LoginException
    {
        System.err.println(" * * * AppLoginModule.logout() * * *");
        return super.logout();
    }
 
}

Et voilà la sortie d'erreur (où on voit bien que l'on "perd" les informations de l'utilisateur:
La requête de login:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
12:58:13,643 ERROR [STDERR] Attempting to validate user toto, password: tutu
12:58:13,647 ERROR [STDERR] encryptSHA(user.getPassword()): 4e4Z4uLF92L3neRCnsfvBh5DSZc=
12:58:13,668 ERROR [STDERR] Subject : [javax.resource.spi.security.PasswordCredential@3569e1]
12:58:13,668 ERROR [STDERR] validatePassword result: true
12:58:13,669 ERROR [STDERR] called getRoleSets
12:58:13,689 ERROR [STDERR] getGroupsForUsername(toto) returned 1 groups
12:58:13,708 ERROR [STDERR] getRolesForGroupName(users) returned 1 roles
12:58:13,708 ERROR [STDERR] getRolesForUsername(toto) returned 1 roles
12:58:13,710 ERROR [STDERR] list of roles: [Ljava.security.acl.Group;@785b38d6

Et la requête foo:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
13:12:37,602 ERROR [STDERR] Attempting to validate user null, password: null
13:12:37,602 ERROR [STDERR] encryptSHA(user.getPassword()): null
13:12:37,682 ERROR [STDERR] Subject : []
13:12:37,682 ERROR [STDERR] validatePassword result: false
13:12:37,723 ERROR [STDERR] app.foo failed for toto
13:12:37,723 ERROR [STDERR] javax.ejb.EJBAccessException: Authentication failure
13:12:37,723 ERROR [STDERR] 	at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.handleGeneralSecurityException(Ejb3AuthenticationInterceptor.java:68)
13:12:37,723 ERROR [STDERR] 	at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:70)
13:12:37,724 ERROR [STDERR] 	at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:106)
13:12:37,724 ERROR [STDERR] 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
13:12:37,724 ERROR [STDERR] 	at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
13:12:37,724 ERROR [STDERR] 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
13:12:37,724 ERROR [STDERR] 	at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
13:12:37,724 ERROR [STDERR] 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
13:12:37,724 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:333)
13:12:37,724 ERROR [STDERR] 	at org.jboss.ejb3.remoting.IsLocalInterceptor.invokeLocal(IsLocalInterceptor.java:79)
13:12:37,725 ERROR [STDERR] 	at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:70)
13:12:37,725 ERROR [STDERR] 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
13:12:37,725 ERROR [STDERR] 	at org.jboss.ejb3.stateful.StatefulRemoteProxy.invoke(StatefulRemoteProxy.java:135)
13:12:37,725 ERROR [STDERR] 	at $Proxy68.foo(Unknown Source)

Où sont sensés être stocké les Principals/Credentials de l'utilisateur une fois que ce dernier est loggé? (je perd le contexte mais je ne sais ni pourquoi ou alors comment le retrouver. Avec le hack, sur mon premier post ça fonctionne mais je suis pas censé faire ça)

**balibalo** · 20/11/2007, 12h35

Envoyé par manblaizo

Il faudrait donc essayer d'adapter les exemples que tu as pour ejb2 vers ejb3.

Cet exemple est "assez" complet (même si il ne traite pas du tout de la manière à interagir avec LDAP) http://www.javaworld.com/javaworld/j...as.html?page=1
C'est le seul que j'ai trouvé de potable.

**balibalo** · 20/11/2007, 15h07

Je vous passe la config (peut-etre ai-je fait une bêtise là dedans)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
<mbean code="org.jboss.naming.ExternalContext"
       name="jboss.jndi:service=ExternalContext,jndiName=external/ldap/jboss">
    <attribute name="JndiName">external/ldap/jboss</attribute>
    <attribute name="Properties">
        java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
        java.naming.provider.url=ldap://zog.net:389
        java.naming.security.principal=cn=admin,dc=jkl,dc=cellx,dc=net
        java.naming.security.authentication=simple
        java.naming.security.credentials=niark
    </attribute>
    <attribute name="InitialContext"> javax.naming.ldap.InitialLdapContext </attribute>
    <attribute name="RemoteAccess">true</attribute>
</mbean>

login-config.xml:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
<application-policy name="app">
		<authentication>
			<login-module code="com.truc.muche.app.security.AppLoginModule" flag="required" />
			<login-module code="org.jboss.security.ClientLoginModule" flag="required" >
				<module-option name="multi-threaded">true</module-option>
				<!--<module-option name="password-stacking">useFirstPass</module-option>-->
				<!--<module-option name="restore-login-identity">true</module-option>-->
			</login-module>
		</authentication>
	</application-policy>

Personne n'a d'idée? J'ai vraiment besoin d'une piste là

**hellsbells** · 20/11/2007, 17h24

effectivement l'info est perdu !
- pourquoi il y'a cet écart de temps entre la req d'émission et l'objet reçu de 12:58 à 13:12 ?
- as tu la main sur d'autre traces ? peux tu activer celles des autres modules ldap et jass ... ?

**balibalo** · 20/11/2007, 19h00

Envoyé par hellsbells

effectivement l'info est perdu !
- pourquoi il y'a cet écart de temps entre la req d'émission et l'objet reçu de 12:58 à 13:12 ?

C'est rien je me suis emmélé les pinceaux dans les logs

, mais le contenu reste le même.

Envoyé par hellsbells

- as tu la main sur d'autre traces ? peux tu activer celles des autres modules ldap et jass ... ?

Je verrais ça demain. (le code n'est pas chez moi)

Sinon pour résumer l'affaire j'ai bel et bien une "perte" du contexte. J'ai ajouté la "@Resource" SessionContext au bean mais ça ne change rien. Bon j'ai aussi un soucis de LDAP en fait, car ici l'app utilise toujours le user admin pour accéder à LDAP (il va chercher si tel user possède bien tel pass...). Illogique puisque le user/pass utilisé dans le login doit correspondre à un login effectif sur LDAP (j'ai tenté le coup via l'outil ldapsearch en console et ça fonctionne). Je vais corriger ça.
Ça n'explique pas par contre cette perte de contexte, y aurait-il quelque chose qui vous choque, qui manque dans le code?

**hellsbells** · 20/11/2007, 21h41

le chemin mentionné ci-dessous existe bien ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

java.naming.security.principal=cn=admin,dc=jkl,dc=cellx,dc=net

et je suppose que le paramétrage du ldap en conf est le bon (réel),

sinon je ne vois pas.
j'arrête aussi pr ce soir ...

A+

**balibalo** · 20/11/2007, 22h01

Envoyé par hellsbells

le chemin mentionné ci-dessous existe bien ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

java.naming.security.principal=cn=admin,dc=jkl,dc=cellx,dc=net

et je suppose que le paramétrage du ldap en conf est le bon (réel),

C'est en effet le bon chemin, tout ceci fonctionne oui. C'est pas ça

(en tout cas pas ce qui fait que je perds mon contexte)

Au fait j'y pense: vu que je ne fais pas une véritable authentification au travers d'LDAP (ici c'est toujours le user admin qui recherche le user pour le login donné, puis compare le password ensuite...métode pourrie oui oui

), est ce que ça pourrait être à l'origine d'un "phénomène" tel que le LdapExtLoginModule ne met pas en place le bon contexte (gardant le bon couple PrivateCredentials dans la session etc...)?
Je le saurais de toute manière demain (puisque cette fois les users vont bien être authentifé oau travers d'LDAP directement), mais je me demandais si ma méthode bancale actuelle n'était pas une source possible d'effets de bord...

**balibalo** · 21/11/2007, 09h57

Humpf... je galère toujours autant

Y a rien à faire. (en plus j'arrive pas à mettre en place un mode plus verbeux la sortie de JBOSS...en ayant pourtant suivis la doc à ce sujet)

Personne n'a utilisé cette combinaison: EJB3 + JAAS + LDAP?
je commence à désespérer là, les exemples sur net manquent toujours d'un truc ou deux...et pour ce qui est d'adapter de l'ejb2 vers de l'ejb3...ben les annotations sont censé faire le boulot non? (@Stateful suffit, plus besoin d'implémenter l'interface SessionBean, le context lookup permet de récupérer un bean, plus besoin de récupérer l'interface et d'appelle create() etc...)

[EDIT] Ah si j'ai bien plus de sortie (je regardais pas là où il faut)
Le login:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
2007-11-21 10:56:56,952 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635416952 sessioncount 0
2007-11-21 10:56:56,952 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 10:56:56,952 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635416952 sessioncount 0
2007-11-21 10:56:56,952 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 10:56:56,953 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635416953 sessioncount 0
2007-11-21 10:56:56,953 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 10:56:56,953 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635416953 sessioncount 0
2007-11-21 10:56:56,953 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 10:56:56,953 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635416953 sessioncount 0
2007-11-21 10:56:56,953 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 10:56:56,953 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635416953 sessioncount 0
2007-11-21 10:56:56,953 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 10:57:06,955 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635426954 sessioncount 1
2007-11-21 10:57:06,955 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 1 expired sessions: 0
2007-11-21 10:57:18,588 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] Periodic recovery - first pass <mer., 21 nov. 2007 10:57:18>
2007-11-21 10:57:18,589 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] StatusModule: first pass 
2007-11-21 10:57:18,589 DEBUG [com.arjuna.ats.txoj.logging.txojLoggerI18N] [com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_3] - TORecoveryModule - first pass
2007-11-21 10:57:18,589 DEBUG [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.info.firstpass] Local XARecoveryModule - first pass
2007-11-21 10:57:28,590 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] Periodic recovery - second pass <mer., 21 nov. 2007 10:57:28>
2007-11-21 10:57:28,591 DEBUG [com.arjuna.ats.arjuna.logging.arjLogger] AtomicActionRecoveryModule: Second pass 
2007-11-21 10:57:28,591 DEBUG [com.arjuna.ats.txoj.logging.txojLoggerI18N] [com.arjuna.ats.internal.txoj.recovery.TORecoveryModule_6] - TORecoveryModule - second pass
2007-11-21 10:57:28,591 DEBUG [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.info.secondpass] Local XARecoveryModule - second pass
2007-11-21 10:57:56,966 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635476966 sessioncount 0
2007-11-21 10:57:56,966 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 10:57:56,966 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635476966 sessioncount 0
2007-11-21 10:57:56,966 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 10:57:56,966 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635476966 sessioncount 0
2007-11-21 10:57:56,966 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 10:57:56,966 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635476966 sessioncount 0
2007-11-21 10:57:56,966 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 10:57:56,967 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635476967 sessioncount 0
2007-11-21 10:57:56,967 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 10:57:56,967 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635476967 sessioncount 0
2007-11-21 10:57:56,967 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 10:58:06,969 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635486969 sessioncount 1
2007-11-21 10:58:06,969 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 10:58:56,983 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635536983 sessioncount 0
2007-11-21 10:58:56,983 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 10:58:56,983 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635536983 sessioncount 0
2007-11-21 10:58:56,983 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 10:58:56,983 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635536983 sessioncount 0
2007-11-21 10:58:56,983 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 10:58:56,983 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635536983 sessioncount 0
2007-11-21 10:58:56,983 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 10:58:56,984 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635536984 sessioncount 0
2007-11-21 10:58:56,984 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 10:58:56,984 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635536984 sessioncount 0
2007-11-21 10:58:56,984 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 10:59:02,136 DEBUG [org.apache.catalina.connector.CoyoteAdapter]  Requested cookie session id is 50729D54D431260B96E458A1D425CCC2
2007-11-21 10:59:02,137 ERROR [STDERR] Attempting to validate user toto, password: tutu
2007-11-21 10:59:02,137 ERROR [STDERR] encryptSHA(user.getPassword()): 4e4Z4uLF92L3neRCnsfvBh5DSZc=
2007-11-21 10:59:02,163 ERROR [STDERR] validatePassword result: true
2007-11-21 10:59:02,164 ERROR [STDERR] called getRoleSets
2007-11-21 10:59:02,185 ERROR [STDERR] getGroupsForUsername(toto) returned 1 groups
2007-11-21 10:59:02,206 ERROR [STDERR] getRolesForGroupName(users) returned 1 roles
2007-11-21 10:59:02,206 ERROR [STDERR] getRolesForUsername(riku) returned 1 roles
2007-11-21 10:59:02,207 ERROR [STDERR] list of roles: [Ljava.security.acl.Group;@48ffb301
2007-11-21 10:59:06,985 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635546985 sessioncount 1
2007-11-21 10:59:06,985 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0

La requête foo:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
2007-11-21 11:00:07,000 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635607000 sessioncount 1
2007-11-21 11:00:07,000 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 11:00:57,011 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635657011 sessioncount 0
2007-11-21 11:00:57,011 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 11:00:57,012 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635657012 sessioncount 0
2007-11-21 11:00:57,012 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 11:00:57,012 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635657012 sessioncount 0
2007-11-21 11:00:57,012 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 11:00:57,012 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635657012 sessioncount 0
2007-11-21 11:00:57,013 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 1 expired sessions: 0
2007-11-21 11:00:57,013 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635657013 sessioncount 0
2007-11-21 11:00:57,013 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 11:00:57,015 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635657013 sessioncount 0
2007-11-21 11:00:57,015 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 2 expired sessions: 0
2007-11-21 11:01:07,017 DEBUG [org.apache.catalina.session.ManagerBase] Start expire sessions StandardManager at 1195635667017 sessioncount 1
2007-11-21 11:01:07,017 DEBUG [org.apache.catalina.session.ManagerBase] End expire sessions StandardManager processingTime 0 expired sessions: 0
2007-11-21 11:01:26,354 DEBUG [org.apache.catalina.connector.CoyoteAdapter]  Requested cookie session id is 50729D54D431260B96E458A1D425CCC2
2007-11-21 11:01:26,356 ERROR [STDERR] Attempting to validate user null, password: null
2007-11-21 11:01:26,356 ERROR [STDERR] encryptSHA(user.getPassword()): null
2007-11-21 11:01:26,373 ERROR [STDERR] validatePassword result: false
2007-11-21 11:01:26,373 DEBUG [com.truc.muche.security.AppLoginModule] Bad password for username=null
2007-11-21 11:01:26,373 DEBUG [org.jboss.ejb3.security.Ejb3AuthenticationInterceptor] Authentication failure
javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required
	at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:213)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
	at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
	at org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:603)
	at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:537)
	at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:344)
	at org.jboss.aspects.security.AuthenticationInterceptor.authenticate(AuthenticationInterceptor.java:123)
	at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:66)
	at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:106)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:278)
	at org.jboss.ejb3.remoting.IsLocalInterceptor.invokeLocal(IsLocalInterceptor.java:79)
	at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:70)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:103)
	at $Proxy78.fooUser(Unknown Source)
	at com.truc.muche.web.RARequestHandler.proceed(RARequestHandler.java:152)
	at com.truc.muche.web.AppServlet.doPost(AppServlet.java:54)
	at com.truc.muche.web.AppServlet.doGet(AppServlet.java:45)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:595)
2007-11-21 11:01:26,377 ERROR [STDERR] as.foo failed for toto
2007-11-21 11:01:26,377 ERROR [STDERR] javax.ejb.EJBAccessException: Authentication failure
2007-11-21 11:01:26,377 ERROR [STDERR] 	at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.handleGeneralSecurityException(Ejb3AuthenticationInterceptor.java:68)
2007-11-21 11:01:26,377 ERROR [STDERR] 	at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:70)
2007-11-21 11:01:26,377 ERROR [STDERR] 	at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:106)
2007-11-21 11:01:26,378 ERROR [STDERR] 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
2007-11-21 11:01:26,378 ERROR [STDERR] 	at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
2007-11-21 11:01:26,378 ERROR [STDERR] 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
2007-11-21 11:01:26,378 ERROR [STDERR] 	at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
2007-11-21 11:01:26,378 ERROR [STDERR] 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
2007-11-21 11:01:26,378 ERROR [STDERR] 	at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:278)
2007-11-21 11:01:26,378 ERROR [STDERR] 	at org.jboss.ejb3.remoting.IsLocalInterceptor.invokeLocal(IsLocalInterceptor.java:79)
2007-11-21 11:01:26,378 ERROR [STDERR] 	at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:70)
2007-11-21 11:01:26,378 ERROR [STDERR] 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
2007-11-21 11:01:26,378 ERROR [STDERR] 	at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:103)
2007-11-21 11:01:26,378 ERROR [STDERR] 	at $Proxy78.foo(Unknown Source)
2007-11-21 11:01:26,378 ERROR [STDERR] 	at com.truc.muche.web.RARequestHandler.proceed(RARequestHandler.java:152)
2007-11-21 11:01:26,378 ERROR [STDERR] 	at com.truc.muche.web.AppServlet.doPost(AppServlet.java:54)
2007-11-21 11:01:26,378 ERROR [STDERR] 	at com.truc.muche.web.AppServlet.doGet(AppServlet.java:45)
2007-11-21 11:01:26,378 ERROR [STDERR] 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
2007-11-21 11:01:26,379 ERROR [STDERR] 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
2007-11-21 11:01:26,379 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
2007-11-21 11:01:26,379 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
2007-11-21 11:01:26,379 ERROR [STDERR] 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
2007-11-21 11:01:26,379 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
2007-11-21 11:01:26,379 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
2007-11-21 11:01:26,379 ERROR [STDERR] 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
2007-11-21 11:01:26,379 ERROR [STDERR] 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
2007-11-21 11:01:26,379 ERROR [STDERR] 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
2007-11-21 11:01:26,379 ERROR [STDERR] 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
2007-11-21 11:01:26,379 ERROR [STDERR] 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
2007-11-21 11:01:26,379 ERROR [STDERR] 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
2007-11-21 11:01:26,379 ERROR [STDERR] 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
2007-11-21 11:01:26,379 ERROR [STDERR] 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
2007-11-21 11:01:26,379 ERROR [STDERR] 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
2007-11-21 11:01:26,380 ERROR [STDERR] 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
2007-11-21 11:01:26,380 ERROR [STDERR] 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
2007-11-21 11:01:26,380 ERROR [STDERR] 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
2007-11-21 11:01:26,380 ERROR [STDERR] 	at java.lang.Thread.run(Thread.java:595)

En espérant que ça vous donne la puce à l'oreille.
[/EDIT]

**hellsbells** · 21/11/2007, 14h05

au fait je viens de voir cette trace ?!
$Proxy68.foo(Unknown Source)

c'est plus un prob de connexion et d'accès, avant même le chargement du contexte. n'as tu pas plus d'info en mode debug ?

**balibalo** · 21/11/2007, 14h25

Envoyé par hellsbells

c'est plus un prob de connexion et d'accès, avant même le chargement du contexte. n'as tu pas plus d'info en mode debug ?

Je peux tenter le mode TRACE mais ça va etre verbeux

[EDIT]
Eh ben, ça cause dans le poste!

Ceci dit, rien qui en dises plus au sujet de ce

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

15:18:07,736 ERROR [STDERR] 	at $Proxy68.foo(Unknown Source)

Par contre - ce qui me fait d'ailleurs penser que je suis sur la bonne voie car j'ai déjà commencer à bosser là dessus - ça m'indique que le SecurityAssociation est pas le "bon". Il ne retrouve pas le Principal et Credential utile à l'authentification, d'où des valeurs null à a place et un rejet à l'authentification.
Ce qui explique pourqoi mon "hack" (voir premier post de ce topic) "résout" le problème: il force à l'utilisation de tel et tel Principal et Credential.
Mais j'ai trouvé - peut-être - une manière de faire les choses plus "proprement": je stock en cache dans le SecurityAssociation le subject avec le couple Princinpal/Credential et ensuite je les rechoppes et d'une requête à l'autre: rien n'est semble-t-il perdu. Pour info (le bean étant mis/récupéré dnas l'HttpSession):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SecurityAssociation.setContextInfo(app, lc.getSubject());

puis

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
Subject subject = (Subject)SecurityAssociation.getContextInfo(app);
 
                    System.err.println("Subject : "+subject.getPrivateCredentials().toString()+" "+subject.toString());
 
                    SecurityAssociation.setSubject(subject);
                    Iterator it = subject.getPrivateCredentials(PasswordCredential.class).iterator();
                    if(it.hasNext())
                    {
                        PasswordCredential pc = (PasswordCredential)it.next();
                        SecurityAssociation.setCredential(pc.getPassword());
                        SecurityAssociation.setPrincipal(new SimplePrincipal(pc.getUserName()));
                    } else {
                        logout(req, res);
                    }

**balibalo** · 21/11/2007, 15h12

Ô joie, ça fonctionne dirait-on!

Bon c'est crade mais moins que d'avoir les credentials coté client. Par contre faut encore que je test ça avec plusieurs sessions différentes, et aussi voir au nettoyage de la SessionAssociation

**balibalo** · 22/11/2007, 11h23

Petite rectification, finalement garder les infos dans la session http est la bonne soluce . Le seul cookie coté client et le jsession_id. Ça arrange finalement tout, sauf que là j'ai modifié le bouzin pour qu'il garde juste le subject (qui est lui même proprement "remplie" dans la méthode d'authentification.)
Au moins ça m'auras permis de comprendre pas mal de mécanisme sous-jacent.

**jlerbsc** · 16/12/2007, 18h35

Je pense que tu fais fausse route! Ca ne semble bien compliqué ton histoire!

Voici ce que je ferais à ta place dans l'environnement JBoss 4 si ton référentiel de sécurité est stocké dans un ldap.

Je te conseille de laisser JBoss gérer la sécurité.

Dans le fichier conf/login-config.xml, il faut créer une politique de sécurité applicative élément "authentification-policy"

Par exemple dans le cas ou 1 annuaire doit être consulté pour authentifier l'utilisateur. La configuration du module est dépendant de la structure de l'annuaire (cf http://wiki.jboss.org/wiki/Wiki.jsp?...dapLoginModule).
Bien entendu tous les paramètres utilisés dans la configuration du loginmodule sont spécifiques à ton environnement.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
    <!-- Security domain for MyDomain -->
    <application-policy name = "MyDomain">
 
        <authentication>
            <login-module code="org.jboss.security.auth.spi.LdapLoginModule" flag="sufficient" >
                <module-option name="java.naming.provider.url">ldap://<serveur>:389/</module-option>
                <module-option name="rolesCtxDN">CN=Users,DC=ldaphost,DC=jboss,DC=org</module-option>
                <module-option name="matchOnUserDN">false</module-option>
                <module-option name="principalDNPrefix">CN=</module-option>
                <module-option name="principalDNSuffix">,CN=Users,DC=ldaphost,DC=jboss,DC=org</module-option>
                <module-option name="uidAttributeID">sAMAccountName</module-option>
                <module-option name="roleAttributeID">memberOf</module-option>
                <module-option name="roleAttributeIsDN">true</module-option>
                <module-option name="roleNameAttributeID">name</module-option>
            </login-module>
        </authentication>
    </application-policy>

Configuration de l'application
--------------------------------
Pour faire le lien entre le serveur JBoss et l'application, cette dernière doit spécifier le nom de la politique de sécurité à appliquer. Dans l'exemple ci dessus il faut insérer dans l'application web à l'intérieur du fichier jboss-web.xml la déclaration suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
<jboss-web>
...
<security-domain>java:/jaas/MyDomain</security-domain>
</jboss-web>

Par défaut, la politique de sécurité est référencée dans le contexte local du serveur sous la racine java:/jaas

Dans le fichier web.xml, il faut ensuite décrire les contraintes de sécurité dans l'élément <security-constraint>. Voici un exemple de déclaration.
La encore tu dois spécifier tes propres contraintes dans les éléments security-constraint, login-config, security-role.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
<web-app>
...
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>security</web-resource-name>
            <description>Declarative security tests</description>
            <url-pattern>/*</url-pattern>
            <http-method>HEAD</http-method>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
            <http-method>PUT</http-method>
            <http-method>DELETE</http-method>
        </web-resource-collection>
        <!-- the role which can access these resources -->
        <auth-constraint>
             <!-- liste des rôles autorisés à accéder aux ressources décrites dans l'élement web-resource-collection -->
            <role-name>admin</role-name>
        </auth-constraint>
        <user-data-constraint>
            <description>no description</description>
            <transport-guarantee>NONE</transport-guarantee>
        </user-data-constraint>
    </security-constraint>
    <!-- the login page in case of Basic authentication -->
<!--
    <login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>Ceci est un exemple</realm-name>
    </login-config>
-->
    //the login page in case of form based authentication
    <login-config>
        <auth-method>FORM</auth-method>
        <form-login-config>
            <form-login-page>/logon.do</form-login-page> //path to login page
            <form-error-page>/logoff.do</form-error-page> //path in case login fails
        </form-login-config>
    </login-config>
<!-- déclaration des rôles utilisés par l'application -->
    <security-role>
        <description>A user role allowed to invoke methods</description>
        <role-name>admin</role-name>
    </security-role>
</web-app>

**shertoo** · 24/05/2012, 12h15

bonjour,
je souhaite intégrer LDAP a mon application web développée en respectant ejb3
serveur d'application glassfish .
je suis nouveau concernat LDAP je vous serait reconnaissant si vous pouviez me communiquer une documentation concernant ceci, les etapes a suivre pour mettre en place ce system etc.....
je vous remercie d'avance.
Cordialement,

[EJB3] [LDAP] Sécurisation des EJB3, quelque chose m'échappe. [JAAS]

Java EE

Discussions similaires

Partager

Partager