Re: [PATCH] Catalina JNDIRealm - binding as the user
John Holman wrote: As said before I'd like to add the ability to search the directory for the user's dn to cover cases when a fixed pattern will not work, but will wait to see the fate of this patch before going ahead. Regarding the search, then bind authentication; what would be the suggested behaviour when there are more than one returned dn from the search? Should one try to authenticate as each of these, or automatically assume not authenticated? -- - Torgeir
Re: JNDI/LDAP realm
John Holman wrote: I preferred binding to the directory with supplied credentials because it allows the realm implementation to use an anonymous password for the rest of what it needs. +1 The only advantage I can see for having the realm retrieve the password is that it makes http digest authentication possible, provided that the plaintext password or a suitable hash is stored in the directory. I think that http digest authentication in theory is possible with authentication using an LDAP bind. The tricky details are in using the nonce realm from the LDAP server in the initial challenge, and not having the LDAP client code touch the digested answer from the client before sending it to the LDAP server. I would like to add a third feature, namely to be able to reuse the authentication information from the servlet container in a resource connector, eg. an LDAP connection pool so that a web application could ask for authenticated connections to the LDAP server without having to deal with username and passwords itself. Currently this is not possible with tomcat4.0beta. -- - Torgeir
Re: [PATCH] LDAPRealm implementation
Ellen Lockhart wrote: The jakarta website encourages people to get involved; I am a little disappointed to not receive at least a thanks but no thanks response. But I am glad that there is now a realm implementation that will work with LDAP for tomcat. This list is a little slow to respond to postings. Don't be put off by not receiving a response promptly. Your contribution is appreciated, even if there are allready something like this allready. -- - Torgeir
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Catalina.java ContextConfig.java EngineConfig.java HostConfig.java
[EMAIL PROTECTED] wrote:
craigmcc01/04/18 11:59:30
Modified:catalina/src/share/org/apache/catalina/startup Catalina.java
ContextConfig.java EngineConfig.java
HostConfig.java
Log:
Catalina: Restore the recognition of Logger, Realm, and Valve
elements nested inside a Context. They were only being recognized
inside a DefaultContext.
{Context,Engine,Host}Config: Inherit the debugging detail level of the
owning component to assist in debugging problems like this.
PR: Bugzilla #1370
Submitted by: Larry Karnowski [EMAIL PROTECTED]
Does this mean that one can now use a Context specific Realm, that lives
in the same classloader as the rest of the context?
--
- Torgeir
Re: [Tomcat 4] - JndiRealm Proposals
"Craig R. McClanahan" wrote: * Support for two major modes of operation: * SYSTEM LOGIN. Realm implementation binds itself to the server using a system-level username/password, then reads the username and password attributes to perform authentication (analogous to how JDBCRealm works). Would also support the optional digesting functionality that JDBCRealm supports. * USER LOGIN. Realm implementation attempts to bind to the server using the username and password specified by the user. If this is successful, the user is considered to be authenticated, and the associated roles are looked up. This is the way we do it, but it has the problem of not being able to be used with digest authentication, since the input to the digest method are different when done on the LDAP server, and when done by the http client. (Ok, maybe a genious of an SASL expert could do it, but it would require getting the nounce from the LDAP server, which would require some modification to some tomcat classes.) -- - Torgeir
Re: [Tomcat 4] - JndiRealm Proposals
Torgeir Veimo wrote: "Craig R. McClanahan" wrote: * Support for two major modes of operation: * SYSTEM LOGIN. Realm implementation binds itself to the server using a system-level username/password, then reads the username and password attributes to perform authentication (analogous to how JDBCRealm works). Would also support the optional digesting functionality that JDBCRealm supports. * USER LOGIN. Realm implementation attempts to bind to the server using the username and password specified by the user. If this is successful, the user is considered to be authenticated, and the associated roles are looked up. This is the way we do it, but it has the problem of not being able to be used with digest authentication, since the input to the digest method are different when done on the LDAP server, and when done by the http client. Well I was wrong, see http://www.ietf.org/rfc/rfc2831.txt. -- - Torgeir
Re: Using JNDI with Jakarta-Tomcat 4.0 beta 3
Julian Payne wrote:
Hi,
I have been using Jakarta-Tomcat 3.2.1 and when I upgraded to the 4.0 beta 3
I have a propblem with my JNDI configuration.
I have a servlet that uses an EJB container that requires the following
"jndi.properties" :
java.naming.factory.initial
com.sun.jndi.rmi.registry.RegistryContextFactory
java.naming.provider.url rmi://localhost:1099
java.naming.factory.url.pkgs org.objectweb.jonas.naming
With 3.2.1 I just needed to make sure that I had my jndi.properties file on
the classpath, with 4.0 beta 3 I do not seem to be able to get this read by
any means. The only mechanism that I found to get this to work is if I call
"System.setProperty()" in my servlet just before I call "new
javax.naming.InitialContext()". If I do not do this I get the following
error message:
javax.naming.NoInitialContextException: Cannot instantiate class:
org.apache.naming.java.javaURLContextFactory. Root exception is
java.lang.ClassCastException: org.apache.naming.java.javaURLContextFactory
Can anyone tell me how I am supposed to set this for my servlet? I tried the
following without any success:
1) Using env-entry in my WEB-INF/web.xml
2) Putting the jndi.properties into the classpath
3) Using Resource in the server.xml (except that I was not sure of the
correct parameters to use...)
This is what I use inside a Context element in server.xml;
Resource name="jndi/ContextPool" auth="SERVLET"
type="com.ecomda.ldap.ContextPool"/
ResourceParams name="jndi/ContextPool"
parameternamefactory/namevaluecom.ecomda.ldap.ContextPoolFactory/value/parameter
parameternameproviderURL/namevalueldap://trabant.intern.ecomda.de:389/value/parameter
parameternamesearchBase/namevalueou=People,o=ecomda.de/value/parameter
parameternameauthentication/namevaluesimple/value/parameter
parameternamemaxPoolSize/namevalue20/value/parameter
/ResourceParams
This is fairly similar to the connection pooling factories that tomcat
provides itself.
There is a classpath problem though. The ResourceFactory class doesn't
recognize the ResourceRef class unless you replace the (... instanceof
ResourceRef) with a ( ..getClass().getName().equals("...ResourceRef").
--
- Torgeir
Realms and webapp contexts (again..)
I'm still trying to use Realms on a per webapp context basis. This seems to be harder than I first imagined. Could someone from the tomcat developemt team please comment on whether this is possible or not at all? There are comments in the source that indicates that in theory this should be possible. But putting a Realm ... / anywhere else than inside the Engine/Engine part of server.xml is ignored. I have also tried using a single realm impl., but with context specific data lookup up using jndi. This doesn't work simply because the jndi context factory is created with a different class loader, and thus jndi.lookup() simply blocks the current thread running Realm.authenticate(). -- - Torgeir
LXR view of tomcat src?
Is there anyone that maintain an LXR (or cvsweb) view of the tomcat development source, or current beta3 source somewhere? -- - Torgeir
Re: context factories
"Craig R. McClanahan" wrote: If you don't mind specifying the resource factory class yourself, you don't need to modify any code at all -- just configure it in server.xml like this: Context path="/myapp" ... ... Resource name="jndi/ContextPool" type="com.mycompany.ContextPool"/ ResouceParams name="jndi/ContextPool" parameter namefactory/name valuecom.mycompany.ContextPoolFactory/value /parameter parameternamename/namevaluevalue/value/parameter ... /ResourceParams ... /Context where "com.mycompany.ContextPoolFactory" is a class that implements javax.naming.spi.ObjectFactory. You can use the existing factories as examples of how such factories can access the declared resource parameters and use them to configure the object itself. Ok, I've configured this, and all I get back from the initCtx.lookup() method is a ResourceRef, not a ContextPool. I have found the reason for this to be that the "instanceof" check in the getObjectInstance() method in org.apache.naming.factory.ResourceFactory fails, and this must be due to classloader issues. What are the magic spells I need to cast to get classloading right? Can I put the ContextPoolFactory in an independent jar file in lib, common/lib or server/lib? -- - Torgeir
Re: context factories
Btw, if I replace the instanceof test with a
getClass().getName().equals("org.apache.naming.ResourceRef")
it all works.
--
- Torgeir
context factories
I've read in a post by Remy with subject: "Re: ejb-ref ejb-link
Implementation in 4.0.b1",
http://w4.metronet.com/~wjm/tomcat/2001/Mar/msg00273.html that the only
two factories supported in tomcat right now is one for getting Tyrex
managed data sources User Transactions.
I'm interested in getting a resource factory that I've created myself to
reuse jndi context's to an LDAP database that is used for authentication
more.
I've created a ContextPool that handles this, and I want to retrieve
this with initCtx.lookup("java:comp/env/jndi/ContextPool");
How do I create and add the necessary resource factory? Should I modify
org.apache.naming.factroy.ResourceFactory.java ?
Any hints appreciated.
--
- Torgeir
debugging tomcat's jndi provider
I need to look at the behaviour of the jndi provider inside tomcat. Are there any tricks to debugging tomcat? -- - Torgeir
