[JBoss][Jaas] Authentification client standalone

Version imprimable

16/05/2005, 10h09
mauvais_karma

[JBoss][Jaas] Authentification client standalone

salut
je suis sur JBoss4.0.2, configuration default

alors g un SLSB avec des méthodes dont l'acces est restreint à certains roles.
Les roles, users & pass sont stockés dans une bd, et la politique de sécurité utilise un module Jaas qui va chercher ces infos dans la base.

Cette méthode fonctionne déja avec une appli web (un web services) et les infos login/mdp sont passés par le stub dans l'entete soap.

Pour l'ejb, le deploiement se passe bien, mais je ne sais pas comment le client stand-alone (un test JUnit par ex.) doit fournir les infos d'authentification (principal)?

[edit]
en passant par le ws, ca marche maintenant, voir 3eme post
mon nouveau pb: 4eme post
[/edit]

Dans les 2 cas g cette erreur au niveau du client:

Citation:

RemoteException occurred in server thread; nested exception is:
java.rmi.AccessException: SecurityException; nested exception is:
javax.security.auth.login.FailedLoginException: No matching username found in Principals

et quand j'y accede via le ws, g cette erreur coté serveur:

Citation:

10:07:16,015 ERROR [ServerEngine] Server error: AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Client
faultSubcode:
faultString: SecurityException; nested exception is:
javax.security.auth.login.FailedLoginException: No matching username found in Principals
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace: java.rmi.AccessException: SecurityException; nested exception is:
javax.security.auth.login.FailedLoginException: No matching username found in Principals
at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:370)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:196)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624)
at org.jboss.ejb.Container.invoke(Container.java:870)
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:324)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:144)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.webservice.server.InvokerProviderEJB.invokeServiceEndpoint(InvokerProviderEJB.java:129)
at org.jboss.webservice.server.InvokerProvider.invokeMethod(InvokerProvider.java:350)
at org.jboss.axis.providers.java.RPCProvider.invokeTarget(RPCProvider.java:176)
at org.jboss.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:121)
at org.jboss.axis.providers.java.JavaProvider.invoke(JavaProvider.java:358)
at org.jboss.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:73)
at org.jboss.axis.SimpleChain.doVisiting(SimpleChain.java:160)
at org.jboss.axis.SimpleChain.invoke(SimpleChain.java:123)
at org.jboss.axis.handlers.soap.SOAPService.invoke(SOAPService.java:560)
at org.jboss.webservice.server.ServerEngine.invokeInternal(ServerEngine.java:198)
at org.jboss.webservice.server.ServerEngine.invoke(ServerEngine.java:87)
at org.jboss.axis.transport.http.AxisServlet.doPost(AxisServlet.java:905)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.jboss.axis.transport.http.AxisServletBase.service(AxisServletBase.java:370)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:75)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:147)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:53)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:743)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:536)
Caused by: javax.security.auth.login.FailedLoginException: No matching username found in Principals
at org.jboss.security.auth.spi.DatabaseServerLoginModule.getUsersPassword(DatabaseServerLoginModule.java:103)
at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:156)
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:324)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:675)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:129)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:610)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:607)
at javax.security.auth.login.LoginContext.login(LoginContext.java:534)
at org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:483)
at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:425)
at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:251)
at org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityInterceptor.java:180)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:129)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192)
... 46 more

10:07:16,015 INFO [AxisServlet] java.rmi.AccessException: SecurityException; nested exception is:
javax.security.auth.login.FailedLoginException: No matching username found in Principals

d'apres le code source que g trouvé sur
http://www.cenqua.com/clover/eg/jboss/report/org/jboss/security/auth/spi/DatabaseServerLoginModule.html

cette erreur est levée lorsqu'il ne trouve pas l'utilisateur dans la base. Pourtant ce dernier existe. Donc je pense que je m'y prends mal pour spécifier le login/mdp.

voila voila
16/05/2005, 10h48
mauvais_karma
dans le code client (pas le ws) g aussi mis ca:
Code:

1 2 3 4 props.put( Context.SECURITY_PRINCIPAL, "ludo2" ); props.put( Context.SECURITY_CREDENTIALS, "ludo2"); Context ctx = new InitialContext(props);
avec ludo2 cô login/mdp

mais g la meme erreur...

Par contre, g remarqué que si je supprime les infos de sécurité dans les fichiers de déploiements et que j'affiche les infos de login (via ctx.getCallerPrincipal() ) dans le bean, il m'identifie comme anonymous.
Donc le pb viendrait de la propagation de infos de sécurité?

Sinon, voila les descripteurs de deploiement:

Citation:

<ejb-jar >

<enterprise-beans>


<session >
<description><![CDATA[Description for Hello]]></description>
<display-name>Name for Hello</display-name>
<ejb-name>Hello</ejb-name>
<ejb-class>beans.HelloBean</ejb-class>

<home>beans.HelloHome</home>
<remote>beans.Hello</remote>
<local-home>beans.HelloLocalHome</local-home>
<local>beans.HelloLocal</local>
<service-endpoint>beans.HelloWSE</service-endpoint>

<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>

</session>
</enterprise-beans>

<assembly-descriptor >
<security-role>
<role-name>AuthorizedUser</role-name>
</security-role>


<method-permission>
<role-name>AuthorizedUser</role-name>
<method>
<ejb-name>Hello</ejb-name>
<method-name>*</method-name>
</method>
</method-permission>


