Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of jak-tomcat-user@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: users@tomcat.apache.org
From: "Bill Barker" <wbarker@wilshire.com>
Subject: Re: Authentication from the browser
Date: Tue, 2 Jun 2009 19:59:19 -0700
Lines: 107
Message-ID: <h04ou6$ciu$1@ger.gmane.org>
References: <34abb48b0906021022w77fa5ef2yd3b0e3d1dc7e614d@mail.gmail.com>
 <4eedb92a0906021037h6506eeb6yf3e219929cde0266@mail.gmail.com>
 <34abb48b0906021103w7fab5541uf1f6c8123696ac0f@mail.gmail.com>
 <4eedb92a0906021122k66e023amd99cd2841cbd25d3@mail.gmail.com>
 <34abb48b0906021301r2ee0964fjd5da3b50992e1027@mail.gmail.com>
 <f5af14000906021334g1ee05efbr7f0474e9a61ccb82@mail.gmail.com>
 <34abb48b0906021503t158542a5ube612b5ccfad0b8a@mail.gmail.com>
Sender: news <news@ger.gmane.org>


"Alec Swan" <alecswan@gmail.com> wrote in message 
news:34abb48b0906021503t158542a5ube612b5ccfad0b8a@mail.gmail.com...
> On Tue, Jun 2, 2009 at 2:34 PM, Jonathan Mast 
> <jhmast.developer@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 <alecswan@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 <alecswan@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