RE: LDAPRealm JNDIReam for Tomcat 3.2 and 4.0 beta 1 is available
Title: LDAPRealm & JNDIReam for Tomcat 3.2 and 4.0 beta 1 is available Hey Alex : I've got a question about your JNDIRealm stuff... I'm using your SimpleRoleMapper to get started, but I can't get it to work. I can't find in your code where a distinguished name (dn) is linked to roles. In your translateroles function, I can see how users are assigned roles assigned to everybody (*), but I can't find anything like (String[])userRoles.get(distinghushedname) as I might expect. All my users are reporting only a role of [guest] even though I've carefully matched the dn in the rolemapper file to the dn stored by jndirealm. The translateroles code seems to be looking for rolenames as keys in the userroles Map : String items[] = (String[])userRoles.get(ur); Shouldn't this be something like : (String[])userRoles.get(distinghushedname) Please let me know if I'm looking at this wrong or not. Thanks... ..Casey == Casey Bragg - Software Engineer Allegiance Telecom, Inc. Dallas, TX 469-259-2702 - [EMAIL PROTECTED] == -Original Message-From: Roytman, Alex [mailto:[EMAIL PROTECTED]]Sent: Monday, June 04, 2001 5:03 PMTo: '[EMAIL PROTECTED]'Subject: LDAPRealm JNDIReam for Tomcat 3.2 and 4.0 beta 1 is available http://www.peacetech.com/java/files/apache/tomcat/default.htm JndiRealm authenticates and authorizes users against JNDI. It was tested against LDAP JNDI with Sun's and Netscape's jndi providers LdapRealm authenticates and authorizes users directly against LDAP using Netscape LDAP JDK. These two realms are interchangeable you can switch between them without many configuration changes. According to my tests it performs 10 faster under 20 concurrent threads than JNDI with Sun's LDAP provider. This is not final result because I need to test and tune-up multithreaded access and synchronization there might be some misunderstanding on my part. I also noticed some cases of JNDI loosing connection to the server under heavy multithreaded load while Netscape's LDAP handled it nicely. Because I use LdapRealm for Tomcat 3.2 for my production system it is tested better than JndiRealm. There are four classes in the package : JndiRealm and LdapRealm are for Tomcat 3.2x JndiRealmCatalina and LdapRealmCatalina for Tomcat 4.0 className="com.peacetech.webtools.tomcat.JndiRealm" JNDI TOMCAT 3.2x className="com.peacetech.webtools.tomcat.JndiRealmCatalina" JNDI TOMCAT 4.0 className="com.peacetech.webtools.tomcat.LdapRealmCatalina" LDAP TOMCAT 4.0 className="com.peacetech.webtools.tomcat.LdapRealm" LDAP TOMCAT 3.2x Jndi/LdapRealm uses searchBindDN and searchBindCredentials to connect to a directory. Then it looks for exactly one user name matching searchFilter in searchBaseContext scoped by searchScopeAsString (values are "base", "one", "sub" according to LDAP URL rules) If one and only one matching directory object is found it will use this object and tomcat supplied credentials to authenticate the user. If successful Realm will fetch user roles using JNDI attributes listed in securityAttributes (comma separated directory attribute names). If attributesReadByOwner = "true" Realm will use authenticated user itself to pool the attributes from directory otherwise it will use searchBindDN to retrieve the attributes. If roleMapperClass is specified Realm will use it to map user roles onto application roles specific for each web context for tomcat 3.2x and specific for each defined Realm for tomcat 4.2. Provided SimpleRoleMapper implementation will read role map from either roleMapperSourceUrl (if specified) or for tomcat 3.2x from WEB-INF/role-map.xml file in each web context if no roleMapperSourceUrl was defined (if WEB-INF/role-map.xml file does not exist in a context no mapping for this context will occur). You can use principalAttributes parameter to specify LDAP attributes to be stored in principal so you can access them from your servlets PARAMETERS: jndiInitialContextFactory = "com.sun.jndi.ldap.LdapCtxFactory" (or "com.netscape.jndi.ldap.LdapContextFactory") This attribute for JndiRealm ONLY. It corresponds to javax.naming.Context.INITIAL_CONTEXT_FACTORY directoryUrl = "ldap://207.176.93.66:389" This attribute for both JndiRealm and LdapRealm. If you want to use SSL for LdapRealm you can use "ldaps" protocol: directoryUrl = "ldaps://207.176.93.66:636" You will need to configure Sun's JSSE to use SSL It corresponds to javax.naming.Context.PROVIDER_URL jndiSecurityAuthentication = "simple" This attribute for JndiRealm ONLY. It
RE: LDAPRealm JNDIReam for Tomcat 3.2 and 4.0 beta 1 is available
What about a port of LDAPRealm JNDIReam to TC 3.3 ? Thanks http://www.peacetech.com/java/files/apache/tomcat/default.htm
RE: LDAPRealm JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le
Title: RE: LDAPRealm JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le Hello Henri, Has Interceptor architecture changed in TC3.3? If not 3.2 version should work just fine. In general I do not mind doing it however I did not see much interest from apache developers and little from users so I am not making any effort to make it truly open source - comments, documentation, etc. If somebody from tomcat developers community could review it would express some interest I will be glad to spend couple of days to its quality. Alex -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 05, 2001 6:52 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: LDAPRealm JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le What about a port of LDAPRealm JNDIReam to TC 3.3 ? Thanks http://www.peacetech.com/java/files/apache/tomcat/default.htm
RE: LDAPRealm JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le
Title: RE: LDAPRealm JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le Henry, What about creating a sub project jakarta-tomcat-realms? Sure why not. Although I think TC4.0 has or will have some JNDI authentication I do not know how tomcat project works internally. I rely on tomcat developers (committers) for guidance. I love tomcat product and developed various extensions for it (context aware JNDI Environment for TC3.2 to make it somewhat J2EE compatible, Authentication, etc.) but I have no idea whether they are wanted (I know I can't develop without them) or not. I rely on you guys to provide guidance. If I got no response I assume it is not needed. Alex -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 05, 2001 12:12 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: LDAPRealm JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le That was asked many time before but . What about creating a sub project jakarta-tomcat-realms - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED] (. .) PGP KEY : 697ECEDD ...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Roytman, Alex [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 05, 2001 5:37 PM To: 'GOMEZ Henri'; [EMAIL PROTECTED] Subject: RE: LDAPRealm JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le Hello Henri, Has Interceptor architecture changed in TC3.3? If not 3.2 version should work just fine. In general I do not mind doing it however I did not see much interest from apache developers and little from users so I am not making any effort to make it truly open source - comments, documentation, etc. If somebody from tomcat developers community could review it would express some interest I will be glad to spend couple of days to its quality. Alex -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 05, 2001 6:52 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: LDAPRealm JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le What about a port of LDAPRealm JNDIReam to TC 3.3 ? Thanks http://www.peacetech.com/java/files/apache/tomcat/default.htm
RE: LDAPRealm JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le
That was asked many time before but . What about creating a sub project jakarta-tomcat-realms - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Roytman, Alex [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 05, 2001 5:37 PM To: 'GOMEZ Henri'; [EMAIL PROTECTED] Subject: RE: LDAPRealm JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le Hello Henri, Has Interceptor architecture changed in TC3.3? If not 3.2 version should work just fine. In general I do not mind doing it however I did not see much interest from apache developers and little from users so I am not making any effort to make it truly open source - comments, documentation, etc. If somebody from tomcat developers community could review it would express some interest I will be glad to spend couple of days to its quality. Alex -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 05, 2001 6:52 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: LDAPRealm JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le What about a port of LDAPRealm JNDIReam to TC 3.3 ? Thanks http://www.peacetech.com/java/files/apache/tomcat/default.htm
LDAPRealm JNDIReam for Tomcat 3.2 and 4.0 beta 1 is available
Title: LDAPRealm JNDIReam for Tomcat 3.2 and 4.0 beta 1 is available
http://www.peacetech.com/java/files/apache/tomcat/default.htm
JndiRealm authenticates and authorizes users against JNDI. It was tested against LDAP JNDI
with Sun's and Netscape's jndi providers
LdapRealm authenticates and authorizes users directly against LDAP using Netscape LDAP JDK.
These two realms are interchangeable you can switch between them without many configuration changes.
According to my tests it performs 10 faster under 20 concurrent threads than JNDI with
Sun's LDAP provider. This is not final result because I need to test and tune-up multithreaded
access and synchronization there might be some misunderstanding on my part.
I also noticed some cases of JNDI loosing connection to the server under heavy multithreaded
load while Netscape's LDAP handled it nicely. Because I use LdapRealm for Tomcat 3.2 for my
production system it is tested better than JndiRealm.
There are four classes in the package :
JndiRealm and LdapRealm are for Tomcat 3.2x
JndiRealmCatalina and LdapRealmCatalina for Tomcat 4.0
className=com.peacetech.webtools.tomcat.JndiRealm JNDI TOMCAT 3.2x
className=com.peacetech.webtools.tomcat.JndiRealmCatalina JNDI TOMCAT 4.0
className=com.peacetech.webtools.tomcat.LdapRealmCatalina LDAP TOMCAT 4.0
className=com.peacetech.webtools.tomcat.LdapRealm LDAP TOMCAT 3.2x
Jndi/LdapRealm uses searchBindDN and searchBindCredentials to connect to a directory.
Then it looks for exactly one user name matching searchFilter in searchBaseContext
scoped by searchScopeAsString (values are base, one, sub according to LDAP URL rules)
If one and only one matching directory object is found it will use this object and
tomcat supplied credentials to authenticate the user.
If successful Realm will fetch user roles using JNDI attributes listed in securityAttributes
(comma separated directory attribute names). If attributesReadByOwner = true Realm will use
authenticated user itself to pool the attributes from directory otherwise it will use searchBindDN
to retrieve the attributes.
If roleMapperClass is specified Realm will use it to map user roles onto application roles
specific for each web context for tomcat 3.2x and specific for each defined Realm for tomcat 4.2.
Provided SimpleRoleMapper implementation will read role map from either roleMapperSourceUrl
(if specified) or for tomcat 3.2x from WEB-INF/role-map.xml file in each web context
if no roleMapperSourceUrl was defined (if WEB-INF/role-map.xml file does not exist in a context
no mapping for this context will occur).
You can use principalAttributes parameter to specify LDAP attributes to be stored in principal
so you can access them from your servlets
PARAMETERS:
jndiInitialContextFactory = com.sun.jndi.ldap.LdapCtxFactory
(or com.netscape.jndi.ldap.LdapContextFactory)
This attribute for JndiRealm ONLY.
It corresponds to javax.naming.Context.INITIAL_CONTEXT_FACTORY
directoryUrl = ldap://207.176.93.66:389
This attribute for both JndiRealm and LdapRealm.
If you want to use SSL for LdapRealm you can use ldaps protocol: directoryUrl = ldaps://207.176.93.66:636
You will need to configure Sun's JSSE to use SSL
It corresponds to javax.naming.Context.PROVIDER_URL
jndiSecurityAuthentication = simple
This attribute for JndiRealm ONLY.
It corresponds to javax.naming.Context.SECURITY_AUTHENTICATION
jndiSecurityProtocol = ( vendor default or ssl, or vendor specific)
This attribute for JndiRealm ONLY.
It corresponds to javax.naming.Context.SECURITY_PROTOCOL
searchBindDN = cn=ldap-user,o=pti
This attribute for both JndiRealm and LdapRealm. User name to bind to directory
a to perform user name lookups. It corresponds to javax.naming.Context.SECURITY_PRINCIPAL
searchBindCredentials = mypassword
This attribute for both JndiRealm and LdapRealm. Password for searchBindDN
It corresponds to javax.naming.Context.SECURITY_CREDENTIALS
searchBaseContext = o=pti
Base context for user lookups
ldapVersion = 3
This attribute for LdapRealm ONLY. Defines LDAP version.
searchScopeAsString = base | one | sub
defines search scope base - object scope, one - one level scope, sub - subtree scope.
attributesReadByOwner = true
defines who will read securityAttribures from the directory. If true authenticating user account
will be used to retrieve the roles otherwise the searchBindDN account used for user name lookups will
fetch the attributes. It is useful when either one or the other do not have permission to read the
attributes so you can chose the one which has this permissions
searchFilter = cn={0}
Filter to lookup authorizing user. Support java.text.MessageFormat.
The only parameter is to java.text.MessageFormat pattern authorizing username.
i.e. jndiSearchFilter = cn={0} for user alex will result in lookup for cn=alex
securityAttributes = securityEquals
One or more directory attributes separated with semicolon
Re: LdapRealm
On Wed, 28 Mar 2001, Torgeir Veimo wrote:
GOMEZ Henri wrote:
I may try to do something to TC 3.3 if nobody volunteer
I allready have some initial code. I don't handle digest authentication,
and don't search for group membership to determine roles yet, but it's a
start. I'm working with 4.0beta.
I would be very happy for feedback on this code.
--
- Torgeir
Hello Torgeir!
It looks like you've made a great start on this. I'd like to work with
you to get this kind of functionality included in Tomcat 4.0. I've got
several comments and suggestions for you to consider:
* I'd like to see an LdapRealm implementation be as flexible about the
underlying organization of the directory server's data as JDBCRealm
is about the columns and tables it uses. You've made a start by
allowing the search base to be configurable, but there are several
things that are hard coded (such as the use of "uid" for the username.
This is common but not universal - it would be nice to be able to
configure the name of the attribute to use.
* Maybe we can specify a general search expression using the {0}
replacement for where the literal username value goes? Then we could
use the java.text.MessageFormat class to do the substitution.
* To handle group lookups (i.e. roles in the servlet spec's vocabulary)
we could do something similar. The variables would be the user for
which we are checking, and the name of the attribute we want returned
(multiple values supported if the user is in multiple groups).
* I would suggest that LdapRealm *not* try to cache retrieved
Principal objects itself. The reason for this is that Catalina already
caches the retrieved principal if sessions are in use (which is the
usual case for apps that require authentication), so doing it here
is redundant.
* In JDBCRealm, the Principal object being created contains the username
and all of the roles that user has, so that the hasRole() method does
not have to go back to the database again. We can use the same
approach here (and should probably factor out the common code so that
it can be shared -- I will work on that).
* For digest mode authentication of the password, we can again borrow
(actually, refactor and reuse) code from JDBCRealm as well.
* An alternative approach to LDAP authentication that I've seen used in
other servers (such as the old Netscape Enterprise Server) is to attempt
to bind to the directory server with the *user's* name and credentials,
instead of a sysadmin-specified identity. Successful binding is proof
that the user is who they say they are. Do you think it would be worth
supporting this mode of operation as well?
What do you think?
Craig McClanahan
PS: Further discussions of this should probably happen on the TOMCAT-DEV
mailing list, since we're talking about building Tomcat features. I
suggest that you subscribe to this list if you haven't yet.
LdapRealm
Is there any impl of this somewhere allready? -- - Torgeir
RE: LdapRealm
I may try to do something to TC 3.3 if nobody volunteer "Entre truands, les bnfices, a se partage, la rclusion, a s'additionne." -- Michel Audiard -Original Message- From: Torgeir Veimo [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 28, 2001 12:39 PM To: [EMAIL PROTECTED] Subject: LdapRealm Is there any impl of this somewhere allready? -- - Torgeir
Re: LdapRealm
GOMEZ Henri wrote:
I may try to do something to TC 3.3 if nobody volunteer
I allready have some initial code. I don't handle digest authentication,
and don't search for group membership to determine roles yet, but it's a
start. I'm working with 4.0beta.
I would be very happy for feedback on this code.
--
- Torgeir
package com.ecomda.ldap;
import java.beans.*;
import java.security.Principal;
import java.io.*;
import java.util.*;
import org.apache.catalina.Container;
import org.apache.catalina.LifecycleException;
import org.apache.catalina.util.*;
import org.apache.catalina.util.xml.*;
import org.xml.sax.AttributeList;
import javax.naming.*;
import javax.naming.directory.*;
import org.apache.catalina.realm.*;
import com.ecomda.ldap.security.*;
public class LdapRealm extends RealmBase {
protected static final String info = "ecomda.ldap.LdapRealm/1.0";
protected static final String name = "LdapRealm";
private Container container = null;
private HashMap principals = new HashMap();
private static StringManager sm = StringManager.getManager(Constants.Package);
private boolean started = false;
protected StringsearchBase;
protected StringproviderURL;
protected StringauthMechanism;
public String getInfo() { return info; }
public String getName() { return name; }
public LdapRealm() { authMechanism = "simple"; }
public void setProviderURL(String providerURL) {
if (debug 1)
System.out.println("setting providerURL: " + providerURL);
this.providerURL = providerURL;
}
public void setSearchBase(String searchBase) {
if (debug 1)
System.out.println("setting searchBase: " + searchBase);
this.searchBase = searchBase;
}
public void setAuthMechanism(String authMechanism) {
if (debug 1)
System.out.println("setting authMechanism: " + authMechanism);
this.authMechanism = authMechanism;
}
public Principal authenticate(String username, String credentials) {
String dn = "uid="+ username + ", " + searchBase;
// First check if we have cached info on this user.
LdapRealmPrincipal principal = (LdapRealmPrincipal) principals.get(username);
if ((principal != null) principal.checkCredentials(dn, credentials)) {
if (debug 1)
log(sm.getString("ldapRealm.authenticateSuccess", username));
return (principal);
}
// FIX! How do we age and remove old cached principals? Maybe use soft
references?.
// If not, try authenticate to LDAP server.
try {
if (debug 1)
System.out.println("trying to authenticate with dn: " + dn + ", to
URL: " + providerURL);
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, providerURL);
env.put(Context.SECURITY_AUTHENTICATION, authMechanism);
env.put(Context.SECURITY_PRINCIPAL, dn);
env.put(Context.SECURITY_CREDENTIALS, credentials);
DirContext ctx = new InitialDirContext(env);
ctx.lookup(dn);
if (debug 1)
log(sm.getString("ldapRealm.authenticateSuccess", username));
principal = new LdapRealmPrincipal(dn, credentials);
principals.put(username, principal);
return principal;
} catch (NamingException ne) {
if (debug 1)
log(sm.getString("ldapRealm.authenticateFailure", username));
}
return null;
}
protected String getPassword(String username) { return null; }
public boolean hasRole(Principal principal, String role) {
// FIX! should we really define this static role?
if (role.equalsIgnoreCase("authenticated"))
return true;
if ((principal == null) || (role == null) || !(principal instanceof
LdapRealmPrincipal))
return (false);
boolean result = ((LdapRealmPrincipal) principal).hasRole(role);
if (debug 1) {
String name = principal.getName();
if (result)
log(sm.getString("ldapRealm.hasRoleSuccess", name, role));
else
log(sm.getString("ldapRealm.hasRoleFailure", name, role));
}
return (result);
}
void addUser(String username, String password, String roles) {
LdapRealmPrincipal principal = new LdapRealmPrincipal(username, password);
principals.put(username, principal);
roles += ",";
Re: JaasRealm / LdapRealm
Hi, I came across a JAAS Realm implementation done for cataline by * @author a href="mailto:[EMAIL PROTECTED]"Kyle F. Downey/a Can't remember how I found it but I think it was from ML (probably tomcat-dev. I have a JAAS implementation which has been made outside Tomcat and I'm looking at making it fit into 3.x. However, I received a reply from Costin in the dev list who said all you need to do is implement authenticate() and authorise() hooks in Realm class. As Servlet API does not support JAAS or allow for more than a single Principal it looks like the approach has to be along the lines taken by K.F.D above. i.e. wrap a JAAS Subject in a Principal class. Rgds -- Antony Bowesman Teamware Group [EMAIL PROTECTED] tel: +358 9 5128 2562 fax: +358 9 5128 2705 Torgeir Veimo wrote: I tried to find info on any possible implementation of one of these in the ML archive, but didn't find anything except a pointer to Interceptor sources from a wrox book example. Are there anyone currently working on this? -- - Torgeir
JaasRealm / LdapRealm
I tried to find info on any possible implementation of one of these in the ML archive, but didn't find anything except a pointer to Interceptor sources from a wrox book example. Are there anyone currently working on this? -- - Torgeir
Re: LDAPRealm
This is what I'm looking for, too: I'm trying to use an LDAP directory for authentication and authorization. I'm totally new to Tomcat and just subscribed to this list and am checking thru the archives: does the same mechanism authenticate and obtain additional credentials? Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: LDAPRealm
Anyone working on an LDAPRealm? A good start might be to check out the LDAP Tomcat example from Professional JSP from Wrox Press. They set up a fairly simple, but workable LDAP security mechanism, though it is set up to work with an older version of Tomcat. Perhaps with the permission of Mark Wilcox, the author of the chapter, it would be possible to put together an LDAPRealm using his example. I know people were able to get the code from the example (available at wrox.com) to work with a more recent release of Tomcat. --Tim
FW: LDAPRealm
Michael L Smith AvantGardeSolutions.net (501) 225-6153 [EMAIL PROTECTED] -- The greatest programming project ever, took 6 days and 6 nights and on the 7th day the programmer rested... we've been trying to debug the bloody thing ever since -Original Message- From: Tim McNerney [mailto:[EMAIL PROTECTED]] Sent: Monday, December 18, 2000 1:30 PM To: [EMAIL PROTECTED] Subject:Re: LDAPRealm Anyone working on an LDAPRealm? A good start might be to check out the LDAP Tomcat example from Professional JSP from Wrox Press. They set up a fairly simple, but workable LDAP security mechanism, though it is set up to work with an older version of Tomcat. Perhaps with the permission of Mark Wilcox, the author of the chapter, it would be possible to put together an LDAPRealm using his example. I know people were able to get the code from the example (available at wrox.com) to work with a more recent release of Tomcat. --Tim
LDAPRealm
Anyone working on an LDAPRealm? __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
Re: LDAPRealm
"David M. Holmes" wrote: Anyone working on an LDAPRealm? Not that I know of. A contribution would be welcome. Craig McClanahan
