"Alec Swan" <alecs...@gmail.com> wrote in message news:34abb48b0906021503t158542a5ube612b5ccfad0...@mail.gmail.com... > 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. >
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 <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 >> > > >> > > >> > >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
