On Jun 10, 2006, at 10:01 PM, Sunny Saxena wrote:

What if I don't want to use geronimo's security realms. My application
internally challenges the user for authentication and for that it uses
JAAS. Now jaas uses its config file to pick up login module
definitions... I need to specify the location of the config file. On
other app servers like weblogic, I used to add the system property
-Djava.security.auth.login.config=etc\example.conf in the server startup
file, in the java execution path.

But in geronimo, doing that is not working.

correct.  We don't use that style of jaas configuration.
I hope I got my point through. :)

Thanks
PS: the application is already built. We don't want to make major
changes in its working structure.

You should be able to do this without changing your packaged j2ee application at all. You will need a geronimo deployment plan. What you need to do is write gbean configurations that set up the equivalent login module configuration to your example.conf and include these in your geronimo plan. When you deploy the app with this plan, the login modules will be properly configured. Aaron provided some gbean configuration example below although he used a different realm name than you, something closer to your example would be

   <gbean name="ExampleRealm"
class="org.apache.geronimo.security.realm.GenericSecurityRealm">
       <attribute name="realmName">example</attribute>
       <reference name="ServerInfo">
           <name>ServerInfo</name>
       </reference>
       <reference name="LoginService">
           <name>JaasLoginService</name>
       </reference>
       <xml-reference name="LoginModuleConfiguration">
           <login-config
xmlns="http://geronimo.apache.org/xml/ns/loginconfig-1.1";>
               <login-module control-flag="REQUIRED"
server-side="true" wrap-principals="false">
                   <login-domain-name>example</login-domain-name>
<login-module-class>com.test.DBLoginModule</login- module-class>
               </login-module>
           </login-config>
       </xml-reference>
   </gbean>


This would go as the last element in your geronimo plan. Since I don't know what kind of app you are deploying (ejb, web, ear, app- client) I'm not going to guess at what the rest of the plan might look like.

thanks
david jencks




-----Original Message-----
From: Alan D. Cabrera [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 10, 2006 9:36 PM
To: [email protected]
Subject: Re: Location of JAAS config file

I would change that statement to:

In Geronimo, we don't have use a JAAS conf file.  You could instead
declare and deploy security realms using a Geronimo deployment plan,
like many other components.


Regards,
Alan


Aaron Mulder wrote:
In Geronimo, we don't use a JAAS conf file, but instead let you
declare and deploy security realms using a Geronimo deployment plan,
like many other components. There is some special syntax for security

realms, though.

Basically, to create a realm called DatabaseRealm using the JAAS login

module DBLoginModule and the flag required, you could use a plan like
the one below.  Either you can deploy this plan with a JAR containing
the DBLoginModule class, or you could put the login module class in a
JAR in the Geronimo repository and then add a dependency on that JAR
to the environment element in the plan and deploy the plan on its own.

Another option is to add your security realm (the "gbean" element in
the plan below) directly to the Geronimo plan for a WAR or EAR or
something, and add the login module classes to that component (in
WEB-INF/lib or in an EJB JAR, etc.).  That way the realm would always
be deployed and undeployed with that module.

Thanks,
   Aaron

<module xmlns="http://geronimo.apache.org/xml/ns/deployment-1.1";>
   <environment>
       <moduleId>
           <artifactId>DatabaseRealm</artifactId>
       </moduleId>
       <dependencies>
           <dependency>
               <groupId>geronimo</groupId>
               <artifactId>j2ee-security</artifactId>
               <type>car</type>
           </dependency>
       </dependencies>
   </environment>
   <gbean name="DatabaseRealm"
class="org.apache.geronimo.security.realm.GenericSecurityRealm">
       <attribute name="realmName">DatabaseRealm</attribute>
       <reference name="ServerInfo">
           <name>ServerInfo</name>
       </reference>
       <reference name="LoginService">
           <name>JaasLoginService</name>
       </reference>
       <xml-reference name="LoginModuleConfiguration">
           <login-config
xmlns="http://geronimo.apache.org/xml/ns/loginconfig-1.1";>
               <login-module control-flag="REQUIRED"
server-side="true" wrap-principals="false">

<login-domain-name>DatabaseRealm</login-domain-name>

<login-module-class>com.test.DBLoginModule</login-module-class>
                   <option name="...">..</option>
                   <option name="...">...</option>
               </login-module>
           </login-config>
       </xml-reference>
   </gbean>
</module>

On 6/10/06, Sunny Saxena <[EMAIL PROTECTED]> wrote:


My application deployed under gerenimo, uses JAAS for authentication.

The
login modules are picked up from a config file, example.conf.
Generally in other app servers, I just add the system property,

-Djava.security.auth.login.config=etc\example.conf

in the java execution path, and it works. But in gerenimo, it is
unable to locate any login modules.

The Error:
javax.security.auth.login.LoginException: No LoginModules configured
for example

File:
example.conf:::

example {
com.test.DBLoginModule required;
}

Thanks
**************** CAUTION - Disclaimer *****************  This e-mail
contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for
the use of the addressee(s). If you are not the intended recipient,
please notify the sender by e-mail and delete the original message.
Further, you are not to copy, disclose, or distribute this e-mail or
its contents to any other person and any such actions are unlawful.
This e-mail may contain viruses. Infosys has taken every reasonable
precaution to minimize this risk, but is not liable for any damage
you may sustain as a result of any virus in this e-mail. You should
carry out your own virus checks before opening the e-mail or
attachment. Infosys reserves the right to monitor and review the
content of all messages sent to or from this e-mail address. Messages

sent to or from this e-mail address may be stored on the Infosys
e-mail system.
 ***INFOSYS******** End of Disclaimer ********INFOSYS***



Reply via email to