Re: Custom LoginModule classloading issue in gernimo 2.0.2

Tue, 18 Dec 2007 14:08:25 -0800 

Thanks for the prompt response.
Could you elaborate a bit on how to "Deploy this plan into your geronimo server", or point me to some documentation which describes how to package and deploy a "config module"? I'm relatively new to geronimo, and haven't deployed artifacts other than ear files, war files, etc. Thanks. 

- Brian


----- Original Message ----- 
From: "David Jencks" <[EMAIL PROTECTED]>

To: <[email protected]>
Sent: Tuesday, December 18, 2007 4:38 PM
Subject: Re: Custom LoginModule classloading issue in gernimo 2.0.2



My guess is that Aaron is right and this is an openejb bug.


The only way I can think to fix it is to replace the server-security- 
config module with one that is identical except also including the  jar 
containing your login module as a dependency and the security  realm 
configuration you want.  Deploy this plan into your geronimo  server. 
Also, while geronimo is stopped, add a line like



org.apache.geronimo.configs/server-security-config/2.0.2/car=com.myco/ 
myserver-security-config/1.0/car



and another similar line without the 2.0.2 to var/config/ 
artifact_aliases.properties (where com.myco/myserver-security-config/ 
1.0/car is the moduleId of your replacement plan).  When you restart 
geronimo the realm should work.



I actually recommend doing this for any non-toy geronimo  installation. 
The provided server-security-config is really an  example that's easy to 
set up, but on a real installation you  probably want access to the admin 
console controlled by your  enterprise security system, not a couple of 
property files stuck in a  geronimo directory.


let us know how this works
david jencks

On Dec 18, 2007, at 12:46 PM, Aaron Mulder wrote:


It's curious that, from the error, it appears to be looking for the
security realm in the OpenEJB class loader (which I guess is receiving
the remote call) instead of the application's class loader.  Perhaps
the context class loader should be set by e.g.
EjbDaemon.processAuthRequest?

Thanks,
       Aaron

On Dec 18, 2007 2:55 PM, Brian Dellert <[EMAIL PROTECTED]> wrote:

Hi.


I have created a simple custom login module which uses the  principal 
created
by the standard PropertiesFileLoginModule and adds a principal 
containing a
group (which is looked up in a DB).  I have configured a security  realm 
in
the geronimo-application.xml contained in my application ear file 
including

both of these login modules as follows:

    <gbean name="my-realm"
class="org.apache.geronimo.security.realm.GenericSecurityRealm"
           xsi:type="dep:gbeanType"
xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2";
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
        <attribute name="realmName">my-realm</attribute>
        <reference name="ServerInfo">
            <name>ServerInfo</name>
        </reference>
        <xml-reference name="LoginModuleConfiguration">
            <log:login-config
xmlns:log="http://geronimo.apache.org/xml/ns/loginconfig-2.0";>
                <log:login-module control-flag="REQUISITE"
wrap-principals="false">

                    <log:login-domain-name>my-properties-file</ 
log:login-domain-name>
                    <log:login-module- 
class>org.apache.geronimo.security.realm.providers.PropertiesFileLogi 
nModule</log:login-module-class>

                    <log:option
name="usersURI">var/security/users.properties</log:option>
                    <log:option
name="groupsURI">var/security/groups.properties</log:option>
                </log:login-module>
                <log:login-module control-flag="OPTIONAL"
wrap-principals="false">

                    <log:login-domain-name>my-sql-role</log:login- 
domain-name>
                    <log:login-module- 
class>my.company.security.realm.providers.SqlRoleLoginModule</ 
log:login-module-class>

                    <log:option name="roleSelect">SELECT username,
group_name FROM user_groups WHERE username=?</log:option>
                    <log:option
name="dataSourceApplication">null</log:option>

                    <log:option name="dataSourceName">MyPool</ 
log:option>

                </log:login-module>
            </log:login-config>
        </xml-reference>
    </gbean>

