[Java EE] record a pit where SSO is not working properly under the reverse proxy

Well... Really is a long time did not update, feel a little bottleneck, learn and learn not to go on, work to use things and no difficulty, job-hopping and no experience not the key is not blowing is also embarrassing ...

Inadvertently turned to this blog, but also a long time not updated suddenly thought of this thing, just send a recently done gadget good

Mainly in a system, where customers do not want to provide multi-port, but to deploy multiple applications and single sign-on, so it is natural to use the reverse proxy, and then the company's internal SSO client to the pit ...

SSO single point of landing the general idea should be this:

Redirect to a single sign-on server, server login successfully jumped back and brought the identity of the project two times to the single sign-on server check the identity and retrieve the login information, set the login status

Originally is a very simple thing, the company has done before also encapsulated a Ssoclient.jar package, as long as the filter to inherit a successful landing callback class can be, use it simple rough, but very subtle is the first step on the problem .... Before the company wrote Ssoclient.jar in the first step, not logged in when the filter redirects to a single point of landing, and the single-point login system requires an address parameter for the login to jump back, but the jar inside the code is written dead, through request to get the current server protocol, address, Port, After stitching redirects the past

However, this creates a problem, in reverse proxy environment, request to get the data is the reverse proxy internal intranet IP and port, not the external network IP and port, the result is a single sign-on system can not jump back, the corresponding or struts2 configuration redirection, there are the same problem, And look at the next ssoclient and no code, decompile and build the development environment to compile back, too troublesome

Search, one solution is to synchronize configuration on both sides, nginx configuration to forward the real IP and port, tomcat through the plug-in read and set to request

But obviously, the problem can be solved by configuration .... Not good enough to play .... Like to do things, I'm really going to go on with things.

In fact, the idea is the same as the solution described above, the use of the Tomcat plugin to configure the real address to the request is not universal (other container configuration is not the same), and the core idea is to tamper with the request getserverport and other methods to return to the real network address, Rather than the reverse proxy internal address

Then the question becomes how to tamper with the request, it is obvious that the servlet specification does not provide such a function, so I thought ... You can do things with filter, if my filter is the first to operate the filter, and provide a false request and reponse to the subsequent filter operation, whether it is struts2 or ssoclient, They got the request and the response that I built, not the original.

With this idea is good to do, the definition of two request and response forwarding class, the majority of real-world methods to forward, need to tamper with the method to return the configuration file configuration data, Then regenerate the address for the 302 redirect (the original relative address will go wrong if it is returned by a container completion path such as Tomcat, and the path will be added to the intranet address of the reverse proxy), and then it's done.

Try the effect is very good, the perfect cheat ssoclient and struts2, code runs very normal, so far have not encountered any bug

Code Address: Https://coding.net/u/pppploi8/p/MyUtils/git/tree/master/Java/RProxyFilter

It's also a good place to hang out on your own tool-like project. By the way, see if anyone else has visited this blog 2333333

Anyway, I'm still trying to make a mistake. A set of general parameters Check Tool class before and after, and so on.

[Java EE] record a pit where SSO is not working properly under the reverse proxy