j_security_check

["Boudreau, Mike" <MB...@TRCSOLUTIONS.com>]

I have a requirement to implement security via LDAP and RDBMS.  
 
I was planning on using Form Based Authentication utilizing the
j_sucurity_check.
 
I see that you can use a JDBC Realm, but can I implement an LDAP realm or
some custom solution and take advantage of the web.xml security
declarations?
 
Does the JDBC realm use connection pooling?    
 
Is there a standard way to extend the j_security_check in a way that will
work in other Servlet Containers (e.g. WebSphere, WebLogic)?
 
Thanks,
Mike
 
 
 
 
 
 
 

Re: j_security_check

["Craig R. McClanahan" <cr...@apache.org>]

On Mon, 31 Dec 2001, Boudreau, Mike wrote:

> Date: Mon, 31 Dec 2001 10:34:14 -0500
> From: "Boudreau, Mike" <MB...@TRCSOLUTIONS.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: "'tomcat-user@jakarta.apache.org'" <to...@jakarta.apache.org>
> Subject: j_security_check
>
> I have a requirement to implement security via LDAP and RDBMS.
>
> I was planning on using Form Based Authentication utilizing the
> j_sucurity_check.
>
> I see that you can use a JDBC Realm, but can I implement an LDAP realm or
> some custom solution and take advantage of the web.xml security
> declarations?
>

Tomcat 4 has a JNDIRealm implementation that can talk to LDAP servers.

> Does the JDBC realm use connection pooling?
>

Not at the moment.  It's on my list of things to fix, now that we have
global JNDI resources (in the nightly builds).

> Is there a standard way to extend the j_security_check in a way that will
> work in other Servlet Containers (e.g. WebSphere, WebLogic)?
>

The declaration of security constraints and form-based login that you do
inside the web.xml file is portable across all servers.  What is *not*
portable is how each server looks up users and roles (i.e. the Realm
concept in Tomcat) -- you will have to consult the documentation for each
server individually to see how that is done.

> Thanks,
> Mike
>

Craig McClanahan


--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>