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 att
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 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"
