Re: Admin password for Tomcat
Chris, On 12/26/2023 11:35 AM, Christopher Schultz wrote: Jerry, On 12/24/23 19:18, Jerry Malcolm wrote: Chris, On 11/8/2023 2:43 PM, Christopher Schultz wrote: Jerry, On 11/6/23 23:22, Jerry Malcolm wrote: On 11/5/2023 11:54 AM, Jerry Malcolm wrote: On 11/5/2023 9:26 AM, Christopher Schultz wrote: Jerry, On 11/4/23 20:17, Jerry Malcolm wrote: My support team needs to be able to log in to our site as various users (on behalf of...) to be able to see exactly what they are seeing since roles, access groups, history is different for different users. I would like to implement an admin password where I can log in as any userId with this password. I totally realize the security risks involved in this. But I am handling the security risks with additional authorizations. I simply need to make every user have two passwords... their real personal password, and the admin password. The only alternative I have right now is to save off the user's password hash in the USERS table, replace it with my password hash, then restore the user's original password when I'm done. I'm not thrilled with that solution first because it's a pain and error prone, and also because the user can no longer log in while their password is replaced with my password. I figure this function is buried in the authenticator code somewhere. But I'd first like to see if anybody has done anything like this already. If not, could somebody point me in the right direction to the tomcat source file that I'm going to need to modify and also what's involved in making authentication use my updated class instead of the default. Suggestions? This sounds like "impersonation" to me, which, I think, can be done differently. If you are indeed describing an X-Y problem above, then might I suggest the following? Instead of figuring out how to "add" a second password to a user, what about allowing you to login as e.g. "jerry" and then assume the identity of the user "tom"? You should be able to do this by changing the UserPrincipal in the session to have a different username. Which application are you trying to do this with? Your own application, or one which ships with Tomcat (e.g. Manager)? -chris Hi Chris, it's my own webapp. Changing user principal is exactly what I'm trying to do. I wasn't aware that the user principal could be easily swapped. Where can I learn more about how to do that? Chris, I'm not having any luck googling info on how to replace the user principal object in the session object. This is exactly what I need to do. But looks like I'm going to need a little bit of guidance to figure out how to implement it. I forgot that "we" are using our own custom principal and actually not using Tomcat's authentication and authorization. So we do things differently. If you are using FORM authentication, then I think this is a little easier. You may have to do a nasty bit of casting to internal Tomcat classes and/or use reflection, but you can simply call: org.apache.catalina.Session.setPrincipal(java.security.Principal) The StandardSession class you probably are already getting from Tomcat implements that interface, so you should be able to call that. I think while Tomcat will accept any java.security.Principal, in practice, you'll want to use org.apache.catalina.realm.GenericPrincipal. -chris I finally had a minute to try to implement your suggestion from a few weeks ago. I got everything coded. But I'm getting a ClassCastException when trying to retrieve StandardSession. I'm getting a StandardSessionFacade object instead of StandardSession. I looked at the javaDoc hoping to find a way to get the StandardSession from the facade object. But no luck. Am I not going about this correctly in my code? How can get access to the StandardSession object instead of the StandardSessionFacade object? Thx GenericPrincipal newPrincipal = new GenericPrincipal( getUserName(), getPassword(), roles ); ((StandardSession)getCtrl().getRequest().getSession()).setPrincipal( newPrincipal ); Hmm. It seems that StandardSessionFacade is used to prevent the kind of thing you are trying to do, probably as a protection against potentially malicious applications. If you are willing to get messier, you can use reflection to get the value of the StandardSessionFacade.session member, which will be a StandardSession object. Another option is to do what my application does, which is to store the user in a session attribute and then wrap each request in a Filter making it available: doFilter(...) { HttpSession s = request.getSession(false); if(null != s) { final User u = s.getAttribute("user"); if(null != u) { // Wrap request request = new HttpServletRequestWrapper(request) { public Principal getUserPrincipal() { return u; } }; } } chain.doFilter(request, response); } The above is psuedocode ty
Re: [EXT] Datadog _ JMX Integration facing connection issues.
Sai Vamsi, have you answered any of the questions Chris, Chuck and I asked? Tomcat is NOT running, so please check "why" first. We'd like to help, but can't see what is happening on your machine. Kind regards Peter > Am 26.12.2023 um 12:02 schrieb Bodavula, Sai Vamsi Mohan Krishna (TR > Technology) : > > by chance any findings on this., > > Thanks & Regards, > -- > > SAI VAMSI .B > Senior DevOps Engineer > > > From: Bodavula, Sai Vamsi Mohan Krishna (TR Technology) > > Sent: Thursday, December 14, 2023 10:56 > To: Tomcat Users List > Subject: Re: [EXT] Datadog _ JMX Integration facing connection issues. > > Hai Chuck., > Thanks for jumping in., > > thats what my concern is. > as previously added by Chris, I have added my annotations in Catalina_opts ., > Which is preferred by Java_Process for adding the annotations., But Here by > using catalina_opts., they are not reflecting. > > where as adding them in java-tool-options., Makes a process with Tomcat and a > process that listens on the mentioned port., but throws port is already > binded., as its an environment variable, its already looking for a port, > where as its already created., throws binding error. > > Yesterday ., I thought of adding both the formats, adding java_tool_opts and > Catalina opts., inorder to utilize the previous thigns., as below > > - name: JAVA_TOOL_OPTIONS > value: {{ .Values.deployment.javaVMMemoryArgument }} > >- name: POD_IP > valueFrom: >fieldRef: > fieldPath: status.podIP >- name: CATALINA_OPTS > value: >- >-Dcom.sun.management.jmxremote >-Dcom.sun.management.jmxremote.port=49151 >-Djava.rmi.server.hostname=$POD_IP >-Dcom.sun.management.jmxremote.authenticate=false >-Dcom.sun.management.jmxremote.ssl=false >-Dcom.sun.management.jmxremote.local.only=false >-Xms2048M -Xmx10240M > > Java_tool_opts are as : -XX:+UseStringDeduplication -XX:+UseContainerSupport > -Dcom.sun.management.jmxremote > > just added to initiate a JMX process., > > but nothing is working out., > I would like to request you for further inputs > > > cc :chris > > Thanks & Regards, > -- > > SAI VAMSI .B > Senior DevOps Engineer > > > From: Chuck Caldarale > Sent: Thursday, December 14, 2023 00:28 > To: Tomcat Users List > Subject: Re: [EXT] Datadog _ JMX Integration facing connection issues. > > >> On Dec 13, 2023, at 10:36, Bodavula, Sai Vamsi Mohan Krishna (TR Technology) >> wrote: >> >> as you just asked ., >> I do have a process with Catalina. >> >> root@lab1workflow4scalsvc2zus1-deployment-659dd79df7-wg59g:/# netstat -tulpn >> Active Internet connections (only servers) >> Proto Recv-Q Send-Q Local Address Foreign Address State >>PID/Program name >> tcp6 0 0 :::34753:::*LISTEN >>1/java >> tcp6 0 0 :::9109 :::*LISTEN >>1/java >> tcp6 0 0 :::10109:::*LISTEN >>1/java >> root@lab1workflow4scalsvc2zus1-deployment-659dd79df7-wg59g:/# ^C >> root@lab1workflow4scalsvc2zus1-deployment-659dd79df7-wg59g:/# ps aux | grep >> catalina >> root 744 0.0 0.0 6460 680 pts/1S+ 11:47 0:00 grep >> --color=auto catalina >> root@lab1workflow4scalsvc2zus1-deployment-659dd79df7-wg59g:/# > > > That shows only the grep process looking for catalina, not anything using > catalina. If Tomcat were actually running, you’d see something like this > (slightly reformatted for clarity): > > chuck@Chuck-MacBookPro apache-tomcat-9.0.83 > ps aux | grep catalina > chuck16879 0.0 0.0 408626896 1376 s000 S+ 12:53PM > 0:00.00 grep catalina > chuck16874 0.0 0.9 415316912 153296 s000 S12:53PM > 0:02.66 > /Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/Home/bin/java > -Djava.util.logging.config.file=/Users/chuck/Downloads/apache-tomcat-9.0.83/conf/logging.properties > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > -Djdk.tls.ephemeralDHKeySize=2048 > -Djava.protocol.handler.pkgs=org.apache.catalina.webresources > -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 > -Dtest_port=9090 > -Dignore.endorsed.dirs= > -classpath > /Users/chuck/Downloads/apache-tomcat-9.0.83/bin/bootstrap.jar:/Users/chuck/Downloads/apache-tomcat-9.0.83/bin/tomcat-juli.jar > -Dcatalina.base=/Users/chuck/Downloads/apache-tomcat-9.0.83 > -Dcatalina.home=/Users/chuck/Downloads/apache-tomcat-9.0.83 > -Djava.io.tmpdir=/Users/chuck/Downloads/apache-tomcat-9.0.83/temp > org.apache.catalina.startup.Bootstrap > start > > > - Chuck > - To unsubscribe, e-mail:
Re: Admin password for Tomcat
Jerry, On 12/24/23 19:18, Jerry Malcolm wrote: Chris, On 11/8/2023 2:43 PM, Christopher Schultz wrote: Jerry, On 11/6/23 23:22, Jerry Malcolm wrote: On 11/5/2023 11:54 AM, Jerry Malcolm wrote: On 11/5/2023 9:26 AM, Christopher Schultz wrote: Jerry, On 11/4/23 20:17, Jerry Malcolm wrote: My support team needs to be able to log in to our site as various users (on behalf of...) to be able to see exactly what they are seeing since roles, access groups, history is different for different users. I would like to implement an admin password where I can log in as any userId with this password. I totally realize the security risks involved in this. But I am handling the security risks with additional authorizations. I simply need to make every user have two passwords... their real personal password, and the admin password. The only alternative I have right now is to save off the user's password hash in the USERS table, replace it with my password hash, then restore the user's original password when I'm done. I'm not thrilled with that solution first because it's a pain and error prone, and also because the user can no longer log in while their password is replaced with my password. I figure this function is buried in the authenticator code somewhere. But I'd first like to see if anybody has done anything like this already. If not, could somebody point me in the right direction to the tomcat source file that I'm going to need to modify and also what's involved in making authentication use my updated class instead of the default. Suggestions? This sounds like "impersonation" to me, which, I think, can be done differently. If you are indeed describing an X-Y problem above, then might I suggest the following? Instead of figuring out how to "add" a second password to a user, what about allowing you to login as e.g. "jerry" and then assume the identity of the user "tom"? You should be able to do this by changing the UserPrincipal in the session to have a different username. Which application are you trying to do this with? Your own application, or one which ships with Tomcat (e.g. Manager)? -chris Hi Chris, it's my own webapp. Changing user principal is exactly what I'm trying to do. I wasn't aware that the user principal could be easily swapped. Where can I learn more about how to do that? Chris, I'm not having any luck googling info on how to replace the user principal object in the session object. This is exactly what I need to do. But looks like I'm going to need a little bit of guidance to figure out how to implement it. I forgot that "we" are using our own custom principal and actually not using Tomcat's authentication and authorization. So we do things differently. If you are using FORM authentication, then I think this is a little easier. You may have to do a nasty bit of casting to internal Tomcat classes and/or use reflection, but you can simply call: org.apache.catalina.Session.setPrincipal(java.security.Principal) The StandardSession class you probably are already getting from Tomcat implements that interface, so you should be able to call that. I think while Tomcat will accept any java.security.Principal, in practice, you'll want to use org.apache.catalina.realm.GenericPrincipal. -chris I finally had a minute to try to implement your suggestion from a few weeks ago. I got everything coded. But I'm getting a ClassCastException when trying to retrieve StandardSession. I'm getting a StandardSessionFacade object instead of StandardSession. I looked at the javaDoc hoping to find a way to get the StandardSession from the facade object. But no luck. Am I not going about this correctly in my code? How can get access to the StandardSession object instead of the StandardSessionFacade object? Thx GenericPrincipal newPrincipal = new GenericPrincipal( getUserName(), getPassword(), roles ); ((StandardSession)getCtrl().getRequest().getSession()).setPrincipal( newPrincipal ); Hmm. It seems that StandardSessionFacade is used to prevent the kind of thing you are trying to do, probably as a protection against potentially malicious applications. If you are willing to get messier, you can use reflection to get the value of the StandardSessionFacade.session member, which will be a StandardSession object. Another option is to do what my application does, which is to store the user in a session attribute and then wrap each request in a Filter making it available: doFilter(...) { HttpSession s = request.getSession(false); if(null != s) { final User u = s.getAttribute("user"); if(null != u) { // Wrap request request = new HttpServletRequestWrapper(request) { public Principal getUserPrincipal() { return u; } }; } } chain.doFilter(request, response); } The above is psuedocode typed from memory. I'm fairly sure we create a new Principal
Re: need features list that were removed in tomcat 10 while moving from tomcat 9
Rajendra, On 12/22/23 04:31, Rathore, Rajendra wrote: We are migrating from tomcat 9 to tomcat 10, we run the migration tool on our codebase, that work perfectly, can you please share the changes from 9 to 10, we are interested in removed API or features that we can fix manually as migrator tool not take care of such changes. Can you give an example? There are 2 major changes in Tomcat 10 with respect to Tomcat 9 due to the migration from Java EE -> Jakarta EE: 1. All package names have changes usually from javax.* to jakarta.* 2. Old deprecated classes, methods, etc. from the Java EE specs have finally been removed from the APIs The migration tool can help with #1; it's basically a massive recursive search-and-replace for the migrated packages. I would look to see if your application uses any deprecated methods or classes from Java EE and fix those to use their modern equivalents right now, because after migration, they will not work at all if they currently have deprecation warnings. If your application works well on Tomcat 10 using the auto-migration auto-deployment process, then in order to "upgrade" your application from Tomcat 9 to Tomcat 10, you should take (roughly) the following steps: 1. Run the migration tool on your *source code* to replace package names in sources. 2. Note any compiler errors due to libraries that fail to link properly. Search for updated versions of these libraries that support Jakarta EE instead of Java EE and use those. 3. Any libraries with no support for Jakarta EE will have to be manually-migrated using the migration tool on the library *only*. Store those manually-migrated libraries next to your source code for builds and deployments. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [EXT] Datadog _ JMX Integration facing connection issues.
by chance any findings on this., Thanks & Regards, -- SAI VAMSI .B Senior DevOps Engineer From: Bodavula, Sai Vamsi Mohan Krishna (TR Technology) Sent: Thursday, December 14, 2023 10:56 To: Tomcat Users List Subject: Re: [EXT] Datadog _ JMX Integration facing connection issues. Hai Chuck., Thanks for jumping in., thats what my concern is. as previously added by Chris, I have added my annotations in Catalina_opts ., Which is preferred by Java_Process for adding the annotations., But Here by using catalina_opts., they are not reflecting. where as adding them in java-tool-options., Makes a process with Tomcat and a process that listens on the mentioned port., but throws port is already binded., as its an environment variable, its already looking for a port, where as its already created., throws binding error. Yesterday ., I thought of adding both the formats, adding java_tool_opts and Catalina opts., inorder to utilize the previous thigns., as below - name: JAVA_TOOL_OPTIONS value: {{ .Values.deployment.javaVMMemoryArgument }} - name: POD_IP valueFrom: fieldRef: fieldPath: status.podIP - name: CATALINA_OPTS value: >- -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=49151 -Djava.rmi.server.hostname=$POD_IP -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.local.only=false -Xms2048M -Xmx10240M Java_tool_opts are as : -XX:+UseStringDeduplication -XX:+UseContainerSupport -Dcom.sun.management.jmxremote just added to initiate a JMX process., but nothing is working out., I would like to request you for further inputs cc :chris Thanks & Regards, -- SAI VAMSI .B Senior DevOps Engineer From: Chuck Caldarale Sent: Thursday, December 14, 2023 00:28 To: Tomcat Users List Subject: Re: [EXT] Datadog _ JMX Integration facing connection issues. > On Dec 13, 2023, at 10:36, Bodavula, Sai Vamsi Mohan Krishna (TR Technology) > wrote: > > as you just asked ., > I do have a process with Catalina. > > root@lab1workflow4scalsvc2zus1-deployment-659dd79df7-wg59g:/# netstat -tulpn > Active Internet connections (only servers) > Proto Recv-Q Send-Q Local Address Foreign Address State > PID/Program name > tcp6 0 0 :::34753:::*LISTEN > 1/java > tcp6 0 0 :::9109 :::*LISTEN > 1/java > tcp6 0 0 :::10109:::*LISTEN > 1/java > root@lab1workflow4scalsvc2zus1-deployment-659dd79df7-wg59g:/# ^C > root@lab1workflow4scalsvc2zus1-deployment-659dd79df7-wg59g:/# ps aux | grep > catalina > root 744 0.0 0.0 6460 680 pts/1S+ 11:47 0:00 grep > --color=auto catalina > root@lab1workflow4scalsvc2zus1-deployment-659dd79df7-wg59g:/# That shows only the grep process looking for catalina, not anything using catalina. If Tomcat were actually running, you’d see something like this (slightly reformatted for clarity): chuck@Chuck-MacBookPro apache-tomcat-9.0.83 > ps aux | grep catalina chuck16879 0.0 0.0 408626896 1376 s000 S+ 12:53PM 0:00.00 grep catalina chuck16874 0.0 0.9 415316912 153296 s000 S12:53PM 0:02.66 /Library/Java/JavaVirtualMachines/temurin-21.jdk/Contents/Home/bin/java -Djava.util.logging.config.file=/Users/chuck/Downloads/apache-tomcat-9.0.83/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Dtest_port=9090 -Dignore.endorsed.dirs= -classpath /Users/chuck/Downloads/apache-tomcat-9.0.83/bin/bootstrap.jar:/Users/chuck/Downloads/apache-tomcat-9.0.83/bin/tomcat-juli.jar -Dcatalina.base=/Users/chuck/Downloads/apache-tomcat-9.0.83 -Dcatalina.home=/Users/chuck/Downloads/apache-tomcat-9.0.83 -Djava.io.tmpdir=/Users/chuck/Downloads/apache-tomcat-9.0.83/temp org.apache.catalina.startup.Bootstrap start - Chuck