proNovell

Юрий Беляков писал(а):Простой пример: Sun Java System Web Proxy Server
В теории позволяет авторизовывать пользователей по сертификатам. В реальности быстро настроить не получилось. Индусы как всегда пишут криво документацию, а детально разбираться не было времени.

IMHO это жутко неудобно, и опять же не соответствует техзаданию.

Видел в свое время коммерческие дистрибутивы, внутри которых был Squid. При первом входе пользователь перенаправлялся на какую-то страничку, где нужно было ввести имя/пароль. Прошел регистрацию - дальше может пользоваться. Как это делается в деталях - где бы почитать...

Если эта страничка будет отдаваться по https то тогда будет побезопасней немного, но наверняка там используется механизм внесения ип адреса в какой-то trusted список, что является изначально небезопасным и в некоторых случаях (терминальные сервера, nat) неприемлимым.

v13 писал(а):IMHO это жутко неудобно, и опять же не соответствует техзаданию.

Как раз все соответствует, если бы удалось заставить работать
Не совсем удобно работать с сертификатами.

v13 писал(а):

Константин Ошмян писал(а):Я приводил пример выше.

Ваш пример из другой оперы - посмотрите техзадание.

Перечитал ещё раз техзадание, перечитал свой пример. В чём несоответствие? По-моему, соответствует полностью. Авторизация пользователей путём обращения к LDAP-каталогу, которое можно сделать защищённым (через SSL). Между рабочими станциями и прокси-сервером пароли не передаются.

Единственное, что несоответствует, - это отсутствие домена AD, но я же про это тоже упоминал. Во-первых, для NTLM-аутентификации можно использовать CIFS или Samba (или эмуляцию домена в eDirectory, когда её - эмуляцию - доделают). Во-вторых, на NTLM-аутентификации свет клином не сошёлся: можно использовать и альтернативные методы (правда, я не слышал о каком-то, который бы был удобен во всех отношениях - везде есть свои недостатки). Один из них уже упоминался: сертификаты. Другой тоже: обращение к eDirectory с запросом о том, кто залогинен с такого-то IP-адреса. Третий способ тоже упоминался: перенаправление на отдельную страничку с формой для ввода имени-пароля, которые пересылаются по HTTPS. Могу припомнить также идею использования клиента Single Sign-On от ClientTrust (который применяется в Border Manager-е).

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