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 <wbar...@wilshire.com> wrote: > > "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 > >
