You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Alec Swan <al...@gmail.com> on 2009/06/02 19:22:36 UTC
Authentication from the browser
I implemented a servlet and deployed it in Tomcat 6.0. The servlet is
secured using Tomcat authentication mechanism which reads user credentials
from the conf/users.xml file.
We have a customer who would like to put a link on a web page (hosted by
their server) which will invoke the servlet (hosted on our Tomcat server).
We would also like to continue using the existing authentication mechanism.
So, the question is how can we configure the customer environment, the link
or my Tomcat server to allow authentication to happen without requiring the
end-user to type in the user name and password?
Can we implement link authentication using JavaScript to set HTTP headers?
Thanks.
RE: Authentication from the browser
Posted by Martin Gainty <mg...@hotmail.com>.
Alec-
Here are the index.jsp contents from securityfilter
<h2>POST to the Secure Page</h2>
This form POSTs to the Secure Page. By entering a value here and clicking the submit button below, you can
verify that POSTed parameters are maintained through the login sequence.
<form id="<%=Constants.HOME_FORM_ID%>"
action="<%=response.encodeURL(request.getContextPath() + "/securePage.jsp")%>" method="POST">
<input type="text" name="<%=Constants.HOME_POST_FIELD%>">
<input type="submit">
</form>
make sure you supply a valid url to securePage.jsp (now its supplied as)
request.getContextPath() + "/securePage.jsp
supply valid values for HOME_FORM_ID
public static final String HOME_FORM_ID = "homeForm";
and valid value for HOME_POST_FIELD now initialised to
public static final String HOME_POST_FIELD = "postMe";
got it working on my server if you need a link
Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> Date: Tue, 2 Jun 2009 16:08:58 -0600
> Subject: Re: Authentication from the browser
> From: alecswan@gmail.com
> To: users@tomcat.apache.org
>
> >
> > ? You can't put HTTP headers "in" a link, unless you're processing
> > it through some proxy mechanism...
> >
>
> Looks like the last SecurityFilter build was released on Dec. 14, 2004,
> which makes me hesitant to use it.
>
> I am wondering if it is possible to use JavaScript to include the user name
> and password in the HTTP header when the link is clicked. According to the
> following statement I borrowed from
> http://securityfilter.sourceforge.net/this won't work either:
> "With container managed security, the container will not process login
> requests unless the container itself has initiated the authentication
> sequence .."
>
> Does this mean that there is no way to authenticate against Tomcat server
> unless the server initiated the request itself?
>
>
> > > Does this give you enough information to propose a solution?
> >
> > I suspect you need to write your own solution, though this:
> > http://securityfilter.sourceforge.net/
> > :: has been recommended by others on this list many times, and
> > might help (I've never used it).
> >
> > HTH,
> > --
> > Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
_________________________________________________________________
Hotmail® has ever-growing storage! Don’t worry about storage limits.
http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage_062009
Re: Authentication from the browser
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alec,
On 6/2/2009 6:08 PM, Alec Swan wrote:
>> ? You can't put HTTP headers "in" a link, unless you're processing
>> it through some proxy mechanism...
>>
>
> Looks like the last SecurityFilter build was released on Dec. 14,
> 2004, which makes me hesitant to use it.
The servlet specification regarding authentication and authorization
hasn't changed in a long time, so newer releases haven't been warranted.
The project is definitely active, in spite of a lack of recent releases.
> I am wondering if it is possible to use JavaScript to include the
> user name and password in the HTTP header when the link is clicked.
Yuk. Relying on javascript for security is, IMO, a terrible mistake.
> Does this mean that there is no way to authenticate against Tomcat
> server unless the server initiated the request itself?
No, that means that the client must make a request for a protected
resource /before/ the client can provide credentials to the server (i.e.
"no drive-by logins").
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkomiUEACgkQ9CaO5/Lv0PAoVgCdHoR8zCu91Bn4prfOhKhs45yx
ElMAn2axBAgLGQ9TAKHz29angRfCJje3
=7rCg
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Authentication from the browser
Posted by Alec Swan <al...@gmail.com>.
>
> ? You can't put HTTP headers "in" a link, unless you're processing
> it through some proxy mechanism...
>
Looks like the last SecurityFilter build was released on Dec. 14, 2004,
which makes me hesitant to use it.
I am wondering if it is possible to use JavaScript to include the user name
and password in the HTTP header when the link is clicked. According to the
following statement I borrowed from
http://securityfilter.sourceforge.net/this won't work either:
"With container managed security, the container will not process login
requests unless the container itself has initiated the authentication
sequence .."
Does this mean that there is no way to authenticate against Tomcat server
unless the server initiated the request itself?
> > Does this give you enough information to propose a solution?
>
> I suspect you need to write your own solution, though this:
> http://securityfilter.sourceforge.net/
> :: has been recommended by others on this list many times, and
> might help (I've never used it).
>
> HTH,
> --
> Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Authentication from the browser
Posted by Hassan Schroeder <ha...@gmail.com>.
On Tue, Jun 2, 2009 at 1:01 PM, Alec Swan <al...@gmail.com> wrote:
> We have one corporate customer who is putting a link to our servlet on their
> intranet web page. Therefore, we know the domain name of the users who need
> custom authentication.
Seems iffy -- none of these users will ever be working remotely
and need access?
> We can also tell the customer to put whatever we need
> in the link, such as HTTP headers.
? You can't put HTTP headers "in" a link, unless you're processing
it through some proxy mechanism...
> Does this give you enough information to propose a solution?
I suspect you need to write your own solution, though this:
http://securityfilter.sourceforge.net/
:: has been recommended by others on this list many times, and
might help (I've never used it).
HTH,
--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Authentication from the browser
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alec,
On 6/3/2009 12:25 PM, Alec Swan wrote:
> Bill, thank you for your feedback. I read up on CLIENT-CERT and am now
> surprised that Bill was the only one to mention it. It sounds like
> CLIENT-CERT is the scheme that we should. We can generate certificates and
> ask our customer to distribute it to its users and have them install
> certificates in their browsers.
>
> Is there a reason why not many people recommended CLIENT-CERT authentication
> on this thread?
We assumed that your stated requirements were accurate. A second
application deployment didn't seem like an option. Note that CLIENT-CERT
cannot be used alongside BASIC/DIGEST or FORM authentication within the
same application: you'll need to deploy the application twice, each with
a different authentication scheme.
Of course, there are ways to do this with code if you follow my
suggestion of having a service-only URL available that handles
authentication differently than the rest of the application.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkon+MIACgkQ9CaO5/Lv0PA0xwCeLSgL5zcnwsHfYof6+KcXYjlc
EzkAoML3rgGqMVh9pJDU51QqUph6yLVQ
=64oX
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Authentication from the browser
Posted by Alec Swan <al...@gmail.com>.
Bill, thank you for your feedback. I read up on CLIENT-CERT and am now
surprised that Bill was the only one to mention it. It sounds like
CLIENT-CERT is the scheme that we should. We can generate certificates and
ask our customer to distribute it to its users and have them install
certificates in their browsers.
Is there a reason why not many people recommended CLIENT-CERT authentication
on this thread?
Thanks
On Tue, Jun 2, 2009 at 8:59 PM, Bill Barker <wb...@wilshire.com> wrote:
>
> "Alec Swan" <al...@gmail.com> wrote in message
> news:34abb48b0906021503t158542a5ube612b5ccfad0b8a@mail.gmail.com...
> > On Tue, Jun 2, 2009 at 2:34 PM, Jonathan Mast
> > <jh...@gmail.com>wrote:
> >
> >> Alec, so basically members of your client company should be able to have
> >> direct access to a servlet that is otherwise restricted to a handful of
> >> users who must authenicate themselves with a username/password login,
> >> right?
> >>
> >
> > Yes, this is exactly what we need.
> >
>
> Awhile back, I had a request to do something similar. However, in this
> case
> the (then) client was providing a portal that their users logged onto, and
> proxied to our app. What we did is to clone the webapp and make the clone
> authenticate with CLIENT-CERT. The client portal would then proxy to the
> clone and provide the same certificate for all users that it had
> authenticated (which Tomcat then accepted). In this case, even if a
> blackhat could find the URL for the clone, she still couldn't get in.
>
> >
> >>
> >> One solution to this situation would be to create a simple servlet that
> >> sniffs incoming request IPs, if they match the range/set of IPs of your
> >> client, then you bypass the authenication mechanism of your existing
> >> servlet
> >> and give them a full view of whatever goodies your servlet has. If
> >> incoming
> >> requests don't match the IPs then bounce them off somewhere.
> >>
> >> However this approach is not a complete solution, a very interested
> party
> >> could observe your system and deduce that it was based upon privileged
> >> IPs
> >> and then spoof them. It all depends upon how important this servlet is
> >> you
> >> and your organization. If it is absolutely mission critical, then
> you'll
> >> want to use SSL and require logins.
> >
> >
> > The servlet is not mission critical and provides only read-only access. I
> > like this idea, but as Hassaan pointed out it does not allow our customer
> > users to access this page if they are outside of the VPN.
> >
> >
> >
> >>
> >>
> >> On Tue, Jun 2, 2009 at 4:01 PM, Alec Swan <al...@gmail.com> wrote:
> >>
> >> > I may not be explaining it clearly.
> >> >
> >> > We have one corporate customer who is putting a link to our servlet on
> >> > their
> >> > intranet web page. Therefore, we know the domain name of the users who
> >> need
> >> > custom authentication. We can also tell the customer to put whatever
> we
> >> > need
> >> > in the link, such as HTTP headers.
> >> >
> >> > Does this give you enough information to propose a solution?
> >> >
> >> >
> >> > On Tue, Jun 2, 2009 at 12:22 PM, Hassan Schroeder <
> >> > hassan.schroeder@gmail.com> wrote:
> >> >
> >> > > On Tue, Jun 2, 2009 at 11:03 AM, Alec Swan <al...@gmail.com>
> >> > > wrote:
> >> > > > Hassan, I don't think that the goals are contradictory, because
> >> > > > each
> >> > goal
> >> > > > applies to its own group of users: our customer users and
> everybody
> >> > else.
> >> > > > Customer users should not have to enter user name and password,
> but
> >> > > > everybody else should.
> >> > >
> >> > > IOW, you want it protected, and you want it openly accessable.
> >> > > Sorry, that sounds contradictory to me :-)
> >> > >
> >> > > If you have "a customer who would like to put a link on a web page"
> >> > > to your servlet, that servlet's URL is now "in the wild" -- anyone
> >> > > who
> >> > > finds it can access it.
> >> > >
> >> > > > I am glad that you made me think about this, because maybe it is
> >> > possible
> >> > > to
> >> > > > extend Tomcat authentication to also use client IP address or
> >> > > > domain?
> >> > >
> >> > > How would you know a priori the IP or domain of the clients?
> >> > >
> >> > > --
> >> > > Hassan Schroeder ------------------------
> hassan.schroeder@gmail.com
> >> > >
> >> > >
> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> > > For additional commands, e-mail: users-help@tomcat.apache.org
> >> > >
> >> > >
> >> >
> >>
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Authentication from the browser
Posted by Bill Barker <wb...@wilshire.com>.
"Alec Swan" <al...@gmail.com> wrote in message
news:34abb48b0906021503t158542a5ube612b5ccfad0b8a@mail.gmail.com...
> On Tue, Jun 2, 2009 at 2:34 PM, Jonathan Mast
> <jh...@gmail.com>wrote:
>
>> Alec, so basically members of your client company should be able to have
>> direct access to a servlet that is otherwise restricted to a handful of
>> users who must authenicate themselves with a username/password login,
>> right?
>>
>
> Yes, this is exactly what we need.
>
Awhile back, I had a request to do something similar. However, in this case
the (then) client was providing a portal that their users logged onto, and
proxied to our app. What we did is to clone the webapp and make the clone
authenticate with CLIENT-CERT. The client portal would then proxy to the
clone and provide the same certificate for all users that it had
authenticated (which Tomcat then accepted). In this case, even if a
blackhat could find the URL for the clone, she still couldn't get in.
>
>>
>> One solution to this situation would be to create a simple servlet that
>> sniffs incoming request IPs, if they match the range/set of IPs of your
>> client, then you bypass the authenication mechanism of your existing
>> servlet
>> and give them a full view of whatever goodies your servlet has. If
>> incoming
>> requests don't match the IPs then bounce them off somewhere.
>>
>> However this approach is not a complete solution, a very interested party
>> could observe your system and deduce that it was based upon privileged
>> IPs
>> and then spoof them. It all depends upon how important this servlet is
>> you
>> and your organization. If it is absolutely mission critical, then you'll
>> want to use SSL and require logins.
>
>
> The servlet is not mission critical and provides only read-only access. I
> like this idea, but as Hassaan pointed out it does not allow our customer
> users to access this page if they are outside of the VPN.
>
>
>
>>
>>
>> On Tue, Jun 2, 2009 at 4:01 PM, Alec Swan <al...@gmail.com> wrote:
>>
>> > I may not be explaining it clearly.
>> >
>> > We have one corporate customer who is putting a link to our servlet on
>> > their
>> > intranet web page. Therefore, we know the domain name of the users who
>> need
>> > custom authentication. We can also tell the customer to put whatever we
>> > need
>> > in the link, such as HTTP headers.
>> >
>> > Does this give you enough information to propose a solution?
>> >
>> >
>> > On Tue, Jun 2, 2009 at 12:22 PM, Hassan Schroeder <
>> > hassan.schroeder@gmail.com> wrote:
>> >
>> > > On Tue, Jun 2, 2009 at 11:03 AM, Alec Swan <al...@gmail.com>
>> > > wrote:
>> > > > Hassan, I don't think that the goals are contradictory, because
>> > > > each
>> > goal
>> > > > applies to its own group of users: our customer users and everybody
>> > else.
>> > > > Customer users should not have to enter user name and password, but
>> > > > everybody else should.
>> > >
>> > > IOW, you want it protected, and you want it openly accessable.
>> > > Sorry, that sounds contradictory to me :-)
>> > >
>> > > If you have "a customer who would like to put a link on a web page"
>> > > to your servlet, that servlet's URL is now "in the wild" -- anyone
>> > > who
>> > > finds it can access it.
>> > >
>> > > > I am glad that you made me think about this, because maybe it is
>> > possible
>> > > to
>> > > > extend Tomcat authentication to also use client IP address or
>> > > > domain?
>> > >
>> > > How would you know a priori the IP or domain of the clients?
>> > >
>> > > --
>> > > Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> > > For additional commands, e-mail: users-help@tomcat.apache.org
>> > >
>> > >
>> >
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Authentication from the browser
Posted by Alec Swan <al...@gmail.com>.
On Tue, Jun 2, 2009 at 2:34 PM, Jonathan Mast <jh...@gmail.com>wrote:
> Alec, so basically members of your client company should be able to have
> direct access to a servlet that is otherwise restricted to a handful of
> users who must authenicate themselves with a username/password login,
> right?
>
Yes, this is exactly what we need.
>
> One solution to this situation would be to create a simple servlet that
> sniffs incoming request IPs, if they match the range/set of IPs of your
> client, then you bypass the authenication mechanism of your existing
> servlet
> and give them a full view of whatever goodies your servlet has. If
> incoming
> requests don't match the IPs then bounce them off somewhere.
>
> However this approach is not a complete solution, a very interested party
> could observe your system and deduce that it was based upon privileged IPs
> and then spoof them. It all depends upon how important this servlet is
> you
> and your organization. If it is absolutely mission critical, then you'll
> want to use SSL and require logins.
The servlet is not mission critical and provides only read-only access. I
like this idea, but as Hassaan pointed out it does not allow our customer
users to access this page if they are outside of the VPN.
>
>
> On Tue, Jun 2, 2009 at 4:01 PM, Alec Swan <al...@gmail.com> wrote:
>
> > I may not be explaining it clearly.
> >
> > We have one corporate customer who is putting a link to our servlet on
> > their
> > intranet web page. Therefore, we know the domain name of the users who
> need
> > custom authentication. We can also tell the customer to put whatever we
> > need
> > in the link, such as HTTP headers.
> >
> > Does this give you enough information to propose a solution?
> >
> >
> > On Tue, Jun 2, 2009 at 12:22 PM, Hassan Schroeder <
> > hassan.schroeder@gmail.com> wrote:
> >
> > > On Tue, Jun 2, 2009 at 11:03 AM, Alec Swan <al...@gmail.com> wrote:
> > > > Hassan, I don't think that the goals are contradictory, because each
> > goal
> > > > applies to its own group of users: our customer users and everybody
> > else.
> > > > Customer users should not have to enter user name and password, but
> > > > everybody else should.
> > >
> > > IOW, you want it protected, and you want it openly accessable.
> > > Sorry, that sounds contradictory to me :-)
> > >
> > > If you have "a customer who would like to put a link on a web page"
> > > to your servlet, that servlet's URL is now "in the wild" -- anyone who
> > > finds it can access it.
> > >
> > > > I am glad that you made me think about this, because maybe it is
> > possible
> > > to
> > > > extend Tomcat authentication to also use client IP address or domain?
> > >
> > > How would you know a priori the IP or domain of the clients?
> > >
> > > --
> > > Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: users-help@tomcat.apache.org
> > >
> > >
> >
>
Re: Authentication from the browser
Posted by Jonathan Mast <jh...@gmail.com>.
Alec, so basically members of your client company should be able to have
direct access to a servlet that is otherwise restricted to a handful of
users who must authenicate themselves with a username/password login, right?
One solution to this situation would be to create a simple servlet that
sniffs incoming request IPs, if they match the range/set of IPs of your
client, then you bypass the authenication mechanism of your existing servlet
and give them a full view of whatever goodies your servlet has. If incoming
requests don't match the IPs then bounce them off somewhere.
However this approach is not a complete solution, a very interested party
could observe your system and deduce that it was based upon privileged IPs
and then spoof them. It all depends upon how important this servlet is you
and your organization. If it is absolutely mission critical, then you'll
want to use SSL and require logins.
On Tue, Jun 2, 2009 at 4:01 PM, Alec Swan <al...@gmail.com> wrote:
> I may not be explaining it clearly.
>
> We have one corporate customer who is putting a link to our servlet on
> their
> intranet web page. Therefore, we know the domain name of the users who need
> custom authentication. We can also tell the customer to put whatever we
> need
> in the link, such as HTTP headers.
>
> Does this give you enough information to propose a solution?
>
>
> On Tue, Jun 2, 2009 at 12:22 PM, Hassan Schroeder <
> hassan.schroeder@gmail.com> wrote:
>
> > On Tue, Jun 2, 2009 at 11:03 AM, Alec Swan <al...@gmail.com> wrote:
> > > Hassan, I don't think that the goals are contradictory, because each
> goal
> > > applies to its own group of users: our customer users and everybody
> else.
> > > Customer users should not have to enter user name and password, but
> > > everybody else should.
> >
> > IOW, you want it protected, and you want it openly accessable.
> > Sorry, that sounds contradictory to me :-)
> >
> > If you have "a customer who would like to put a link on a web page"
> > to your servlet, that servlet's URL is now "in the wild" -- anyone who
> > finds it can access it.
> >
> > > I am glad that you made me think about this, because maybe it is
> possible
> > to
> > > extend Tomcat authentication to also use client IP address or domain?
> >
> > How would you know a priori the IP or domain of the clients?
> >
> > --
> > Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>
Re: Authentication from the browser
Posted by Alec Swan <al...@gmail.com>.
I may not be explaining it clearly.
We have one corporate customer who is putting a link to our servlet on their
intranet web page. Therefore, we know the domain name of the users who need
custom authentication. We can also tell the customer to put whatever we need
in the link, such as HTTP headers.
Does this give you enough information to propose a solution?
On Tue, Jun 2, 2009 at 12:22 PM, Hassan Schroeder <
hassan.schroeder@gmail.com> wrote:
> On Tue, Jun 2, 2009 at 11:03 AM, Alec Swan <al...@gmail.com> wrote:
> > Hassan, I don't think that the goals are contradictory, because each goal
> > applies to its own group of users: our customer users and everybody else.
> > Customer users should not have to enter user name and password, but
> > everybody else should.
>
> IOW, you want it protected, and you want it openly accessable.
> Sorry, that sounds contradictory to me :-)
>
> If you have "a customer who would like to put a link on a web page"
> to your servlet, that servlet's URL is now "in the wild" -- anyone who
> finds it can access it.
>
> > I am glad that you made me think about this, because maybe it is possible
> to
> > extend Tomcat authentication to also use client IP address or domain?
>
> How would you know a priori the IP or domain of the clients?
>
> --
> Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Authentication from the browser
Posted by Hassan Schroeder <ha...@gmail.com>.
On Tue, Jun 2, 2009 at 11:03 AM, Alec Swan <al...@gmail.com> wrote:
> Hassan, I don't think that the goals are contradictory, because each goal
> applies to its own group of users: our customer users and everybody else.
> Customer users should not have to enter user name and password, but
> everybody else should.
IOW, you want it protected, and you want it openly accessable.
Sorry, that sounds contradictory to me :-)
If you have "a customer who would like to put a link on a web page"
to your servlet, that servlet's URL is now "in the wild" -- anyone who
finds it can access it.
> I am glad that you made me think about this, because maybe it is possible to
> extend Tomcat authentication to also use client IP address or domain?
How would you know a priori the IP or domain of the clients?
--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Authentication from the browser
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alec,
On 6/2/2009 2:03 PM, Alec Swan wrote:
> Hassan, I don't think that the goals are contradictory, because each goal
> applies to its own group of users: our customer users and everybody else.
> Customer users should not have to enter user name and password, but
> everybody else should.
What authentication mechanism are you using already? FORM? BASIC?
With BASIC or DIGEST authentication, it's easy enough to put the
credentials into the request that the remote server sends to you.
If you're using FORM authentication, it's more complicated because
Tomcat's authentication /requires/
request->challenge->credentials->repeat-request. If you use
securityfilter (http://securityfilter.sourceforge.net), you can do
drive-by logins by just calling j_security_check directly (without an
initial request).
Another option (which I prefer) is to provide a service that is oriented
toward these clients which accepts credentials in a different form.
Don't use container-managed security for this service. Instead, accept
credentials in some other way. You can accept username and password, or
you could even accept a single token which is encrypted using a
pre-shared key.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkomh9QACgkQ9CaO5/Lv0PB/wwCfdVDhW0QEwL4psZmLz2ff1JM+
EwQAnjjeCbAPtHbiJBvGJV1HVpwdkl0r
=8h+o
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Authentication from the browser
Posted by Alec Swan <al...@gmail.com>.
Hassan, I don't think that the goals are contradictory, because each goal
applies to its own group of users: our customer users and everybody else.
Customer users should not have to enter user name and password, but
everybody else should.
Also, in general it is possible to authenticate a user without requiring the
user to enter the user name and password in the application, e.g. NTLM-based
authentication or authentication based on the client's IP address.
I am glad that you made me think about this, because maybe it is possible to
extend Tomcat authentication to also use client IP address or domain?
Can you think of any other ways to have two different authentication
mechanisms for the same servlet?
Thanks!
On Tue, Jun 2, 2009 at 11:37 AM, Hassan Schroeder <
hassan.schroeder@gmail.com> wrote:
> On Tue, Jun 2, 2009 at 10:22 AM, Alec Swan <al...@gmail.com> wrote:
>
> > We would also like to continue using the existing authentication
> mechanism.
>
> > So, the question is how can we ... allow authentication to happen
> > without requiring the end-user to type in the user name and password?
>
> Your goals seem contradictory. Maybe you need to rethink... :-)
>
> --
> Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Authentication from the browser
Posted by Hassan Schroeder <ha...@gmail.com>.
On Tue, Jun 2, 2009 at 10:22 AM, Alec Swan <al...@gmail.com> wrote:
> We would also like to continue using the existing authentication mechanism.
> So, the question is how can we ... allow authentication to happen
> without requiring the end-user to type in the user name and password?
Your goals seem contradictory. Maybe you need to rethink... :-)
--
Hassan Schroeder ------------------------ hassan.schroeder@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org