freepascal.ru

Просьба задать направление поиска (толковую статью) или объяснить на пальцах.

Есть самописные программы "Сервер" "Клиент". Авторизация проходит по "детской" схеме:
1. Клиент подключается к Серверу.
2. Пользователь вводит логин и пароль, Клиент отправляет их на сервер.
3. Сервер сверяется со своим списком и понимает с каким пользователем он работает.

вопрос КАК СДЕЛАТЬ (учитывая что пользователи под Виндой работают своей учеткой из Новела):
A. для пользователей прошедших Виндой авторизацию пропустить пункт 2. А список из пункта 3 видимо должен переехать в LDAP?
B. оставить возможность использования пункт 2 (вход на "сервер" другой учеткой или у Клиента нет доступа к корп. LDAP).

1. Зачем нужно менять схему работы?
2. А может ограничится тем, чтобы логины AD соответствовали логинам в списка твоего сервера? Проще, и обновлять не так геморно все. А авторизация тогда будет первый раз по тому же логину и паролю, а потом пусть сервер выдасть клиенту некий "ключ" который будет сверяться по какому то алгоритму с списокм и говорить надо ли заново проходить авторизацию. Как у сайтов, к примеру. Серверная часть если надо, уже может быть переписана и проверять пароли с сервера не своего.

Возникает такое ощущение, что у Вас авторизация пользователя происходит на сервере. Если с сервером работает только Ваш клиент, то такой подход излишен.

Уточню начальные данные.
1. корп. сеть на Новеле.
2. каждый пользователь имеет свой логин и пароль.
3. самописные "Клиент" и "Сервер".

Sharfik писал(а):1. Зачем нужно менять схему работы?

"Прозрачная" авторизация.
Пользователь пришел на работу, включил комп, ЛОГИНИТСЯ своей учеткой при входе в винду (и собственно в Новеле). Запускает клиента ... и вот здесь хочется пропустить повторную авторизацию на моем сервере. Технически личность пользователя установлена (авторизацию виндой то он прошел) но как это объяснить моему серверу я чего-то додумкать не могу.
Уверен что это "типичная" задача, для которой есть "рекомендованное" решение и типичные ошибки реализации такого функционала. Постоянно натыкаюсь на статьи как настроить "Сервер А" для прозрачной авторизации с помощью LDAP, а вот как реализовать (запрограммировать) такой сервер ... найти не могу

Sharfik писал(а):2. А может ограничится тем, чтобы логины AD соответствовали логинам в списка твоего сервера? ...

мне кажется что мой сервер вообще должен брать этот список из LDAP

1. Уже имеется структура работы, отбрасывая ее ты посылаешь лесом все работающие клиенты. Привяжешься к ПО разработанному третьей стороной, ты себе подпишешь приговор в виде неработоспособности ПО без доступа к Их серверу, и в случае если Их система что то не так сделает или перестанет поддерживать протокол реализованный у тебя.
2. Твой сервер может работать как надо тебе, и некому ничего не должен. К примеру, Outlook настраивается при первом запуске на сервак почты руками, даже если есть учетка AD. А потом уже работает по факту, если что то не так повторно просит пароль и логин. У себя ты можешь сделать активацию сессии с своим серваком и запомнить ее параметры доступа там, где это доступно только конкретному пользователю прошедшему авторизацию с помощью ОС. В файлах аккаунта ОС. Почитай как в PHP выполняет авторизация пользователей на сайтах, понятней станет.

Я просто считаю, что ты можешь сделать гибкий универсальный способ работы, а вместо этого хочешь завязаться на технологии третьей стороны. Сразу если не стал через них делать, то смысла это сейчас реализовывать не вижу. ИМХО.

Добавлено спустя 5 минут 53 секунды:

stanilar писал(а):Возникает такое ощущение, что у Вас авторизация пользователя происходит на сервере. Если с сервером работает только Ваш клиент, то такой подход излишен.

Когда ключ вставляют в замок, то замок решает откроет этот ключ дверь или нет. Странной если будет на оборот. Логин пароль это способ защиты данных, если это реализовано значит это надо. Хоть раз в жизни пробовал что то взломать?

Sharfik писал(а):Я просто считаю, что ты можешь сделать гибкий универсальный способ работы, а вместо этого хочешь завязаться на технологии третьей стороны. Сразу если не стал через них делать, то смысла это сейчас реализовывать не вижу. ИМХО.

LDAP -- это гибкая, кроссплатформенная технология, поддерживаемая разными производителями ПО, как коммерческими, так и общественными. Использовать ее ради удобства пользователя -- стратегически правильно.

По сути вопроса помочь не могу, к сожалению.

И все таки задам еще один вопрос. Почему нельзя так:

1) Пользователь, под учеткой, зашел в программу и ввел пароль+логин.
2) Программа запомнила соответствие учетка - пароль/логин.
3) при следующем запуске программа сама подставит соответствующий учетке пароль+логин.

