Назад | Перейти на главную страницу

Как пользоваться услугами, защищенными IP-адресом нашего шлюза от клиентов за пределами нашей сети?

Я работаю в организации, которая использует управляемый хост для App1 и набор приложений App2..N

App1 - это веб-приложение, размещенное на веб-ферме Linux крупным поставщиком, и оно использует аутентификацию, подобную формам (например, простое имя пользователя + пароль).

Коллекция приложений App2..N бесплатно доступна пользователям внутри нашей сети без входа в систему, необходимого на основании запросов, поступающих с IP-адреса нашего шлюза.

Приложения (App2..N) прибл. 10 отдельных поставщиков онлайн-информации, которые разделяют общую модель лицензирования, по которой они заключают договор с моим работодателем о предоставлении информационных услуг через каждое из своих веб-приложений, и, похоже, все они используют схему, в которой они записывают IP-адрес шлюза нашей организации. - и разрешить запросы из тот конкретный IP для использования сервиса без логина / пароля.

Приблизительно 1/10 наших пользователей находятся здесь за нашим брандмауэром, а 9/10 распространены по всему миру.

Эти удаленные пользователи проходят аутентификацию для использования App1, используя аутентификацию пользователя / прохода, подобную формам.

При использовании App1 существуют определенные требования, согласно которым они должны получать доступ к ресурсам App2..N, которые отображаются в виде ссылок в App1.

Поставщики App2..N, как правило, используют различные другие средства, позволяющие нашим удаленным пользователям, однако они всегда, кажется, меняются и выходят из строя с течением времени - все схемы разные, и все меняются в разное время, и большинство этих поставщиков не имеют легкодоступных служб поддержки клиентов - например, Мне сложно угнаться за всеми поломками и плохим доступом к решениям от вендоров.

Я хотел бы придумать какой-нибудь тип веб-приложения, которое могло бы принимать входящие запросы со всей сети, а затем каким-то образом направлять их через нашу внутреннюю сеть, чтобы эти различные запросы могли аутентифицироваться по праву "исходящие из" нашей IP-адрес локального шлюза.

Я не знаю, как называется этот тип решения, я думал, что это будет обратный прокси, но не на 100%.

Какое решение мне нужно? Что называется?

Есть ли какой-то тип сервера, который мы можем запустить в нашей сети и / или в DMZ, который может перенаправлять запросы в App2..N, чтобы они обрабатывались так, как будто они исходят от пользователя в нашей сети?

Ограничение: количество пользователей за пределами нашей сети намного больше, чем количество пользователей внутри нашей сети, поэтому мы не хотим предоставлять VPN-доступ к нашей сети для этой цели.

Поскольку я точно не знаю, как правильно называются инструменты и / или концепции, я открываю приветственное редактирование этого вопроса, чтобы сделать его более понятным для сообщества SF.

РЕДАКТИРОВАТЬ: Я могу не требовать, чтобы исходный IP-адрес для наших запросов к App2..N будут точно с IP нашего шлюза, но если они пришли с одного IP (не обязательно IP нашего шлюза) - это тоже может сработать.

Похоже, вы говорите об обратном прокси. Это будет работать, если вы запустите обратный прокси в своей DMZ. Вы должны дать URL-адрес обратного прокси-сервера своим внешним пользователям.

Когда пользователи переходят по URL-адресу, который вы им предоставили, ваш обратный прокси-сервер получает соединение и запрос. Затем он переводит, переписывает или просто пересылает запрос (как сам / с вашего IP-адреса) в App1. App1 аутентифицирует пользователя.

Вам нужно решить, как определить на обратном прокси, аутентифицированы ли они в App1. Это может быть файл cookie, элемент URL или ... ???. Обратный прокси видит весь веб-трафик, поэтому он должен быть выполнимым.

Как только обратный прокси-сервер узнает, прошли ли вы аутентификацию, вы настраиваете его для выборочной пересылки соединений в App2..N только для аутентифицированных пользователей / соединений.

Вам необходимо убедиться, что либо App1 представляет URL-адреса, которые указывают через обратный прокси-сервер, либо вы переписываете ссылки, представленные App1, для прохождения через обратный прокси.

Конфигурация этого может быть болезненной. Если вы используете Apache, вы ищете что-то вроде mod_rewrite или mod_rewrite2 (если я правильно помню). Есть другое программное обеспечение, которое делает такие вещи (BlueCoat, я думаю, один, но я не знаю, насколько он настраивается )

Надеюсь это поможет.