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" <david_jencks@yahoo.com>
To: <user@geronimo.apache.org>
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 <bdellert@rcn.com> 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
>>>
|