<method-permission>
<unchecked/>
<method>
<ejb-name>Hello</ejb-name>
<method-name>sayHelloRemote</method-name>
</method>
</method-permission>

</assembly-descriptor>

</ejb-jar>

et le jboss.xml

Citation:

<jboss>


<security-domain>java:/jaas/ObjectWS-WSDL</security-domain>

<enterprise-beans>

<session>
<ejb-name>Hello</ejb-name>
<jndi-name>ejb/Hello</jndi-name>
<local-jndi-name>HelloLocal</local-jndi-name>

<method-attributes>
</method-attributes>
</session>

</enterprise-beans>
</jboss>

Je ne penses pas qu'il y ait d'erreur, mais on ne sait jamais...
De +, le ObjectWS-WSDL spécifié marche tres bien avec une autre application.

bon, g du nouveau!

alors dans le jboss.xml, g rajouté

Citation:

...
<port-component>
<port-component-name>HelloWSE</port-component-name>
<port-component-uri>/Hello/HelloWSE</port-component-uri>
<auth-method>BASIC</auth-method>
</port-component>
...

du coup, je peux maintenant acceder à l'EJB via l'interface WebService (en passant login/mdp dans le stub)

En revanche, ca ne passe toujours pas à partir d'un client qui utilise les interfaces remote ou locale.

Donc c'est bien un probleme de propagation des infos de login/mdp.

En furetant un peu, g cru comprendre qu'il ne faut pas utiliser ca:

Citation:

props.put( Context.SECURITY_PRINCIPAL, "ludo2" );
props.put( Context.SECURITY_CREDENTIALS, "ludo2");

...et entre temps, g cru comprendre qu'il faut utiliser un LoginContext pour se logger. Donc g mis ce bout de code:
Code:

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 //Pour se logger import java.util.Set; import javax.security.auth.Subject; import javax.security.auth.callback.CallbackHandler; import javax.security.auth.login.LoginContext; import javax.security.auth.login.LoginException; import org.jboss.security.SimplePrincipal; import org.jboss.security.auth.callback.SecurityAssociationHandler; ... try{ SecurityAssociationHandler handler = new SecurityAssociationHandler(); Principal user = new SimplePrincipal("ludo"); handler.setSecurityInfo(user, "ludo".toCharArray()); LoginContext loginContext = new LoginContext("ObjectWS-WSDL", (CallbackHandler)handler); loginContext.login(); Subject subject = loginContext.getSubject(); Set principals = subject.getPrincipals(); principals.add(user); } catch(LoginException e){ System.out.println("loginerror" + e.getMessage()); } Context ctx = new InitialContext(props); ...
et la ca me met cette erreur coté client, au niveau du "new LoginContext(...)":

Citation:

Impossible de trouver une configuration de connexion

si qq peut m'aider? G oublié qq chose?

18/05/2005, 09h11
mauvais_karma
Je crois que g compris d'où vient le probleme: en fait, l'application cliente s'exécute en dehors du contexte du serveur. Donc il ne voit pas ma politique de sécurité.
Alors que lorsque le client est un WS, la servlet qui expose le service s'execute dans le meme contexte que le serveur, donc elle voit bien la politique de sécurité, et ca passe: logique!

La preuve: g rajouté un fichier auth.conf coté client:

Citation:

ObjectWS-WSDL {
org.jboss.security.auth.spi.DatabaseServerLoginModule required
;
};

et dans le code je lui indique le fichier en faisant:
Code:

1 2 System.setProperty("java.security.auth.login.config", ClientTest.class.getResource("auth.conf").toString());
Du coup l'erreur devient:

Citation:

loginerrorclasse LoginModule introuvable : org.jboss.security.auth.spi.DatabaseServerLoginModule

C'est logique: mais est ce qu'il faut rajouter ce package coté client: je ne suis pas sur?

Donc ma question maintenant est: lorsque l'on a une application cliente qui n'est pas un EJB ou une servlet (cô le WS), par exemple un test JUnit, comment peut on s'authentifier pour acceder à l'EJB protégé?
18/05/2005, 10h36
mauvais_karma

Bon alors pour résumer:
coté client, il faut un fichier auth.conf, qui doit contenir ca:

Citation:

ObjectWS-WSDL {
org.jboss.security.ClientLoginModule required
password-stacking="useFirstPass"
;
};

où ObjectWS-WSDL est le nom du domaine de sécurité qui protege mes EJBs...
... et le ClientLoginModule est un module qui propage le contexte de sécurité du client vers le serveur JBoss. Il ne faut donc pas y mettre le module DatabaseServerLoginModule, car ca, c'est coté serveur...

Au final, je peux lancer l'authentification (loginContext.login(); ) et ca passe sans erreurs. Oui, mais meme si je met un mauvais login/pass, il ne déclenche pas non plus d'erreur! Par contre, dès que je fais le lookup, il me pose ca:

Citation:

RemoteException occurred in server thread; nested exception is:
java.rmi.AccessException: SecurityException; nested exception is:
javax.security.auth.login.FailedLoginException: No matching username found in Principals

donc le contexte de sécurté n'est pas propagé, et je me retrouve avec la meme erreur qu'au tout début!!!

bon si vous voyez ce que c'est...
18/05/2005, 11h42
mauvais_karma

bon ca marche, c cool!
pour ceux qui veulent comprendre:

Citation:

password-stacking:
Recommended value is 'useFirstPass'. If enabled then Subject and Credential information should have been set by a LoginModule higher in the stack.