It doesn't look like this approach will work. JAAS=Java Authentication and
Authorization Service, a Sun Java extension
(http://java.sun.com/products/jaas).
For authentication, you construct a module for handling authentication services
for your application, and it has to implement
javax.security.auth.spi.LoginModule from jaas.jar. In my case, this was the
class that wasn't found in the original exception trace that I posted.
In addition, you have to add entries for 'providers' to the java.security file,
like so:
login.configuration.provider=com.ibm.security.auth.login.ConfigFile
login.config.url.1=file:/opt/Projects/Scheduler/webapp/WEB-INF/lib/scheduler.conf
auth.policy.provider=com.ibm.security.auth.PolicyFile
auth.policy.url.1=file:/opt/Projects/Scheduler/webapp/WEB-INF/lib/scheduler.policy
In this case, IBM has supplied the JAAS implementation for Linux (Sun only has
Windows and Solaris implementations available). The problem is that neither of
the classes mentioned implement java.security.Provider, so they can't be added
via Security.addProvider().
You then construct the configuration and policy files referenced. In the
configuration file indicated above, I've got the following entry:
Scheduler {
org.sofbex.security.login.SchedulerModule Required repository=schedule;
};
The format is:
[Application] {
[Login Module] [Constraint] [Options];
...
};
In my case, I'm only using one type of login module for authentication
purposes, SchedulerModule.
Although these classes provide the mechanism for getting at the security
configuration and policy, the class that manages access to the JAAS portion of
the security framework is javax.security.auth.login.LoginContext. You create a
new instance of this class, using your application's name as entered in the
.conf file indicated above ('Scheduler', in my case). When I attempt to
instantiate the LoginContext object, I get the exception that I referenced in
my original message.
Are there alternate mechanisms for loading providers?
- Roby
David Wall wrote:
> > I'm trying to work out a variation of what appears to be a problem
> > previously encountered via JNDI/JMS and Tomcat. My specific
> > configuration has a little bit of a different slant, though. I'm
> > attempting to follow this route:
> >
> > JSP->JAAS->EJB->database
>
> I figured out a work-around for JNDI/JMS. Actually, in my case it was just
> for JNDI, though I was only using JNDI to use JMS! I have not used JAAS
> before. Is it an extension? How is the extension loaded? You'll want to
> make sure that the extension is loaded your code, and not by anything that
> would be found in the standard CLASSPATH (as used by Tomcat), and it cannot
> be done by including configuration information in a properties file or the
> like.
>
> For example, to use JCE, I had used the method of installing the provider by
> putting an entry in the jre/lib/security/java.security file, and this had
> the unfortunate side effect of causing those classes to be loaded by the
> system class loaders rather than the JSP classloader that's going to look in
> WEB-INF/lib for you. By loading the provider in my code instead
> (Security.addProvider()) I was able to solve it. Hope this helps...
>
> David
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
