It is more curiosity now on my part, but I have a couple of questions :
Where does this SSO third-party app actually "live" ? Is it on another webserver which
acts as a proxy to your Tomcat ? Or inside of Tomcat itself ?
And you mention that you are supplied a token; how ? Is it in the form of a HTTP header
added to the request ? or does the third-party app actually fill-in the login form ?
Or does it add a query-string parameter with this token ?
Pid * wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
