On 28 Jan 2011, at 18:53, "beau.hutche...@thomsonreuters.com" <beau.hutche...@thomsonreuters.com> wrote:
> @Pid: The SSo third party app knows the SSO entry point into my Tomcat app. I > am supplied an encrypted token which contains the username and my tomcat app > has the libraries to unencrypt that token and unveil the username If you're using Tomcat 6 the only safe* way to do this is to implement JAAS. It's a bit of a hassle but the result will be worth it. p *IMHO > @Andre: Ideally it would seem most convenient to access j_security_check with > a valid j_username and a j_password with a blank value, so then the tomcat > container would generate the proper principal and roles information. > I want to be able to use request.getRemoteUser() and > request.isUserInRole(String role). > > It would seem that I can extend AuthenticatorBase and mimic everything that > FormAuthenticator does except for the password query part. > > Or I can use a hack for the DataSourceRealm and use my "UserName" column for > both the userCredCol and userNameCol values. Therefore no password to check > for. > > Beau > > -----Original Message----- > From: André Warnier [mailto:a...@ice-sa.com] > Sent: Friday, January 28, 2011 6:36 AM > To: Tomcat Users List > Subject: Re: Pid OpenSSO request for Tomcat Form Authentication that requires > no password for third party SSO > > Pid wrote: >> On 1/27/11 3:57 PM, beau.hutche...@thomsonreuters.com wrote: >>> Chris: >>> Thanks for your reply. >>> Currently I am using Tomcat 6.0.29 >>> >>> @Pid: Would you have any ideas on how to set something up like this? >> >> What details are you providing to Tomcat? >> >> If I read the thread correctly you've got a single parameter - how are >> you validating that to stop say, me, guessing at logins? >> > > That's easy, as long as Tomcat accepts only connections from a source known > to go through > the aforementioned SSO. > > I have a similar setup at one of my customers. This is only an example : > All users use a session on a specific Windows Terminal Server. In that > session, they open > a browser, which allows them to connect to Tomcat (*). > Tomcat accepts only connections from the IP's of the Terminal Server. > On the Terminal Server runs that nifty SSO mechanism which I mentioned in > another message > here. Somehow, that SSO "detects" the login page which the Tomcat > authentication is > sending back to the browser, fills-in the userid (**), and re-posts the login > form to the > server. > The user is now logged-in and gets the application page. > The user does not see anything. > > I know that it sounds a bit strange when one explains it like that, but it > works. > > (**) the user-id being sent is the user's Windows Domain user-id, which has > already been > authenticated/verified, so it can be "trusted". There is thus no need to > verify it again > in Tomcat. > > (*) Ok, I'm cheating : in my case, it is not Tomcat directly, but it is an > Apache httpd > front-ending for Tomcat, and connecting to it via mod_jk. mod_jk will pass > on the > httpd-level user-id, and Tomcat (with the 'tomcatAuthentication="false" > attribute on the > AJP Connector), will accept that user-id as its own. > At the Tomcat level, you would still have to do the "isUserInRole" part > though. > > Now the question is : assuming that there is no httpd front-end and no > mod_jk, can a > similar mechanism work with Tomcat directly ? > In other words, can the standard Tomcat form-based authentication work, if > the login form > is sent back with a non-blank userid, but with a blank password ? > And could this authentication code be easily "tweaked" to bypass any > verification of the > received user-id ? > > And, to the original poster : apologies for somewhat hijacking your thread, > but I am just > trying to help finding the best method for you. > > I have a feeling that for this case, having to create a brand-new > Authenticator is a bit > heavy as a solution. It seems that it should be possible to at least crate > some "null > Realm" which always accepts any user-id and always returns OK. > Or use whatever mechanism mod_jk is using to the same basic effect. > > > > > > > --------------------------------------------------------------------- > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
