Hi Mark. You were absolutely right about a redirect not being as simple as it sounds. It turns out tomcat is relying on the HTTPSession to store the original request which obviously fails in this case since the HTTPSession is not shared between different web apps. Additionally the Principal, username and password are also stored in the session between the login page submit and redirect to the authenticated target page (in the same web app).
I managed to get a "rough" POC working where before the login redirect a "login token cookie" is set (similar to the sso cookie) and the original request is stored in a Map in the SingleSignOn class with the cookie as a key. Of course this POC needs to be much more tested and polished before it can get submitted. What are my chances to have such a change incorporated in one of the next tomcat releases? Another approach which I haven't tried yet is to open a HttpURLConnection from the FormAuthenticator to the login page instead of a forward or redirect. In this case I'm hoping to be able to use the existing session in the same way as the forward does. Do you have any thoughts on this approach? Sincerely Bernie On Thu, Feb 4, 2016 at 7:15 PM, Bernhard Lenz <bernh...@lenz.name> wrote: > Hi Mark. > > Unfortunately CAS doesn't support Tomcat 8 or 9 and the documentation is > often outdated and sometimes messy. > > I feel Tomcat is so close to perfect with its SingleSignOn valve and > Realms that supporting a global login page is just the dot on the I. > > I'm new to the apache process... How can I best get my hands dirty > and find the edge cases? Would I create a folk in GitHub and in case I get > it to work submit a pull request? > > Sincerely > Bernie > > > On Thu, Feb 4, 2016 at 12:58 PM, Bernhard Lenz <bernh...@lenz.name> wrote: > >> Are there any Tomcat developers in this forum that would like to pick up >> below suggestion? I'm very interesting in hearing your opinion. >> >> Sincerely >> Bernie >> >> On Wed, Jan 27, 2016 at 3:54 PM, Bernhard Lenz <bernh...@lenz.name> >> wrote: >> >>> I'm currently researching an architectural issue which has been >>> pondering me for quite some time now. >>> >>> Tomcat is probably one of the most widely used web servers out there. >>> It has some really nice build in features to implement authentication >>> and authorization using >>> Form Based Authentication and the SingleSignOn valve. Also the database >>> realms with configurable table and column names and hashing of passwords >>> are exactly what is needed to develop state of the art web sites. >>> >>> In my career I've almost exclusively come across (or worked on) web >>> sites which consist of multiple war modules protected by a single site >>> wide login page. Examples are myprofile.war for a customer to update >>> his information, and admin.war for internal users to administer the site, >>> etc etc. All wars are typically protected by a single login page which >>> matches the style of the web page. >>> >>> However it appears that (based on the Servlet Reference Implementation) >>> the login page can only live within each war's servlet context and >>> therefore the login page must be copied into each single war. This makes it >>> kind of hard to maintain the login page, and in case the page needs to be >>> modified it must be changed in multiple places (namely in each war) instead >>> of just in one place. >>> >>> In order to adapt Tomcat better to today's web development practices I >>> would like to suggest an enhancement for Tomcat to provide some kind >>> of host level declaration of a login page which overrides the web.xml >>> definition or takes affect if the login page is not declared inside the >>> web.xmls. For this the FormAuthenticator's forwardToLoginPage method would >>> need to be modified to also offer a (conditional) redirect besides just a >>> forward. In my simple mind such a change shouldn't be too difficult to >>> implement. >>> >>> I also looked at glassfish's clone of Tomcat and saw that the glassfish >>> team did add a redirect to the forwardToLoginPage method, although it >>> appears not exactly for this purpose >>> >>> I'm curious to know your thoughts about this enhancement and how to best >>> proceed with it? >>> >>> Sincerely >>> Bernie >>> >> >> >