Добавлено спустя 26 минут 8 секунд:

Sharfik писал(а):Когда ключ вставляют в замок, то замок решает откроет этот ключ дверь или нет.

По нормальному, тут должно быть два замка и ключа. Один от квартиры с сейфом, другой от самого сейфа. Если ключ от квартиры и от сейфа один и тот-же, то на фига нужен сейф?

stanilar писал(а):По нормальному, тут должно быть два замка и ключа. Один от квартиры с сейфом, другой от самого сейфа. Если ключ от квартиры и от сейфа один и тот-же, то на фига нужен сейф?

Сейф не нужен, об этом топикстартер ясно написал в первом посте.

stanilar писал(а):По нормальному, тут должно быть два замка и ключа. Один от квартиры с сейфом, другой от самого сейфа. Если ключ от квартиры и от сейфа один и тот-же, то на фига нужен сейф?

от степени важности данных зависит.

А твой вариант авторизации совершенно справедлив, я в принципе его и предлагал. Только хранить пароль открыто не очень красиво, а по id открытой сессии можно и выкидывать удаленно всех с соединения, когда надо что то обновить, и пароли хранить не надо, только логины.

А у меня такой вопрос - если гражданин уже зарегистрировался в системе, т.е. он опознан и принят положительно, нужно ли при работе с сервером опять проверять его на "лояльность"?

Дож писал(а):Сейф не нужен, об этом топикстартер ясно написал в первом посте.

ТС скорее нужно, чтоб при открытии двери уже и сейф был открыт. На самом деле не очень понятно, где идет валидация пароля: сервер только протоколирует то, с кем работает, или обрывает соединение при неправильном пароле? В первом случае сейф есть, но всегда открыт. Во втором случае есть и сам сейф, и ключ от него.

Так вот возникает вопрос, если и сервер свой и клиент свой, то ключом от сервера может быть собственный протокол обмена, либо ключ лицензии на программу. Тогда валидация пользователя проходит на клиенте, и действительно есть возможность запоминать связку учетка+логин/пароль для входа.

Если валидация пользователя идет на сервере, и эта валидация строго привязана к паролю+логин, то судя по первому посту, это вызывает проблемы в возможности запомнить пару учетка+логин. Вот мне и интересно что это за проблемы.

Vadim писал(а):А у меня такой вопрос - если гражданин уже зарегистрировался в системе, т.е. он опознан и принят положительно, нужно ли при работе с сервером опять проверять его на "лояльность"?

вот ... именно, повторную проверку я и хочу избежать.

stanilar писал(а):Если валидация пользователя идет на сервере, и эта валидация строго привязана к паролю+логин, то судя по первому посту, это вызывает проблемы в возможности запомнить пару учетка+логин. Вот мне и интересно что это за проблемы.

проблема "среднестатистического" пользователя ... вот не хочет он помнить 10 разных логин-паролей к различным системам на предприятии, он готов запомнить ОДИН пароль-логин и везде с ним ходить (и тут я с пользователем согласен, и как мне кажется Домены, LDAP`ы (Novel, AD и т.д.) можно использовать для этих целей)

То есть хочется реализовать два сценария:
1. Пользователь внутри домена (вошел в корп. сеть). Тогда мой сервер должен прозрачно (не запрашивая пароль и логин) его авторизовать и продолжить работу.
2. Пользователь находится ВНЕ домена. Тогда пользователь вводит логин-Пароль, который мой сервер проверяет средствами LDAP.

Ближе к делу. В библиотеке Ararat Synapse есть модуль LDAPSend, который, как говорят, реализует функциональность клиента LDAP. Его смотрели? Неужели нельзя было нагуглить?

Vapaamies писал(а):Ближе к делу. В библиотеке Ararat Synapse есть модуль LDAPSend, который, как говорят, реализует функциональность клиента LDAP. Его смотрели? Неужели нельзя было нагуглить?

конечно же я его видел, и другие смотрел. Получение списка пользователей и проверка Логин-Пароля через LDAP в принципе реализуется и примеры есть.

я не могу найти информация как правильно реализовать сценарий:
Пользователь вошел в корпСеть на Новеле.
И теперь прозрачно для пользователя (то есть БЕЗ повторного ввода Логин-Пароль) должна произойти Аутентифика́ция и Авторизация на моем сервере.

iN0k писал(а):И теперь прозрачно для пользователя (то есть БЕЗ повторного ввода Логин-Пароль) должна произойти Аутентифика́ция и Авторизация на моем сервере.

Проблема в чем? В логике?

Грубо говоря, в окне ввода логина-пароля должна быть галка "Авторизоваться через LDAP", затеняющая поля ввода логина и пароля. Далее зависит от схемы, используемой во взаимодействии клиент-сервер. Программа может отправлять эту галку на сервер, вынуждая его выполнять какие-то дополнительные действия, и/или же имя пользователя запрашивается из окружения на стороне клиента, и потом отправляется на сервер вместе с этой галкой (булевым полем).