Re: Best practice question: where to place project libraries
Matt Raible wrote: -Original Message- From: Josh Rehman [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 10, 2004 5:49 PM Thanks. You bring up an interesting aspect of container configuration: database drivers. It would be interesting to extend the META-INF/context.xml tomcat convention to include support for the installation of 3rd party libraries. E.g., libraries placed in META-INF/server/lib will be placed into the similiar tomcat directory on deployment. Same thing for common/lib. +1 - that'd be slick! Seems wrong to me - one web application should not be able to change the environment for others. (Also I think a Tomcat server restart would be needed for it to take effect anyway). John. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Authentication without authorisation
Krause auth-constraint role-name*/role-name /auth-constraint Will require authentication but not authorisation. John. Krause Karin wrote: Hi all, I've got a question regarding authentication. I wish to do authentication without authorisation. So this means everybody should be free to access my web-resource but I wish to know who it is. Therefore the accessing user must login. As probably everybody knows here I can configure that by means of a security-constraint/login-config in my web.xml file. Here is a little example: security-constraint web-resource-collection web-resource-nameProtect the Helloworld example/web-resource-name description/ url-pattern/servlet/HelloWorldExample/url-pattern url-pattern/servlet/SessionExample/url-pattern http-methodPOST/http-method http-methodGET/http-method /web-resource-collection /security-constraint login-config auth-methodBASIC/auth-method realm-namepublic/realm-name /login-config Please remark that no auth-constraint is defined, because anybody should have free access to this web-resource. So what I need is authentication without authorisation. The problem is that only if I define some auth-constraint in the security-constraint the authenticate method of the Authenticator will be invoked. I think that the J2EE Standard makes no restriction that authentication can only be used in combination with authorisation. Am I wrong? Or is this a Tomcat bug? Cheers Karin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
reloading context configuration file
Using tomcat 4.1.18, I can deploy an application by copying a context configuration file (CCF) to the webapps directory. I can also make changes to the WAR file referenced in the CCF, and Tomcat will notice provided I stop the application first using Tomcat manager and start if afterwards. However I cannot find a way to have Tomcat see changes in the CCF itself, short of stopping and restarting the container. It seems that once the application is autodeployed the container caches the contents of the CCF. Removing the CCF or changing its contents appears to have no effect. I would have expected that when the application is stopped and then started the CCF should be re-read to pick up any changes. Is there a way to make this happen? (By the way I know about the ant deploy task but am exploring alternatives). Thanks, John. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HTTPS to HTTP
As said, I was thinking of the scenario where the *whole* site can be accessed without SSL - no admin links or anything like that. I agree with Craig that if there are any sensitive areas at all it is not safe to reuse the session id - and that before enabling any keep session id option it is vital that the user understands the consequences. In this scenario, the *only* page requiring SSL would be the login page that collects the username and password. (That could be either a dedicated application login page or the login page configured for form-based login. Basic authentication is never an option!). If this condition is met I still don't see that stealing the session id will enable anything that would be considered a risk. The benefit is that it hides the password while gaining any benefits of not using SSL where it is not needed. Having said all that - for our own situation the extra costs of requiring SSL for non-sensitive pages are negligible so everything involving a user authentication is done under SSL. But that may not be true for everyone. John Craig R. McClanahan wrote: On Thu, 9 Jan 2003, John Holman wrote: Date: Thu, 09 Jan 2003 12:56:16 + From: John Holman [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: HTTPS to HTTP Yes, that is clearly a risk. The *whole* web application needs have no risks in order to allow http access to any of it - any sensitive link and it must all be https. (And of course if SSO is enabled *all* web applications for the virtual host must be considered safe). Otherwise I'm not convinced that session stealing is really a problem - though open to counter-arguements. Consider a scenario where you have admin pages that require SSL, and normal pages that can run on either. Assume Tomcat were modified to migrate your session back. Consider the following course of events: * User A logs on, selects link for an admin function, and is switched to SSL for that part. * User A then switches back to non-SSL. Among other things, this means that the session id is now visible in plaintext on the wire. * User B snoops the network, acquires the session id, and submits an SSL request (with the stolen session id) to an admin function. * Server blithely executes the forged request, because login identity is attached to the session id (which is now plaintext -- it wouldn't be if the session had been created under SSL and never allowed to switch back). Once an application has switched from HTTP to HTTPS for a session, it should be programmed to never go back again. John Craig Ralph Einfeldt wrote: But be aware that quite simple changes in the configuration of tomcat can lead to big security holes. Guess what happens if you or somebody else someday decides to switch from basic authentification to form authentifcation and the sysadmin visits the user side and somebody steals the sysadmins session ...) -Original Message- From: David Hemingway [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 12:08 PM To: Tomcat Users List Subject: Re: HTTPS to HTTP Thats is my exact situation. The sysadmin section of teh site is 100% https. but the on the user side there is nothing that sensitive and little harm they could be cause stealing someones session. It would not be worth going to the trouble of stealing the session for the benefit you would get. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTPS to HTTP
My understanding (at the moment) is that there are two scenarios where sesssion id reuse might be safe: a) (the scenario I suggested) the *only* secure page requiring https is the login page. Accessing that using the sniffed session id will only let the bad guy login - which gains him nothing. b) (my understanding of the scenario suggested by Jeff Schnitzer). There *are* other secure pages within the site but (somehow) reauthentication is forced when these are requested with a session id that has previously been used in the http context. I don't actually see how that would be implemented but assuming that it was it seems plausible. I'd like to see an analysis of the risks for these two scenarios. John. Jacob Kjome wrote: It is my understanding that if Tomcat allowed you use the same session and the session was created under https for a particular user, then once it gets to http the session id is now in clear text. This is what, I believe, Craig is talking about when he says that using SSL in this manner only creates the appearance of security, not true security. All I'd have to do to wreak some serious havoc is sniff packets, hijack the session, and browse back into the secure sections of the site under the guise of the user whose session I hijacked. How is that security? Jake At 08:17 PM 1/9/2003 -0800, you wrote: I'm aware of that. The tomcat-specific issue is that it won't let you make the transition from https to http on the same session. That's frustrating. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTPS to HTTP
I agree with all of this. For functionality like changing the password I'd use a different SSL-only web application, not include that functionality in the mixed application. The user would then have to reauthenticate to change the password - but I'd want them to do that anyway since they may have gone off to lunch leaving an active session on their PC ... John Ralph Einfeldt wrote: As long as you know what you do and are shure that you (or any other person that may maintain the site in the future) always remember what you have done that may be ok. The risk I see that with such an approach is that it is quite easy to forget about the potential risks of this solution when somebody adds some functionality to the side somewhere in the future that breaks the basic assumption behind this solution. If you use form based login make damn shure that there is no way for an user to edit his password or other sensitive data as this way you can't protect that page against an intruder after the user switched back to http. With form based-login the user is stored in the session and somebody who steals a session is authenticated as far as tomcat is considered. -Original Message- From: John Holman [mailto:[EMAIL PROTECTED]] Sent: Friday, January 10, 2003 2:02 PM To: Tomcat Users List Subject: Re: HTTPS to HTTP In this scenario, the *only* page requiring SSL would be the login page that collects the username and password. (That could be either a dedicated application login page or the login page configured for form-based login. Basic authentication is never an option!). If this condition is met I still don't see that stealing the session id will enable anything that would be considered a risk. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Solaris Authentication
If the Solaris usernames and passwords are held in an LDAP directory you should be able to use the JNDI Realm. You would need to supplement the Solaris user info with role information in the same directory. I don't know of a documented method for connecting to other approaches (e.g. local files (/etc/password + /etc/shadow, NIS, etc). In some cases it *might* be possible to use the JAAS realm with a suitable security provider, or you could write your own Tomcat realm. Using local files is likely to be difficult because Tomcat should not be run as root for security reasons, yet you need to be root to access /etc/shadow. John Khadbai, Abdul (ANTS) wrote: Hi Is there any way that tomcat can hook into the solaris user names and passwords rather than creating a new database with passwords and usernames i.e in a way which weblogic can use NT authentication ? Please let me know. Many Thanks Abdul Khadbai *** This communication (including any attachments) contains confidential information. If you are not the intended recipient and you have received this communication in error, you should destroy it without copying, disclosing or otherwise using its contents. Please notify the sender immediately of the error. Internet communications are not necessarily secure and may be intercepted or changed after they are sent. Abbey National Treasury Services plc does not accept liability for any loss you may suffer as a result of interception or any liability for such changes. If you wish to confirm the origin or content of this communication, please contact the sender by using an alternative means of communication. This communication does not create or modify any contract and, unless otherwise stated, is not intended to be contractually binding. Abbey National Treasury Services plc. Registered Office: Abbey National House, 2 Triton Square, Regents Place, London NW1 3AN. Registered in England under Company Registration Number: 2338548. Regulated by the Financial Services Authority (FSA). *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTPS to HTTP
Ralph Einfeldt wrote: Anybody who can listen to your traffic, can hijack a session. He just has to create a request with the same sessionid (either as cookie or in the url). So after you go back from https to http you open the session to an attacker. The risks that are involved with that, depends on the application. I think it would be useful to be able to configure Tomcat to use the same session id when downgrading from https to http. This caters for the case where an application really does not have significant security requirements - the login is needed only to identify the user so that e.g their non-confidential preferences can be applied and it does not matter that others might masquerade as that user. In that case the session may as well be conducted in http (e.g. for performance reasons). However the password itself should always be hidden using https, because it is likely that the user will employ that same password for other applications where security *is* important. Note that when there are risks with the application there should be no http access at all - that's easy enough to arrange. John -Original Message- From: David Hemingway [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 7:59 AM To: Tomcat Users List Subject: HTTPS to HTTP 2 Does this open up a huge security hole that I am not seeing. I have heard things about session hijacking? Many thanks regards, Dave -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTPS to HTTP
Yes, that is clearly a risk. The *whole* web application needs have no risks in order to allow http access to any of it - any sensitive link and it must all be https. (And of course if SSO is enabled *all* web applications for the virtual host must be considered safe). Otherwise I'm not convinced that session stealing is really a problem - though open to counter-arguements. John Ralph Einfeldt wrote: But be aware that quite simple changes in the configuration of tomcat can lead to big security holes. Guess what happens if you or somebody else someday decides to switch from basic authentification to form authentifcation and the sysadmin visits the user side and somebody steals the sysadmins session ...) -Original Message- From: David Hemingway [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 12:08 PM To: Tomcat Users List Subject: Re: HTTPS to HTTP Thats is my exact situation. The sysadmin section of teh site is 100% https. but the on the user side there is nothing that sensitive and little harm they could be cause stealing someones session. It would not be worth going to the trouble of stealing the session for the benefit you would get. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JNDIRealm login failure
Gil Check whether the directory server is configured to time out idle connections. If so, the first attempt made by Tomcat to authenticate after a long enough period of inactivity will fail in the manner you describe. If this is the problem, you should find that after a second login attempt has succeeded other users can authenticate straight away - until the next long period of inactivity. You may be able fix the problem by disabling timeout on the directory server. (You don't say which directory server you are using). Really there should be an option for JNDIRealm to check whether the connection is valid and reconnect if not before the authentication attempt is made. However its connection management is very basic! John. Gil Chilton wrote: I have created a simple tomcat web app that uses a JNDIRealm for authentication per the instructions in the Tomcat 4.1 documentation. When I start tomcat, the login process for this web app works fine for a few minutes or logins. Eventually, I reach a state where the first login always fails until I restart Tomcat. Each failed login results in the following error in the logs: 2003-01-06 14:33:35 JNDIRealm[Standalone]: Exception performing authentication javax.naming.CommunicationException. Root exception is java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.io.BufferedInputStream.fill(BufferedInputStream.java:183) at java.io.BufferedInputStream.read1(BufferedInputStream.java:222) at java.io.BufferedInputStream.read(BufferedInputStream.java:277) at com.sun.jndi.ldap.Connection.run(Connection.java:779) at java.lang.Thread.run(Thread.java:536) If the user backs up and resubmits the login a second time, it works with no additional log entries. I have seen this on Tomcat 4.1.12 and now 4.1.18 with BASIC or FORM based authentication. I have searched the web and mailing lists without a match. The platform is RedHat Linux 7.3 or 8.0 with Sun's SDK 1.4.1_01 installed. Any ideas? Thanks __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JNDI Realm on Tomcat 4 does not work
Stephan
I answered this a couple of days ago ... did it not reach the list?
You need to use curly brackets {} for the substitions, not parentheses ()
e.g.
userPattern=uid={0},ou=people,dc=yikester,dc=net
not
userPattern=uid=(0),ou=people,dc=yikester,dc=net
John
Stephan Schwab wrote:
Hi,
I want to secure a webapp with the JNDI realm. But the LDAP query is
sent wrong to my OpenLDAP server.
Here is a snippet from server.xml:
Realm className=org.apache.catalina.realm.JNDIRealm debug=99
connectionURL=ldap://localhost;
userPattern=uid=(0),ou=people,dc=yikester,dc=net
roleBase=ou=groups,dc=yikester,dc=net
roleName=cn
roleSearch=(uniqueMember=(0))
userPassword=userPassword /
On the OpenLDAP server I see in the logfile:
SRCH base=uid=(0),ou=people,dc=yikester,dc=net scope=0
filter=(objectClass=*)
So, the problem is that something prevents the exchange of uid=(0) with
the username in question.
I've tried with Tomcat 4.0.4 included in Netbeans 3.4 IDE and with
Tomcat 4.1.10. ldap.jar is from java.sun.com. I've tried with ldap.jar
from Novell Too, but the result is the same.
Any hints?
Stephan
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JNDI Realm on Tomcat 4 does not work
You need to use curly brackets {} for the substitions, not parentheses ()
e.g.
userPattern=uid={0},ou=people,dc=yikester,dc=net
not
userPattern=uid=(0),ou=people,dc=yikester,dc=net
John.
Stephan Schwab wrote:
Hi,
I want to secure a webapp with the JNDI realm. But the LDAP query is
sent
wrong to my OpenLDAP server.
Here is a snippet from server.xml:
Realm className=org.apache.catalina.realm.JNDIRealm debug=99
connectionURL=ldap://localhost;
userPattern=uid=(0),ou=people,dc=yikester,dc=net
roleBase=ou=groups,dc=yikester,dc=net
roleName=cn
roleSearch=(uniqueMember=(0))
userPassword=userPassword /
On the OpenLDAP server I see in the logfile:
SRCH base=uid=(0),ou=people,dc=yikester,dc=net scope=0
filter=(objectClass=*)
So, the problem is that something prevents the exchange of uid=(0) with
the
username in question.
I've tried with Tomcat 4.0.4 included in Netbeans 3.4 IDE and with
Tomcat
4.1.10. ldap.jar is from java.sun.com. I've tried with ldap.jar from
Novell
Too, but the result is the same.
Any hints?
Stephan
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Using A Directory Server for a Realm??
Should be possible using JNDIRealm. See the realm how-to. John. Nicholas Orr wrote: Hi, Has anyone tried using a Novel or Active Directory for a Realm. Would this even be possible? Nicholas Orr ** The information contained in this e-mail is confidential and is intended only for the use of the addressee(s). If you receive this e-mail in error, any use, distribution or copying of this e-mail is not permitted. You are requested to forward unwanted e-mail and address any problems to the MIM Holdings Limited Support Centre. For general enquires: ++61 7 3833 8000 Support Centre e-mail: [EMAIL PROTECTED] Support Centre phone: Australia 1800500646 International ++61 7 38338042 ** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JNDIRealm in tomcat
The patch is included in tomcat 4.1.10 John. Vincent Stoessel wrote: Vincent Stoessel wrote: I was thinking about trying to create a JNDIRealm inside of Tomcat 4.0.4 (java 1.4se) , I've already written a cool little bean to that allows me to autheticate against our ldap/nds server, but I see that tomcat authetication is role based, are roles something that would have to be added to the netware 5/6 ldap/nds schema. Any Novell heads out here? I would rather user our existing system than build a new employee db. Thanks. Ok, I sent this out before I read this: http://marc.theaimsgroup.com/?l=tomcat-devm=101515968207676w=2 this patch seems very cool, has it been incorporated into tomcat? If so what version? Thanks. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Problems getting roles in JNDI Realm (This *IS* a problem.)
Providing a connectionName and connectionPassword does *not* cause
JNDIRealm to lookup the password. It will still authenticate by binding
as the user unless you specify the userPassword configuration attribute.
Looking up roles as the administrator (or anonymously if connectionName
and connectionPassword are not specified) is a deliberate design decision.
John.
Mark R. Diggory wrote:
Looking over the JNDIRealm Code I notice that in the bindAsUser method
that the users principle and credentials are stripped out of the
context. It is after this point that the JNDI search request is made
to gather the roles from the ldap server. Shouldn't it be *after* the
search for the roles that the users principle and credentials is
removed from the DirContext?
This would mean that I can never *really* use bindAsUser(...) strategy
because I'd always have to provide a connectionUser and
connectionPassword to do the role lookup. Not good at all. This means
the configuration is impossible because if you provide the
connectionName and connectionPassword attributes, then it just looks
up the password on authentication instead of binding as the user.
-M.
Mark R. Diggory wrote:
I know my request should work at the LDAP Server through JNDI because
the following does work when I make a request to the LDAP server. I
do get back the groups.
%
Hashtable env = new Hashtable();
env.put(DirContext.INITIAL_CONTEXT_FACTORY,com.sun.jndi.ldap.LdapCtxFactory);
env.put(DirContext.SECURITY_PRINCIPAL,uid=jadmin,ou=vdcid,ou=hmdc,o=vdc);
env.put(DirContext.SECURITY_CREDENTIALS,**);
env.put(DirContext.PROVIDER_URL,ldap://vdc.fas.harvard.edu:389;);
DirContext ctx = new InitialDirContext(env);
SearchControls controls = new SearchControls();
controls.setSearchScope(SearchControls.SUBTREE_SCOPE);
controls.setReturningAttributes(new String[] {vdcGroup});
NamingEnumeration enum =
ctx.search(o=vdc,(member=uid=jadmin,ou=vdcid,ou=hmdc,o=vdc),controls);
while(enum.hasMore()){
SearchResult sr = (SearchResult)enum.next();
out.print(sr.getAttributes().get(vdcGroup) + BR);
}
%
is returning
vdcGroup: public
vdcGroup: researchers
vdcGroup: curators
vdcGroup: administrators
-Mark
Mark R. Diggory wrote:
I'm trying to get a realm set up via JNDI to an Openldap server.
Here is my current server.xml config.
Realm
className=org.apache.catalina.realm.JNDIRealm debug=99
connectionURL=ldap://vdc.fas.harvard.edu:389;
userPattern=uid={0},ou=vdcid,ou=hmdc,o=vdc
roleBase=o=vdc
roleSubtree=true
roleName=vdcGroup
roleSearch=(member={0})
digest=SHA
/
I'm using vdcGroup entries to store unique member attributes named
'member'. I can do this search using straight JNDI in a Test Java
Application. But the realm will not return the vdcGroups that jadmin
is a member of. Is there something obvious I am missing?
-Mark
2002-09-07 10:40:51 JNDIRealm[Standalone]: Connecting to URL
ldap://vdc.fas.harvard.edu:389
2002-09-07 10:41:11 JNDIRealm[Standalone]: lookupUser(jadmin)
2002-09-07 10:41:11 JNDIRealm[Standalone]:
dn=uid=jadmin,ou=vdcid,ou=hmdc,o=vdc
2002-09-07 10:41:11 JNDIRealm[Standalone]: validating credentials
by binding as the user
2002-09-07 10:41:11 JNDIRealm[Standalone]: binding as
uid=jadmin,ou=vdcid,ou=hmdc,o=vdc
2002-09-07 10:41:11 JNDIRealm[Standalone]: Username jadmin
successfully authenticated
2002-09-07 10:41:11 JNDIRealm[Standalone]:
getRoles(uid=jadmin,ou=vdcid,ou=hmdc,o=vdc)
2002-09-07 10:41:11 JNDIRealm[Standalone]: Searching role base
'o=vdc' for attribute 'vdcGroup'
2002-09-07 10:41:11 JNDIRealm[Standalone]: With filter expression
'(member=uid=jadmin,ou=vdcid,ou=hmdc,o=vdc)'
2002-09-07 10:41:11 JNDIRealm[Standalone]: Returning 0 roles
2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT
have role tomcat
2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT
have role role1
2002-09-07 10:41:12 JNDIRealm[Standalone]: Username jadmin does NOT
have role administrators
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Problems getting roles in JNDI Realm (This *IS* a problem.)
Mark Looking up roles as the administrator (or anonymously if connectionName and connectionPassword are not specified) is a deliberate design decision. John. ?? But, if you've already established a connection with the users principle and credentials, why would ever want to convert to a diferent set of principle/credentials to do the role lookup as a *rule*? This seems to be a *configuration* decision. It would be benifical if the interface provided for this option by providing something like a bind-as-user='true|false' query-as-user='true|false' in the realm configuration. One reason for the decision was that users may not have the permissions to retrieve their own roles from the directory, at least when roles are represented as LDAP group entries. (Such permissions would enable a user to retrieve the roles of any other user, which may be considered a breach of privacy). Another reason was that for efficiency reasons role information held as the value of an attribute in the user's entry is retrieved as an integral part of searching for that entry (when a user search is configured). That search must be carried out when bound as the administrator, since we don't yet know the user's dn, and so it seemed consistent to use the same credentials when retrieving role information held as group entries. If you are worried about privacy you won't want to give users the ability to read the roles of others - so binding as the user to retrieve group-based role information won't work. And if you are not, just allow the roles to be read when bound anonymously. So I can't see it would add much (except to the complexity of the program!) to support a query-as-user option. Though I may be missing something ... John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JNDIRealm config
Tim Funk wrote:
To use JNDIRealm with Netscape Directory server you need the 4.1.X
series of tomcat and you need to bind as the user. So do not provide
connectionName and connection password.
Actually it's userPassword that should not be provided if you want
JNDIRealm to bind as the user for authentication. connectionName and
connectionPassword will still be used if provided to retrieve role
information and to search the directory for the user's entry if
required, but are optional.
This is documented in some detail in the realm howto included with 4.1.8
and later.
John.
In the 4.0.X series the passwords are compared in an incompatible
manner with respect to Netscape Dir server.
- - wrote:
hi
This looks long but it's actually straightforward.
I can't get the JNDIRealm config to work Netscape Directory Server 3.1.
I suspect the conf. of the JNDIRealm elment is wrong but don't know why.
I have a LDIF file exported from Netscape Directory Server 3.1 which
define(loosely speaking)
- an admin user that I use in JNDIRealm for initial connection
- a sales person
- a SalesGroup role which has sales person as a member
Other stuff removed for clarity.
dn: uid=admin,o=company.com
objectclass: top
objectclass: person
objectclass: organizationalperson
objectclass: inetorgperson
cn: SuiteSpot Administrator
sn: Administrator
givenname: SuiteSpot
uid: admin
userpassword: {SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
dn: uid=salesID,o=company.com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: nsLicenseUser
givenname: salesFir
sn: salesSur
cn: salesFul
uid: salesID
userpassword: {SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g=
dn: cn=SalesGroup,o=company.com
objectclass: top
objectclass: groupOfUniqueNames
cn: SalesGroup
uniquemember: uid=salesID,o=company.com
So my JNDIRealm config is,
Realm className=org.apache.catalina.realm.JNDIRealm debug=99
connectionName=uid=admin,o=company.com
connectionPassword=password
connectionURL=ldap://localhost:390;
roleName=cn
roleSearch=(uniquemember={0})
roleSubtree=true
userPassword=userpassword
userPattern=uid={0},o=company.com
/
I have tried many combinations of patterns and attributes in the
above configuration but none worked.
The initial connection and authentication using admin seemed to work OK.
But I can't get it to authenticate the sales person/salesGroup.
I enter the salesID as the username and its password in the auth.
dialog box
web.xml has
security-constraint
web-resource-collection
web-resource-nameSales/web-resource-name
url-pattern/jsp/SalesIndex.jsp/url-pattern
/web-resource-collection
auth-constraint
role-nameSalesGroup/role-name
/auth-constraint
/security-constraint
login-config
auth-methodDIGEST/auth-method
realm-nameSID/realm-name
/login-config
security-role
role-nameSalesGroup/role-name
/security-role
Thanks very much
-
Do You Yahoo!?
Yahoo! Health - Feel better, live better
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat4 / OpenLDAP - Encrypted connectionPassword in JNDI Realm(server.xml) - Please Help
Hi Jeremy.
For the JNDI realm to connect to the directory server with administrator
privileges it needs to know the plaintext password. Having a digest in
the config file isn't possible because the realm can't reconstruct the
plaintext password from it. I suppose some other encryption would be
possible, but you'd still need to have the plaintext key for *that* in
some file somewhere, so I doubt it would make much difference. As you
say, having the admin password in the config file is certainly a
security issue, and is one of the disadvantages of the way that the
realm currently included in Tomcat 4.0 operates.
The new JNDI realm in the CVS HEAD authenticates by binding to the
directory as the user rather than connecting as an administrator and
retrieving the user's password. This normally needs no special
privileges, so no password need be given in the config file. The new
realm is not included in the Tomcat 4.0 releases (so far at least) but I
could send you a jar file to install in server/lib giving the same
functionality for Tomcat 4.0.x if that would help.
John.
Jeremy Prellwitz wrote:
Hi all,
i searched the archives but could not come up with an answer for this.
I have everything working for LDAP authentication on my server, and i've
figured out how to include non plain text passwords everywhere except for
the connectionPassword attribute of the Realm tag in the
$CATALINA_HOME/conf/server.xml file. I would like to replace the
MY_CURRENT_PLAIN_TEXT_PASSWORD string with an encrypted password for this
configuration file, as everyone knows, this is otherwise a pretty good
security hole.
Realm className=org.apache.catalina.realm.JNDIRealm debug=99
connectionName=cn=root,dc=MYDOMAIN,dc=ca
connectionPassword=MY_CURRENT_PLAIN_TEXT_PASSWORD
connectionURL=ldap://MYHOST:389;
roleBase=dc=roles,dc=MYDOMAIN,dc=ca
roleName=cn
roleSearch=(uniqueMember={0})
roleSubtree=false
digest=SHA
userPassword=userPassword
userPattern=uid={0},dc=MYDOMAIN,dc=ca
/
I've tried using this : java org.apache.catalina.realm.RealmBase -a
{algorithm} {cleartext-password}, which is what i used to enter my passwords
into my OpenLDAP server, but with this you specify the encryption algorithm
with the digest attribute.
Please help. How do i specify the algorithm and encrypted password for the
connectionPassword attribute; and if you would..which tool do i use to
create this password?
Thanks a million!!!
--
To unsubscribe: mailto:[EMAIL PROTECTED]
For additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list: mailto:[EMAIL PROTECTED]
--
To unsubscribe: mailto:[EMAIL PROTECTED]
For additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list: mailto:[EMAIL PROTECTED]
Re: help with realm setup
Tony If you use the newly committed JNDIRealm, you can easily arrange that each user has a role whose name is the same as their username. Just set userRoleName to uid (or whatever attribute of the user's directory entry holds the username) and your security constraint below should work. Authorisation by username will is also possible with the original JNDIRealm, if you define a suitable role search, but you couldn't then use LDAP groups for authorisation as well. John. At 22:14 14/03/02, Tony Dahbura wrote: I would like to set up my realm to allow folks in by userid not by rolename. I do not know what the tag for the web.xml file should be The following is a sample security constraint. The role names are working fine, but I need to say if a user is tony or user is x then allow them in, but without the use of roles. security-constraint display-nameExample Security Constraint/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name !-- Define the context-relative URL(s) to be protected -- url-pattern/jsp/security/protected/*/url-pattern !-- If you list http methods, only those methods are protected -- http-methodDELETE/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint !-- Anyone with one of the listed roles may access this area -- !-- the following does not work because tony is a userid not a rolename -- !-- what tag should I use to get this to work so userid tony can access the application space? -- role-nametony/role-name role-namemarketing/role-name role-namerole1/role-name /auth-constraint /security-constraint Thanks, Tony -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: IMPORTANT - error while using LDAP/JDNI authentication with tomcat 4.0
Frederic
# Define an entry to base role searches on
dn: dc=roles,dc=mycompany,dc=com
cn: roles
objectClass: person
sn: Roles Entry
This entry has the wrong object class - should be dcObject. Probably it has
not been created in the directory, so the role search is failing with the
no such object error you are seeing.
You should have seen an error when you tried to load the LDIF file, by the
way. You can check whether it has been created using
the ldapsearch utility.
John
At 09:29 27/02/02, Fredrick Rinald wrote
Hello,
Please help me.
I'm a french student and I need to implement LDAP authentication with
tomcat 4 for my project. The user authentication is correct but the
authorization failed because of the role search. Tomcat is unable to get
the corresponding role in my ldap directory.
Here's my LDAP directory definition (I use openldap):
include/usr/local/etc/openldap/schema/core.schema
pidfile/usr/local/var/slapd.pid
argsfile/usr/local/var/slapd.args
database ldbm
suffix dc=mycompany,dc=com
rootdn cn=Manager,dc=mycompany,dc=com
directory /usr/local/var/openldap-ldbm
rootpw secret
indexobjectClasseq
Here's my LDAP directory (LDIF file):
dn : dc=mycompany,dc=com
objectclass: dcObject
objectclass: organization
o: Example Company
# Define a user named 'tomcat'
dn: cn=tomcat,dc=mycompany,dc=com
cn: tomcat
userPassword: tomcat
sn: Tomcat User
objectClass: person
# Define a user named 'role1'
dn: cn=role1,dc=mycompany,dc=com
cn: role1
userPassword: tomcat
sn: Role1 User
objectClass: person
# Define a user named 'both'
dn: cn=both,dc=mycompany,dc=com
cn: both
userPassword: tomcat
sn: Both User
objectClass: person
# Define an entry to base role searches on
dn: dc=roles,dc=mycompany,dc=com
cn: roles
objectClass: person
sn: Roles Entry
# Define all members of the 'tomcat' role
dn: cn=tomcat,dc=roles,dc=mycompany,dc=com
cn: tomcat
objectClass: groupOfUniqueNames
uniqueMember: cn=tomcat,dc=mycompany,dc=com
uniqueMember: cn=both,dc=mycompany,dc=com
# Define all members of the 'role1' role
dn: cn=role1,dc=roles,dc=mycompany,dc=com
cn: role1
objectClass: groupOfUniqueNames
uniqueMember: cn=role1,dc=mycompany,dc=com
uniqueMember: cn=both,dc=mycompany,dc=com
Here's my Tomcat 4 REALM declaration :
Realm className=org.apache.catalina.realm.JNDIRealm debug=99
connectionName=cn=Manager,dc=mycompany,dc=com
connectionPassword=secret
connectionURL=ldap://localhost;
roleBase=dc=roles
roleName=cn
roleSearch=(uniqueMember={0})
roleSubtree=false
userPassword=userPassword
userPattern=cn={0},dc=mycompany,dc=com
/
Here's my catalina_log.2002-02-27.txt file :
2002-02-27 10:15:46 HttpConnector Opening server socket on all host
IP addresses
2002-02-27 10:15:46 JNDIRealm[Standalone]: Connecting to URL
ldap://localhost
2002-02-27 10:15:59 HttpConnector[8080] Starting background thread
2002-02-27 10:15:59 HttpProcessor[8080][1] Starting background thread
2002-02-27 10:15:59 HttpProcessor[8080][0] Starting background thread
2002-02-27 10:15:59 HttpProcessor[8080][2] Starting background thread
2002-02-27 10:15:59 HttpProcessor[8080][3] Starting background thread
2002-02-27 10:15:59 HttpProcessor[8080][4] Starting background thread
2002-02-27 10:16:19 JNDIRealm[Standalone]: getUserDN(tomcat)
2002-02-27 10:16:19 JNDIRealm[Standalone]:
dn=cn=tomcat,dc=mycompany,dc=com
2002-02-27 10:16:19 JNDIRealm[Standalone]: retrieving attribute
userPassword
2002-02-27 10:16:19 JNDIRealm[Standalone]: retrieving value
2002-02-27 10:16:19 JNDIRealm[Standalone]: validating credentials
2002-02-27 10:16:19 JNDIRealm[Standalone]: Username tomcat
successfully authenticated
2002-02-27 10:16:19 JNDIRealm[Standalone]:
getRoles(cn=tomcat,dc=mycompany,dc=com)
2002-02-27 10:16:19 JNDIRealm[Standalone]: Searching role base
'dc=roles' for attribute 'cn'
2002-02-27 10:16:19 JNDIRealm[Standalone]: With filter expression
'(uniqueMember=cn=tomcat,dc=mycompany,dc=com)'
2002-02-27 10:16:19 JNDIRealm[Standalone]: Exception performing
authentication
javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such
Object]; remaining name 'dc=roles'
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:2761)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2682)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2488)
at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1660)
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1583)
at
Re: Using JNDIRealm with password digesting and openldap
Dirk
This isn''t possible with the current JNDIRealm in Tomcat 4, though you
could probably specify the appropriate digest algorithm and
hack the Tomcat code to disregard the {crypt} prefix returned from OpenLDAP.
A much cleaner solution is to have the JNDIRealm to authenticate by binding
to the directory as the user,
in which case doesn't matter how how the password is stored in the
directory. I submitted a patch
for JNDIRealm to the tomcat-dev list last week which supports this, and you
could consider giving that a try. This assumes that you
are using HTTP basic authentication or form-based login, not HTTP digest
authentication.
John.
At 15:59 04/02/02, you wrote:
**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
**
Hi,
I'm trying to use tomcat's JNDIRealm with OpenLDAP. I've converted my
passwords to digest format in the LDAP directory instead of plain text.
Apparently, tomcat only excepts only hex formatted password where openLDAP
provides passwords of the format
{crypt}X where crypt = { SHA, MD, ... } and XXX is a base64 encoded
integer.
Is there a way to configure tomcat to accept this format of passwords? If
so does this require any recompilation of
tomcat?
Thanks for your help,
-- Dirk
--
To unsubscribe: mailto:[EMAIL PROTECTED]
For additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list: mailto:[EMAIL PROTECTED]
--
To unsubscribe: mailto:[EMAIL PROTECTED]
For additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list: mailto:[EMAIL PROTECTED]
Re: JNDIRealm
Fredrik At 15:06 29/01/02, you wrote: John Holman wrote: JNDIRealm works by retrieving the password from the directory server and comparing it explicitly with the value given by the user. Unfortunately AFAIK this mode of operation will not work with eDirectory. Reading the Realm HOWTO again made me realize that... Why would anyone want the Realm to get the password from the server instead of doing a simple LDAP bind? I agree - almost always a bind is better, unless you need to support HTTP digest authentication. There have been proposals (e.g. from me) to enhance JNDIRealm to allow it to authenticate the user by binding to the directory server, in the same way as auth_ldap. This should work with eDirectory, but isn't available yet. Have the proposal been approved by the Tomcat developers, and are there any people working on this issue? Similar proposals are in the draft functional specification for the JNDI realm, and I submitted a patch to the tomcat-dev list earlier today that implements the required functionality. You are more than welcome to try it, if you get the chance. I'm hoping that this patch will get incorporated into Tomcat ... John. -- Fredrik Westermarck -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: JNDIRealm
JNDIRealm works by retrieving the password from the directory server and comparing it explicitly with the value given by the user. Unfortunately AFAIK this mode of operation will not work with eDirectory. There have been proposals (e.g. from me) to enhance JNDIRealm to allow it to authenticate the user by binding to the directory server, in the same way as auth_ldap. This should work with eDirectory, but isn't available yet. John. At 12:55 28/01/02, you wrote: Hi! We are going to upgrade to Tomcat and are investigating how to implement user authentication. Currently we are using the authentication that is offered in Apache with auth_ldap. Since Tomcat offers an authentication mechanism (Realms) we would like to use that functionality. However since we are using Novell NDS (eDriectory) to store our users and have several NDS servers, we would like to have Tomcat to authenticate a user against one or more of the NDS servers. Is this possible? As far as I can see the JNDIRealm can only handle a single server to authenticate users against. -- Fredrik Westermarck -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
worker.tomcat_home etc in mod_jk's workers.properties
Can anyone explain the purpose of the worker.tomcat_home, worker.java_home and ps entries in mod_jk's workers.properties file? My understanding is that workers.properties is used only to configure the mod_jk webserver plugin, and I'm at a loss to see why that would need to know anything about Tomcat or Java. (Anything that Tomcat needs to know should surely be specified in the server.xml configuration file anyway). Indeed when mod_jk is deployed on a system without either Java or Tomcat installed (because these are running on a different host) these entries are meaningless - and things seem to work OK if you just miss them out. What am I missing? Thanks, John. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: Session Question
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 15, 2001 12:54 PM Subject: Session Question I am currently writing a pretty complex data entry HTML page for an application. The HTML has 7 different frames where data is input, one represents the master table and the others detail tables. I am trying to come up with a way to keep all of the data entered into each frame for updating the database (I want to update all the records in one transaction). There some obvious ways of doing this as with invisible fields on the master frame, and URL rewriting (cookies are out in this case) but I have also been looking into using the Session object. I know the object is used for shopping carts on commercial web sites but would it be a good to use it to keep all the input values for various input forms? There will be from 40 - 50 items of data stored in the session object and a user will only be able to one form at a time? Yes, sessions are provided for this kind of thing. Note that Tomcat uses cookies to maintain the session if it can. It will use URL rewriting if cookies are disabled but you may have to amend your pages to support that. It may be worth looking at a web application framework such as Jakarta Struts that can run within Tomcat and help with some of this. John.
Re: Session Question
When cookies are disabled, http requests to your web application have to include the session id in order for the web container to find the correct session. For example, if a page contains a link pointing to your servlet, the URL for that link must be encoded using HttpServletResponse.encodeURL(). This means the page cannot be a static one. John. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 15, 2001 1:34 PM Subject: Re: Session Question John, In what ways may I have amend my pages due to cookies being disabled? John Holman j.g.holman@qTo: [EMAIL PROTECTED] mw.ac.ukcc: Subject: Re: Session Question 05/15/01 07:15 AM Please respond to tomcat-user - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 15, 2001 12:54 PM Subject: Session Question I am currently writing a pretty complex data entry HTML page for an application. The HTML has 7 different frames where data is input, one represents the master table and the others detail tables. I am trying to come up with a way to keep all of the data entered into each frame for updating the database (I want to update all the records in one transaction). There some obvious ways of doing this as with invisible fields on the master frame, and URL rewriting (cookies are out in this case) but I have also been looking into using the Session object. I know the object is used for shopping carts on commercial web sites but would it be a good to use it to keep all the input values for various input forms? There will be from 40 - 50 items of data stored in the session object and a user will only be able to one form at a time? Yes, sessions are provided for this kind of thing. Note that Tomcat uses cookies to maintain the session if it can. It will use URL rewriting if cookies are disabled but you may have to amend your pages to support that. It may be worth looking at a web application framework such as Jakarta Struts that can run within Tomcat and help with some of this. John.
