On Tue, Jun 2, 2009 at 2:34 PM, Jonathan Mast <jhmast.develo...@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 <alecs...@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.schroe...@gmail.com> wrote: > > > > > On Tue, Jun 2, 2009 at 11:03 AM, Alec Swan <alecs...@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.schroe...@gmail.com > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > >
