You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by lightbulb432 <ve...@hotmail.com> on 2007/08/30 02:24:34 UTC
Re: Single-sign on without form-based authentication
Here's the case where three credentials are necessary: there is a requirement
to host multiple applications on a single database, and data such as users
are in a single, shared table. Therefore, someone logging into app A would
enter username and password of user1 and pass1, and someone else logging
into app B could also enter username as password user1 and pass1, but still
be two separate entities.
In the single database, the authentication table would have [User,Pass,App]
as (user1,pass1,A), and (user1,pass1,B), which are two different and
unrelated records.
So even though the users are only entering two credentials into their
respective applications' user interfaces, the application itself
authenticates with Tomcat using three credentials. How could I make this
work?
The requirement doesn't accept having two tables (i.e. userTableA and
userTableB), partly because increased maintenance, the possibility of table
definitions going out of sync, etc.
Thanks.
Gregor Schneider wrote:
> however, i do not see any sense at all passing more tha two
> credentials (user, pass) to authenticate....
>
> therefore, i suggest first thing you should do is to re-think the
> design of your application.
--
View this message in context: http://www.nabble.com/Single-sign-on-without-form-based-authentication-tf3805975.html#a12374143
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Single-sign on without form-based authentication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lb,
lightbulb432 wrote:
> Anytime I want to use more than two credentials, I have to provide my
> own Realm implementation. But the only time I need to do the String
> concatentation is when at least one of the additional credentials
> (i.e. beyond username and password) is provided at request-time by
> the user, rather than at deployment-time?
Well, I think that if you are going to do your own Realm implementation,
you're better off with my (long) suggestion from my previous post. The
concatenation thing basically doesn't work... there's no way (unless you
use javascript... <shudder>) to concatenate that information before the
authenticator gets its hands on the credentials.
> So for the example you gave with the "appId" property on my Realm
> implementation, I wouldn't need to do String concatentation because
> the user is only providing two credentials?
Correct. The big problem with the Realm interface is that it doesn't
accept an HttpServletRequest object... you only have access to the
information that Tomcat wants you to have (like the username and
password, and some other stuff like the message digest to use... MAYBE).
Like I said, the Realm interface is a bit baffling.
> But if the user were specifying what application they wanted to log
> into, then I'd have to concatenate that before passing to the
> authenticate method because Realm hasn't been instantiated with that
> information?
Er, yeah, but I have no idea how you'd do that. When you write your own
Realm, you're still just getting the information Tomcat is willing to
supply. If you want to pass more arguments, I think you're talking about
replacing the authentication Valve at that point. Good luck! ;)
> If your HTML form has a "j_username", "j_password" and
> "myThirdCredential", where would you concatenate j_password and
> myThirdCredential?
I dunno. The plan goes like this:
1. Add the 3rd credential to your login form.
2. ???
3. Profit.
> I'm guessing you'd also have to override the servlet pointed to by
> j_security_check - if I'm correct, how would you override this?
You basically can't.
> (My guess is the servlet class pointed to by the text
> "j_security_check" is hardcoded somewhere within Tomcat?)
I don't think it's a servlet... I think it's a Valve that intercepts
requests to /j_security_check when applying authentication and
authorization is appropriate for a particular (previously-requested) URL.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG1y949CaO5/Lv0PARAhNbAKClocjf0+BChThtUij5UJFtU5wfxgCgw8x4
zAjGdSYzjSJS2ShblnECih4=
=3r7s
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Single-sign on without form-based authentication
Posted by lightbulb432 <ve...@hotmail.com>.
Wow, those are good suggestions. I was thinking about the String
concatenation, but didn't think it was worth considering further until you
just mentioned it. So let me see if I have this straight:
Anytime I want to use more than two credentials, I have to provide my own
Realm implementation. But the only time I need to do the String
concatentation is when at least one of the additional credentials (i.e.
beyond username and password) is provided at request-time by the user,
rather than at deployment-time?
So for the example you gave with the "appId" property on my Realm
implementation, I wouldn't need to do String concatentation because the user
is only providing two credentials? But if the user were specifying what
application they wanted to log into, then I'd have to concatenate that
before passing to the authenticate method because Realm hasn't been
instantiated with that information?
If your HTML form has a "j_username", "j_password" and "myThirdCredential",
where would you concatenate j_password and myThirdCredential? I'm guessing
you'd also have to override the servlet pointed to by j_security_check - if
I'm correct, how would you override this? (My guess is the servlet class
pointed to by the text "j_security_check" is hardcoded somewhere within
Tomcat?)
Christopher Schultz-2 wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Lb,
>
> lightbulb432 wrote:
>> Views would definitely allow me to keep the two tables separate, but then
>> I'd
>> have to authenticate against the two source tables separately (i.e. each
>> application would point to the source table rather than to the view). If
>> pointing both applications to the common view, then doesn't the original
>> problem exist?
>
> Don't do that. Create separate views for each of your applications, and
> use the app-appropriate view for authentication.
>
> If you think this sounds like too much trouble, you're right. Just
> remember that Tomcat implements the simplest thing that could possibly
> work wrt authentication. If you don't like it, you can always override
> the authentication mechanism with something else (securityfilter!) or
> hand-roll your own realm.
>
>> I took a look at JAASRealm and its authenticate method only takes two
>> parameters (username and "credentials", which is really just a single
>> password string).
>>
>>> Is it possible to pass my other credentials to the JAASRealm so that I
>>> can
>>> pass everything at one time (username, password, other credentials) to
>>> the
>>> stored procedure, rather than - if I've interepreted this correctly -
>>> authenticating once through the JAAS username/password, then again
>>> through
>>> my stored procedure to "cancel out" the previous authentication.
>
> Uh, you could always pass a concatenated "credential" which includes
> more than just the password. For instance:
>
> JAASRealm.authenticate(username, appId + ":" + hash(password));
>
> Then, in your stored procedure, tear apart the "credential" and use part
> of it as the app identifier. Or, put the appId into the username.
> Whatever you want to do. There are lots of options.
>
>> So if not JAASRealm, perhaps I need to look at something else to
>> customize?
>> I could of course implement my own authentication, but if I can get
>> around
>> this one shortcoming of the "credentials" concept being considered a
>> password String rather than a generic Collection of multiple Objects,
>> then I
>> think I might be able to use Tomcat authentication.
>
> You can still use Tomcat's authentication "mechanism"... you just might
> have to use your own Realm implementation. Frankly, the
> org.apache.catalina.Realm interface is baffling to me.
>
> One option is to create a Realm that extends JDBCRealm (or, better yet,
> DataSourceRealm) and override the authentication method to do your own
> SQL queries, but keep all the configuration options provided by the
> superclass. You can even add a configuration option by adding a mutator
> and accessor to specify the app's id. Then you can do something like
> this in your context.xml:
>
> <Realm className="package.to.your.Realm" // extends JDBCRealm
> driverName="org.gjt.mm.mysql.Driver"
> connectionURL="jdbc:mysql://localhost/authority"
> connectionName="test"
> connectionPassword="test"
> userTable="users"
> userNameCol="user_name"
> userCredCol="user_pass"
> userRoleTable="user_roles"
> roleNameCol="role_name"
> appId="application-1" />
>
> Just make sure you have setAppId and getAppId methods on your Realm
> implementation, and then use them when you build your SQL query to
> verify a login.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFG1wuQ9CaO5/Lv0PARAh6IAKCIY9aMp59xFxXHIj9z4eCfF+SYngCeMfDF
> O1Gr8CyGEsukK3BFtBw5voQ=
> =Tzs2
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Single-sign-on-without-form-based-authentication-tf3805975.html#a12415130
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Single-sign on without form-based authentication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lb,
lightbulb432 wrote:
> Views would definitely allow me to keep the two tables separate, but then I'd
> have to authenticate against the two source tables separately (i.e. each
> application would point to the source table rather than to the view). If
> pointing both applications to the common view, then doesn't the original
> problem exist?
Don't do that. Create separate views for each of your applications, and
use the app-appropriate view for authentication.
If you think this sounds like too much trouble, you're right. Just
remember that Tomcat implements the simplest thing that could possibly
work wrt authentication. If you don't like it, you can always override
the authentication mechanism with something else (securityfilter!) or
hand-roll your own realm.
> I took a look at JAASRealm and its authenticate method only takes two
> parameters (username and "credentials", which is really just a single
> password string).
>
>> Is it possible to pass my other credentials to the JAASRealm so that I can
>> pass everything at one time (username, password, other credentials) to the
>> stored procedure, rather than - if I've interepreted this correctly -
>> authenticating once through the JAAS username/password, then again through
>> my stored procedure to "cancel out" the previous authentication.
Uh, you could always pass a concatenated "credential" which includes
more than just the password. For instance:
JAASRealm.authenticate(username, appId + ":" + hash(password));
Then, in your stored procedure, tear apart the "credential" and use part
of it as the app identifier. Or, put the appId into the username.
Whatever you want to do. There are lots of options.
> So if not JAASRealm, perhaps I need to look at something else to customize?
> I could of course implement my own authentication, but if I can get around
> this one shortcoming of the "credentials" concept being considered a
> password String rather than a generic Collection of multiple Objects, then I
> think I might be able to use Tomcat authentication.
You can still use Tomcat's authentication "mechanism"... you just might
have to use your own Realm implementation. Frankly, the
org.apache.catalina.Realm interface is baffling to me.
One option is to create a Realm that extends JDBCRealm (or, better yet,
DataSourceRealm) and override the authentication method to do your own
SQL queries, but keep all the configuration options provided by the
superclass. You can even add a configuration option by adding a mutator
and accessor to specify the app's id. Then you can do something like
this in your context.xml:
<Realm className="package.to.your.Realm" // extends JDBCRealm
driverName="org.gjt.mm.mysql.Driver"
connectionURL="jdbc:mysql://localhost/authority"
connectionName="test"
connectionPassword="test"
userTable="users"
userNameCol="user_name"
userCredCol="user_pass"
userRoleTable="user_roles"
roleNameCol="role_name"
appId="application-1" />
Just make sure you have setAppId and getAppId methods on your Realm
implementation, and then use them when you build your SQL query to
verify a login.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG1wuQ9CaO5/Lv0PARAh6IAKCIY9aMp59xFxXHIj9z4eCfF+SYngCeMfDF
O1Gr8CyGEsukK3BFtBw5voQ=
=Tzs2
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Single-sign on without form-based authentication
Posted by lightbulb432 <ve...@hotmail.com>.
Views would definitely allow me to keep the two tables separate, but then I'd
have to authenticate against the two source tables separately (i.e. each
application would point to the source table rather than to the view). If
pointing both applications to the common view, then doesn't the original
problem exist?
But that requirement is only justification for authenticating with more than
two credentials. From a technical point of view, what would you have to
override to get this to work? In a previous post, I said the following:
I took a look at JAASRealm and its authenticate method only takes two
parameters (username and "credentials", which is really just a single
password string).
>
> Is it possible to pass my other credentials to the JAASRealm so that I can
> pass everything at one time (username, password, other credentials) to the
> stored procedure, rather than - if I've interepreted this correctly -
> authenticating once through the JAAS username/password, then again through
> my stored procedure to "cancel out" the previous authentication.
So if not JAASRealm, perhaps I need to look at something else to customize?
I could of course implement my own authentication, but if I can get around
this one shortcoming of the "credentials" concept being considered a
password String rather than a generic Collection of multiple Objects, then I
think I might be able to use Tomcat authentication.
Christopher Schultz-2 wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Lb,
>
> lightbulb432 wrote:
>> The requirement doesn't accept having two tables (i.e. userTableA and
>> userTableB), partly because increased maintenance, the possibility of
>> table
>> definitions going out of sync, etc.
>
> CREATE VIEW, anyone?
>
> - -chris
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFG1sVh9CaO5/Lv0PARAjCcAJ4gF601g5wChd1FQ1TodzPjKuQmpACgsEqq
> nD8wKTUJVWYkc5eGnA/mXt8=
> =FMuk
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Single-sign-on-without-form-based-authentication-tf3805975.html#a12410535
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Single-sign on without form-based authentication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lb,
lightbulb432 wrote:
> The requirement doesn't accept having two tables (i.e. userTableA and
> userTableB), partly because increased maintenance, the possibility of table
> definitions going out of sync, etc.
CREATE VIEW, anyone?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFG1sVh9CaO5/Lv0PARAjCcAJ4gF601g5wChd1FQ1TodzPjKuQmpACgsEqq
nD8wKTUJVWYkc5eGnA/mXt8=
=FMuk
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org