Re: Getting Two times login page issue.
On Thu, Jan 18, 2024 at 8:08 PM Chaudhary, Mohit wrote: > Hello Team , > > We are facing a issue with the tomcat application login URL , where it is > asking twice for login to the user , with first login it will redirect > again to the login page , while reentering the credentials again , it is > successful ( with second attempt it is working ) and user will be > redirected to the next page , this issue we have encountered after a > datacenter migration for the tomcat server on Test region , the servers > were cloned from the original server to the new datacenter servers, we had > manually updated the new IP address on the configuration files related to > new servers , but with testing part we encountering this issue , > > You haven't really indicated how this is a tomcat issue. This sounds like it's either an application issue or a Lotus Domino SSO issue. However I will ask some questions that may point you in the right direction. Is the application dependent on tomcats JSession? If so , when does it determine the userPrincipal? If not then it's an application issue. How is this SSO setup? Header based? cookie based? agent based session? is Tomcat responsible for connecting to the userstore to determine who the user is? This would be done via a realm. > We had 2 servers on Test region which are load balanced where 1 server is > working fine ( with another server shutdown ) , no issue with login page on > this server , while issue happening on another server. > So are you saying it works fine with 1 server and doesn't when 2 are running? Are you sure its not a load balancing issue? How does your application handle sessions? Does it replicate them? Does the application use Affinity to keep the user going to the same server through the LB? > > The application login page resides on the Lotus Domino server and > authentication happens on Domino side and then it redirects the request to > Apache and Tomcat servers . > Please suggest on this issue . > There are a lot of different things that can go wrong here and most of them are not tomcat related. > > Thanks, > Mohit > > -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
Re: EOL - Tomcat versions
https://tomcat.apache.org/whichversion.html 10.0 is EOL but 10.1 is still getting releases. https://tomcat.apache.org/tomcat-10.0-eol.html The official end of life plan for 8.5 https://tomcat.apache.org/tomcat-85-eol.html Basically the final release will be coming out, then it will receive no more fixes. On Mon, Jan 8, 2024 at 1:47 AM i...@flyingfischer.ch wrote: > https://endoflife.date/tomcat > > Am 08.01.24 um 07:39 schrieb Deshmukh, Kedar: > > Hello, > > > > Could you please throw some light on Tomcat versions and its EOL plan? > > > > > >1. 8.5.X > >2. 9.0.X > >3. 10.0.X > >4. 10.1.X > > > > This information would be very critical for us to move forward. > > > > > > Thanks, > > Kedar > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
WebApp Mutual TLS for connecting to thrid party REST service
Is there a way to use JSSE in tomcat to manage TLS mutual auth for when a process in tomcat is acting as a client during a REST call to use a client certificate from a keystore to authenticate to the third party? Or is this something that has to be handled at the application level? I know in Java you can specify these system settings on the commandline. -Djavax.net.ssl.keyStore=/path/to/clientkeystore.p12 \ -Djavax.net.ssl.keyStorePassword=password I was wondering if anyone else has experience with this use case. I want to be clear I am not referring to configuring tomcat to enforce mutual Authn TLS on the connectors. -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
Re: Admin password for Tomcat
You need to build a custom realm for that if you're using tomcat to manage your user sessions and not creating your own sessions for your application. You can extend the existing one that you're using. I assume you're using the JDBC Realm since you said you have an USERS table. So you could add another field to your table and extend the JDBC class to do an additional check on your admin pwd field if you don't want them to have a second account. https://tomcat.apache.org/tomcat-9.0-doc/realm-howto.html#Standard_Realm_Implementations You will want to look at the source of the realm implementation to see how you need to extend it. So you shouldn't have to do too much to get the functionality you're looking for. On Sat, Nov 4, 2023 at 8:18 PM 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? > > Thx > > Jerry > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
Re: AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)
The PKCS12 is the industry standard keystore format. Your mac should be creating it in that version. You should get familiar using the pkcs12. Its not difficult to set it up. keytool and openssl support pkcs12 and have for some time now. Its possible your older keystores are of the storetype JKS or JCEKS, JKS used to be the default I think back in Java 6. Anything newer should throw a warning telling you the industry standard is pkcs12. But you can still open older formats by specifying the "--storetype" option. Your getting that error because you probably didn't tell it what kind it is and its default assumption is wrong. Using a keystore is much better for managing your keys than using PEM files. It's best practice to have seperate stores for keys and for trust. by default java has the "cacerts" file for establishing trust. On Wed, Sep 13, 2023 at 8:16 PM James H. H. Lampert wrote: > Java Keystores work. And I don't find them especially difficult to work > with (other than new formats not being backward-compatible with older > JVMs, and as one who has made a comfortable living banging out code for > IBM Midrange boxes for over a quarter century, I am quite familiar with > a much worse variation on that theme, namely, unless you explicitly set > the TGTRLS parameter (and have the appropriate previous version compiler > installed, and don't need to go back more than it will let you), your > programs will not even *restore* onto a prior release system. > > And the one time I attempted to get anything other than a Java Keystore > to work in Tomcat, on an IBM Midrange box, I failed miserably. > > Putting shell-script wrappers around two different versions of keytool > on my work Mac, so that "keytool" launches the Java 8 version, and > "keytool-default" launches the default version (in the unlikely event > that I'd ever need it) was a relatively simple exercise. > > -- > JHHL > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
Re: Multiple concurrent sessions
Am I understanding your use case right? You need a particular user to have multiple sessions in the same browser? or are you saying you need multiple users to be able to log into your application in the same browser? On Thu, May 25, 2023 at 12:45 PM Stephane Passignat wrote: > Hello, > > I would like to open multiple concurrent session in a web-application > for one user. As far as I understand, the sessionid is stored in the > cookie and the cookie is associated to the server (http://localhost:8080/ > ). > > So if I open a new browser window with the URL, I reach the same page > than the one in the first window, no authentication, ... I can trick > that using a private browse, but it's not convenient. > > Are there any way to have this multiple session per user ? I read a bit > session-config and tracking mode. Is it the right direction ? > > > thanks for your help > > stephane > -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
Re: AW: SSLLabs scan shows TLSv1.0 and TLSv1.1 even though I have sslProtocol="TLSv1.2"
You can disable the protocols at the java level in the java.security file jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, TLSv1, TLSv1.1 On Wed, Aug 10, 2022 at 5:09 AM Thomas Hoffmann (Speed4Trade GmbH) wrote: > Hello Peter, > > > -Ursprüngliche Nachricht- > > Von: logo > > Gesendet: Mittwoch, 10. August 2022 10:22 > > An: Tomcat Users List > > Betreff: Re: AW: SSLLabs scan shows TLSv1.0 and TLSv1.1 even though I > have > > sslProtocol="TLSv1.2" > > > > Thomas, > > > > Am 2022-08-10 08:59, schrieb Thomas Hoffmann (Speed4Trade GmbH): > > > Hello, > > > > > >> -Ursprüngliche Nachricht- > > >> Von: Peter Kreuser > > >> Gesendet: Mittwoch, 10. August 2022 08:44 > > >> An: Tomcat Users List > > >> Betreff: Re: SSLLabs scan shows TLSv1.0 and TLSv1.1 even though I > > >> have sslProtocol="TLSv1.2" > > >> > > >> > > >> > > >> James, > > >> > > >> the most recent connector attribute is "protocols". The documentation > > >> is a bit vague on this saying there is an overlap between the two, > > >> yet I don't know if the overlap is there if protocols is unset and > > >> defaults to "all" > > >> https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support > > >> > > >> Peter > > >> > > >> > Am 10.08.2022 um 00:15 schrieb James H. H. Lampert > > >> : > > >> > > > >> > I think this may have come up before, but I don't recall how it was > > resolved. > > >> > > > >> > On customer box #1, I have: > > >> > > protocol="org.apache.coyote.http11.Http11Protocol" > > >> address="" > > >> > maxThreads="400" SSLEnabled="true" scheme="https" > > secure="true" > > >> > keystoreFile="/tomcat/wttomcat.ks" > > >> keyAlias="" > > >> > > > >> > > ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WI > > >> > > TH_AES_128_GCM_SHA256,SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384" > > >> > clientAuth="false" sslProtocol="TLSv1.2" /> > > >> > > > >> > and an SSLLabs scan shows it accepting only TLSv1.2, as it should. > > >> > > > >> > But on customer box #2, I have: > > >> > > > >> > > protocol="org.apache.coyote.http11.Http11Protocol" > > >> > maxThreads="150" SSLEnabled="true" scheme="https" > > secure="true" > > >> > keystoreFile="/tomcat/wttomcat.ks" > > >> keyAlias="" > > >> > clientAuth="false" sslProtocol="TLSv1.2" /> > > >> > > > >> > and an SSLLabs scan shows it accepting TLSv1.0, TLSv1.1, and > TLSv1.2. > > >> > > > >> > What could be wrong here? I vaguely recall seeing something like > this > > before. > > >> > > > >> > -- > > >> > JHHL > > >> > > > >> > --- > > >> > -- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > >> > For additional commands, e-mail: users-h...@tomcat.apache.org > > >> > > > > > > > I have configured my connector as follows: > > > > > protocol="org.apache.coyote.http11.Http11NioProtocol" > > > > > > > > sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImpleme > > ntation" > > >maxThreads="150" minSpareThreads="25" > > >URIEncoding="UTF-8" useBodyEncodingForURI="false" > > >enableLookups="false" disableUploadTimeout="true" > > >acceptCount="100" scheme="https" secure="true" > > >SSLEnabled="true" > > > compression="off" > > > > > /> > > > > > ciphers="ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM- > > SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM- > > SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20- > > POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384" > > > disableSessionTickets="true" > > honorCipherOrder="false" > > > protocols="+TLSv1.2,+TLSv1.3"> > > > > > certificateFile="../xx.pem" type="RSA" /> > > > > > > > > > > > > This gives a good grade when checking with ssllabs. > > > Only TLS 1.2 and 1.3 are enabled. > > > > > > > of course SSLHostConfig is the modern and preferred way. But unless you > have > > plenty of time, it's a hassle to migrate many boxes to the new way... > > > > Peter > > > > > Greetins, Thomas > > > > > The attributes are quite similar or the same, just located at other > xml-elements, so you can still use the attributes like "protocols" or > "ciphers". > Just located at different tags. > > Sooner or later the old syntax will get deprecated. So it's usually a > matter of time when you have the hassle ;) > > Greetings, Thomas > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
Re: Tomcat is hanging up when I try to access local host:8080
netstat -plunet will show you what ports are in use and what processes are using them On Thu, Jan 27, 2022 at 11:43 AM Neil Aggarwal wrote: > Jim: > > > java.net.BindException: Address already in use > > This means there is some other process which has already > grabbed port 8080 so your Tomcat can't get it. > > Make sure you have nothing else running that will compete > for the port. > > Thank you, > Neil > > -- > Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com > We offer 30 year loans on single family houses! > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
Re: Performance Tuning Tomcat 9
There are a number of tools out there that can load test your site. Most companies use something like loadrunner, jmeter, or https://gatling.io. I personally use jmeter due to licensing and ease of use. On Thu, Jan 13, 2022 at 11:17 AM Campbell, Lance wrote: > For Tomcat 9.x is there a particular website you have found to be helpful > for performance tuning Tomcat 9? > > Thanks, > > Lance > -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
Re: When does tomcat 7.0.76 determine it needs to redeploy the war file?
Thx mark. that was helpful On Mon, Jul 12, 2021 at 2:38 PM Mark Thomas wrote: > On 12/07/2021 19:21, Brian Wolfe wrote: > > Hi, > > As the subject asks, when does tomcat decide that it needs to redeploy > the > > war file? I know the usual one where the app folder does not exist. > > > > Basically I have an app where some changes were made to the webapp > folder, > > but were not made in the accompanied war file. Then we updated the > web.xml > > and restarted tomcat. some of those changes were overwritten with older > > versions. So we think tomcat may have redeployed on startup. > > http://tomcat.apache.org/tomcat-7.0-doc/config/automatic-deployment.html > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
When does tomcat 7.0.76 determine it needs to redeploy the war file?
Hi, As the subject asks, when does tomcat decide that it needs to redeploy the war file? I know the usual one where the app folder does not exist. Basically I have an app where some changes were made to the webapp folder, but were not made in the accompanied war file. Then we updated the web.xml and restarted tomcat. some of those changes were overwritten with older versions. So we think tomcat may have redeployed on startup. -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
Re: 500 instances of tomcat on the same server
I tend to agree with the initial assessment from Mark, your only issue would be on the OS level. # of file descriptors for connections. That many tomcat servers and your gonna start using a lot of ports and push the OS limits on file read/write capabilities. >From an architecture perspective you should probably work on moving to a more modern deployment model of containerization of these apps. You would be better served by containerizing each customer deployment and running them on a kubernetes cluster. you can avoid the need for having large machines and scale more appropriately. and moving between hardware would be as simple as adding/removing nodes to your cluster. It sounds like the apps must be simple to be able to scale it to different clients like that. just my 2 cents. On Mon, Jun 28, 2021 at 1:12 PM Eric Robinson wrote: > > > > > > -Original Message- > > From: Mark Thomas > > Sent: Monday, June 28, 2021 9:04 AM > > To: users@tomcat.apache.org > > Subject: Re: 500 instances of tomcat on the same server > > > > On 28/06/2021 14:53, Christopher Schultz wrote: > > > Eric, > > > > > > On 6/25/21 22:58, Eric Robinson wrote: > > >> We can run 75 to 125 instances of tomcat on a single Linux server > > >> with > > >> 12 cores and 128GB RAM. It works great. CPU is around 25%, our JVMs > > >> are not throwing OOMEs, iowait is minimal, and network traffic is > > >> about 30Mbps. We're happy with the results. > > >> > > >> Now we're upping the ante. We have a 48-core server with 1TB RAM, and > > >> we're planning to run 600+ tomcat instances on it simultaneously. > > >> What caveats or pitfalls should we watch out for? Are there any hard > > >> limits that would prevent this from working as expected? > > > If you have the resources, I see no reason why this would present any > > > problems. > > > > > > On the other hand, what happens when you need to upgrade the OS on > > > this beast? You are now talking about disturbing not 72-125 clients, > > > but 600 of them. > > > > > > If I had a beast like this, I'd run VMWare (or similar) on it, carve > > > it up into virtual machines, and run fewer clients on each just > > > for the sheer flexibility of it. > > That just moves the goal posts. You'll have the same issue when the > > hypervisor needs updating (which admittedly may need a reboot less often > > than the OS). > > > > > If this is already a virtualized/cloud environment, then I think > > > you're doing it wrong: don't provision one huge instance and use it > > > for multiple clients. Instead, provision lots of small instances and > > > use them for fewer (or even 1) at a time. > > > > But it adds the overhead of an OS for each instance. And costs if you > have to > > pay for that OS instance. > > > > The overhead issue is an important factor. The other is the fact that it's > a canned app, supported by the publisher, and doing it our way pays big > dividends in terms of that workflow. > > > As always there are trade-offs to be made and the "right" answer will > vary > > based on circumstances and what you are trying to optimize for. I do > agree > > that, generally, more smaller instances will be a closer fit to more use > cases > > but that is only a general answer. > > > > Generally, I'd agree too. We are considering using containers, but I'm not > yet sure what that buys us in terms of stability. > > > Mark > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > Disclaimer : This email and any files transmitted with it are confidential > and intended solely for intended recipients. If you are not the named > addressee you should not disseminate, distribute, copy or alter this email. > Any views or opinions presented in this email are solely those of the > author and might not represent those of Physician Select Management. > Warning: Although Physician Select Management has taken reasonable > precautions to ensure no viruses are present in this email, the company > cannot accept responsibility for any loss or damage arising from the use of > this email or attachments. > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
Re: Again with the missing headers
So i'm not too familiar with tomcat 9. However, I did notice that maxHttpHeaderSize default is supposed to be 8KB in 9. That is set on the connector. Which affects both request and response headers. https://tomcat.apache.org/tomcat-9.0-doc/config/http.html Did you try that? If i'm not mistaken about a stream of content. the response headers should be the first thing that is received by the client. Then the body can be split and transmitted along the connection. On Sat, Apr 10, 2021 at 10:06 PM Rob Sargent wrote: > I saw this mentioned a couple years ago, on tomcat 7, but don't see > anything recent on this topic and I'm using 9.0.43. Of 59 separate > requests to same servlet three repeatedly do not have the header entry > added by the servlet to the response. The remaining 56 all have the > header/value. The three consistently lose the header. > > Size matters? The 56 which succeed are on average 203 units in payload > size while the bad boys are 7K,10K,13K units. (And I'm guessing about > 100 bytes per unit) > > The clients streams the payload from the response, and I've tried > getting the header both before and after the stream has been read. > > Any clues as to where the missing header goes? Does the servlet not > send it or is it in some /other/ response? > > Thanks, > rjs > > -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
Re: JNDI ldaps Problem with SSO
Seems there might be some debug you can turn on. I haven't tried it myself. But Look at this for reference. https://ldapwiki.com/wiki/Tomcat%20And%20LDAP On Thu, Feb 25, 2021 at 11:18 AM wrote: > Dear Brian > > Thank you for your reply > > We can see the successful handshake with the LDAP Server. > We think, after that, some more data goes back and forth and then the > connection is closed. We can't see, what is exactly happening - its TLSv1.3 > When using ldap with port 3268 - its all good. > So the search itself seems to be fine. > > Only ldaps with port 3269 fails > > Is there maybe another debug Option for the ldap? > > Thank you > > Susan > > > > > -Original Message- > > From: Brian Wolfe > > Sent: Donnerstag, 25. Februar 2021 17:00 > > To: Tomcat Users List > > Subject: Re: JNDI ldaps Problem with SSO > > > > if you define the truststore on the command line it will ignore the > cacerts file. > > Also looks like you're trying to connect to AD over the catalog port. > > I would suggest using the LDAPS port 636. The GC port is used to search > > things within the forest that may not be in the domain. small change but > > shouldn't cause a connection issue if you're using the catalog port. > > > > You shouldn't have to configure any additional SSL stuff on the realm. > As long > > as your JNDI url is ldaps it should know to use SSL. Java will negotiate > the SSL > > for you. > > > > One thing you can do is turn on SSL debug and look at the negotiation to > see > > if it is negotiating SSL. > > *-Djavax.net.debug=ssl* > > You should see it negotiate with the ldap server on startup. You will > also be > > able to see the whole SSL handshake and see if it's failing. > > > > On Thu, Feb 25, 2021 at 10:35 AM wrote: > > > > > Hi Bill > > > > > > Thank you for your fast reply > > > > > > We are using RHEL7 > > > > > > The JAVA is using it's default cacerts which includes all ROOT CA's of > > > the LDAP Server. > > > We also added another Trusstore in the JAVA OPTS of the Tomcat JVM, > > > which also includes the whole chain of the LDAP Server Cert: > > > > > > tomcat 21503 1 2 Feb16 ?05:32:41 > /usr/java/latest/bin/java > > > -Djava.util.logging.config.file=/opt/tomcat/tomcat8_app1/conf/logging. > > > properties > > > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > > > -Djavax.net.ssl.trustStore=/etc/pki/tls/certs/RootCore.jks > > > -Djavax.net.ssl.trustStorePassword=xxx > > > -Djdk.tls.ephemeralDHKeySize=2048 -Xmx12G -XX:+UseThreadPriorities > > > -Dnm.data.home=/opt/tomcat/data > > > -Djava.security.auth.login.config=/opt/tomcat/data/conf/jaas.conf > > > -Djava.security.krb5.conf=/opt/tomcat/tomcat8_app1/conf/krb5.conf > > > -Djavax.security.auth.useSubjectCredsOnly=false > > > -Dsun.security.krb5.debug=false -Duser.timezone=Europe/Berlin > > > -Djava.endorsed.dirs=/opt/tomcat/apache-tomcat-8.0.36/endorsed > > > -classpath > > > /opt/tomcat/apache-tomcat- > > 8.0.36/bin/bootstrap.jar:/opt/tomcat/apache- > > > tomcat-8.0.36/bin/tomcat-juli.jar > > > -Dcatalina.base=/opt/tomcat/tomcat8_appway1 > > > -Dcatalina.home=/opt/tomcat/apache-tomcat-8.0.36 > > > -Djava.io.tmpdir=/opt/tomcat/tomcat8_appway1/temp > > > org.apache.catalina.startup.Bootstrap start > > > > > > Our server.xml only contains the ldap realm and database realm. > > > Could it be, that a ssl config is necessary too? > > > > > > Thank you > > > > > > Susan > > > > > > > -Original Message- > > > > From: Bill Stewart > > > > Sent: Donnerstag, 25. Februar 2021 16:04 > > > > To: Tomcat Users List > > > > Subject: Re: JNDI ldaps Problem with SSO > > > > > > > > On Thu, Feb 25, 2021 at 2:31 AM wrote: > > > > > > > > We are having a problem with our Single sign On config. > > > > > When using ldap - all works well. > > > > > > > > > > When switiching to ldaps , the User loses to connection all > > > > > together (Server not reachable) > > > > > > > > > > server.xml > > > > > > > > > > Good: > > > > > > > > >connectionURL="ldap://x..com:3268; > > > > >userBase="DC=XXXINTRA,DC=CH"
Re: JNDI ldaps Problem with SSO
if you define the truststore on the command line it will ignore the cacerts
file. Also looks like you're trying to connect to AD over the catalog port.
I would suggest using the LDAPS port 636. The GC port is used to search
things within the forest that may not be in the domain. small change but
shouldn't cause a connection issue if you're using the catalog port.
You shouldn't have to configure any additional SSL stuff on the realm. As
long as your JNDI url is ldaps it should know to use SSL. Java will
negotiate the SSL for you.
One thing you can do is turn on SSL debug and look at the negotiation to
see if it is negotiating SSL.
*-Djavax.net.debug=ssl*
You should see it negotiate with the ldap server on startup. You will also
be able to see the whole SSL handshake and see if it's failing.
On Thu, Feb 25, 2021 at 10:35 AM wrote:
> Hi Bill
>
> Thank you for your fast reply
>
> We are using RHEL7
>
> The JAVA is using it's default cacerts which includes all ROOT CA's of the
> LDAP Server.
> We also added another Trusstore in the JAVA OPTS of the Tomcat JVM, which
> also includes the whole chain of the LDAP Server Cert:
>
> tomcat 21503 1 2 Feb16 ?05:32:41 /usr/java/latest/bin/java
> -Djava.util.logging.config.file=/opt/tomcat/tomcat8_app1/conf/logging.properties
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> -Djavax.net.ssl.trustStore=/etc/pki/tls/certs/RootCore.jks
> -Djavax.net.ssl.trustStorePassword=xxx
> -Djdk.tls.ephemeralDHKeySize=2048 -Xmx12G -XX:+UseThreadPriorities
> -Dnm.data.home=/opt/tomcat/data
> -Djava.security.auth.login.config=/opt/tomcat/data/conf/jaas.conf
> -Djava.security.krb5.conf=/opt/tomcat/tomcat8_app1/conf/krb5.conf
> -Djavax.security.auth.useSubjectCredsOnly=false
> -Dsun.security.krb5.debug=false -Duser.timezone=Europe/Berlin
> -Djava.endorsed.dirs=/opt/tomcat/apache-tomcat-8.0.36/endorsed -classpath
> /opt/tomcat/apache-tomcat-8.0.36/bin/bootstrap.jar:/opt/tomcat/apache-tomcat-8.0.36/bin/tomcat-juli.jar
> -Dcatalina.base=/opt/tomcat/tomcat8_appway1
> -Dcatalina.home=/opt/tomcat/apache-tomcat-8.0.36
> -Djava.io.tmpdir=/opt/tomcat/tomcat8_appway1/temp
> org.apache.catalina.startup.Bootstrap start
>
> Our server.xml only contains the ldap realm and database realm.
> Could it be, that a ssl config is necessary too?
>
> Thank you
>
> Susan
>
> > -Original Message-
> > From: Bill Stewart
> > Sent: Donnerstag, 25. Februar 2021 16:04
> > To: Tomcat Users List
> > Subject: Re: JNDI ldaps Problem with SSO
> >
> > On Thu, Feb 25, 2021 at 2:31 AM wrote:
> >
> > We are having a problem with our Single sign On config.
> > > When using ldap - all works well.
> > >
> > > When switiching to ldaps , the User loses to connection all together
> > > (Server not reachable)
> > >
> > > server.xml
> > >
> > > Good:
> > > > >connectionURL="ldap://x..com:3268;
> > >userBase="DC=XXXINTRA,DC=CH"
> > >userSubtree="true"
> > >userSearch="(sAMAccountName={0})"
> > >userRoleName="memberOf"
> > >
> > >
> > > roleBase="OU=PF00_App-
> > Access,OU=PF00_App,OU=PF00_Server,OU=PF00_Res,OU
> > > =PF00,DC=XXXINTRA,DC=ch
> > > "
> > >roleName="CN"
> > >roleSearch="(member:1.2.840.113556.1.4.1941:={0})"
> > >roleSubtree="true"
> > >roleNested="true" />
> > >
> > > bad:
> > >
> > > > >connectionURL="ldaps://x..com:3269"
> > >userBase="DC=XXXINTRA,DC=CH"
> > >userSubtree="true"
> > >userSearch="(sAMAccountName={0})"
> > >userRoleName="memberOf"
> > >
> > > roleBase="OU=PF00_App-
> > Access,OU=PF00_App,OU=PF00_Server,OU=PF00_Res,OU=PF00,DC=XXXINT
> > RA,DC=ch"
> > >roleName="CN"
> > >roleSearch="(member:1.2.840.113556.1.4.1941:={0})"
> > >roleSubtree="true"
> > >roleNested="true" />
> > >
> >
> > If you are running Tomcat on Windows, my question is whether the Java
> > running your Tomcat server trusts the Windows certificate store for the
> > secure LDAP.
> >
> > If you are running Tomcat on Windows, try adding the following parameter
> to
> > the Java command line for your application:
> >
> > -Djavax.net.ssl.trustStoreType=WINDOWS-ROOT
> >
> > (If you are using procrun which is likely on Windows, this means to go
> to the
> > "Java" tab for the Tomcat service configuration and add the above line
> to the
> > "Java Options" text box.)
> >
> > Bill
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
--
Thanks,
Brian Wolfe
https://www.linkedin.com/in/brian-wolfe-3136425a/
Re: Out of memory exception
ing list because I was responsible for > > Tomcat servers running apps developed in-house, and every once in a > > while, I needed to ask something tomcat-specific. > > > > Thanks, > > Shawn > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
Re: Tomcat SSO valve implementation
Most apps I have seen implement it themselves using a SAML framework like spring. usually they build the functionality into their App. I suppose you could build a tomcat implementation, Tomcat supports J2EE so you could leverage those mechanisms to get the tomcat session. I don't think there is anything OOTB for tomcat SAML. Essentially you need to create a couple endpoints, One for SAML metadata retrieval/generation and one for parsing an incoming SAML assertion. assuming your providing a service with your App. You would also want a logout endpoint. You will also need to figure out login as your App needs to redirect to the IDP in the event an user does not have a session. Some SPs have a local login and IDP login. So you would have to implement that. in my quick google searching there seems to be a tool called PicketLink that might do some of this for you. This seems to be a decent write up although I haven't used it. https://dzone.com/articles/saml-single-sign-on-with-tomcat-and-picketlink On Tue, Dec 22, 2020 at 12:04 PM Steve Sanders wrote: > Just to add on to the options already listed (which I'm sure work just > great!), we used openSAML and wrote our own valve fairly painlessly and > have been having really good success with it. > > Steve Sanders > > On Mon, Dec 21, 2020 at 1:17 PM George Stanchev < > george.stanc...@microfocus.com> wrote: > > > We use spring-security-saml for application-level SP implementation and > it > > works pretty good too. The project is in the process of being rewritten > > from scratch though with 2.0 in milestone builds. No direct integration > > with Tomcat though but on application level. > > > > George > > > > -Original Message- > > From: André Warnier (tomcat/perl) > > Sent: Thursday, December 17, 2020 8:42 AM > > To: users@tomcat.apache.org > > Subject: Re: Tomcat SSO valve implementation > > > > On 16.12.2020 19:39, Kevin Oxley wrote: > > > We are trying to support SSO SAML 2.0 for user authentication in Tomcat > > > (9.0.22). Can anybody provide a reference to a pre-integrated SAML > SSO > > > valve implementation that you've had a good experience with? > > > > > > > searching Google for "SAML SP for servlet engine" gives a few links, > among > > them this one : > > > https://dzone.com/articles/saml-single-sign-on-with-tomcat-and-picketlink > > > > I haven't tried it myself. In my cases, I always use an Apache httpd > > front-end, which does the authentication prior to proxying to a back-end > > tomcat (with the Connector attribute ' > > tomcatAuthentication="false" '). In the front-end Apache2 httpd then, we > > use Shibboleth as the SAML SP side. > > That works perfectly. > > > > ----- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
Re: ANN: Bill Stewart's Apache Tomcat Setup for Windows [9.0.40]
Rob, It looks like this installer is specific to windows and from a brief glance at documentation it mostly helps setting it up as a windows service and helps with upgrades. As far as linux distributions go installation and upgrade via the rpm packages should take care of most of that. At least setting up the systemctl services and the user/groups necessary for it to run. I'm not sure I see a need for something similar for linux. Anything more would be specific to your use case. On Tue, Dec 1, 2020 at 6:08 PM Rob Sargent wrote: > Is there something similar for embedded tomcat on linux? > > On 12/1/20 3:58 PM, Bill Stewart wrote: > > Documentation and installer source: > > > > https://github.com/Bill-Stewart/ApacheTomcatSetup > > > > Download installer: > > > > https://github.com/Bill-Stewart/ApacheTomcatSetup/releases > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