Further, I have packaged the

"my.company.security.realm.providers.SqlRoleLoginModule" class in  a jar 
file
(my-login-module-1.0.jar).  I have tried the following approaches  to 
get

this login module to load:

   - Added my-login-module-1.0.jar to the root of my ear file.


   - Added my-login-module-1.0.jar to the root of my ear file and  added 
this
jar file to the MANIFEST classpath of an ejb-jar file which is  also in 
the

ear file.


   - Added my-login-module-1.0.jar to the geronimo repository by 
placing it
in the repository/my/company/my-login-module/1.0/my-login- 
module-1.0.jar

     and added the following dependency to the dependency list in the
environment section of my geronimo-application.xml file:

           <dependency>
                <groupId>my.company</groupId>
                <artifactId>my-login-module</artifactId>
                <version>1.0</version>
                <type>jar</type>
            </dependency>


I am attempting to connect/authenicate in a remote JVM by setting  up 
the

JNDI context and performing an EJB lookup as follows:

  Properties p = new Properties();
  p.put(Context.INITIAL_CONTEXT_FACTORY,
  "org.openejb.client.RemoteInitialContextFactory");
  p.put(Context.PROVIDER_URL, "ejbd://localhost:4201");
  p.put("openejb.authentication.realmName", "my-realm");
  p.put(Context.SECURITY_PRINCIPAL, "my_username");
  p.put(Context.SECURITY_CREDENTIALS, "my_password");
  InitialContext ctx = new InitialContext(p);
  Object obj = ctx.lookup("MyBusinessBeanRemote");

In all cases, I get the following error:

Caused by: javax.security.auth.login.LoginException: unable to find

LoginModule class: 
my.company.security.realm.providers.SqlRoleLoginModule in

classloader org.apache.geronimo.configs/openejb/2.0.2/car
[INFO]  at
javax.security.auth.login.LoginContext.invoke(LoginContext.java:808)
[INFO]  at

javax.security.auth.login.LoginContext.access$000 
(LoginContext.java:186)

[INFO]  at
javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
[INFO]  at java.security.AccessController.doPrivileged(Native Method)
[INFO]  at

javax.security.auth.login.LoginContext.invokePriv 
(LoginContext.java:680)

[INFO]  at
javax.security.auth.login.LoginContext.login(LoginContext.java:579)
[INFO]  at

org.apache.geronimo.security.ContextManager.login 
(ContextManager.java:77)

[INFO]  at

org.apache.geronimo.openejb.GeronimoSecurityService.login 
(GeronimoSecurityService.java:52)

[INFO]  at

org.apache.openejb.server.ejbd.AuthRequestHandler.processRequest 
(AuthRequestHandler.java:56)

[INFO]  at

org.apache.openejb.server.ejbd.EjbDaemon.processAuthRequest 
(EjbDaemon.java:172)

[INFO]  at
org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:130)
[INFO]  at
org.apache.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:84)
[INFO]  at
org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:60)
[INFO]  at
org.apache.openejb.server.ServiceLogger.service(ServiceLogger.java: 73)
[INFO]  at

org.apache.openejb.server.ServiceAccessController.service 
(ServiceAccessController.java:55)

[INFO]  at
org.apache.openejb.server.ServiceDaemon$1.run(ServiceDaemon.java:117)
[INFO]  at java.lang.Thread.run(Thread.java:619)


I know that the dependency is getting at least recognized at ear 
deployment

time since, if I remove the login module jar file from the geronimo
repository, the deployment of the ear fails.


The only way I have been able to get the class to load is by  placing it 
in
the lib/ext directory of my JRE installation, which doesn't seem  like 
the
correct approach.  I am using geronimo 2.0.2 on Windows XP and the 
1.6.0_03

Sun JVM.  Any help with resolving this issue, and getting geronimo to

correctly load this login module class, would be greatly  appreciated. 
If

any additional information is needed, please let me know.  Thanks.

- Brian























					Reply via email to