Добрый день. Подскажите пожалуйста как сделать бесшовную авторизацию через ldap?

Т.е. пользователь открыл мой сайт и по его логину (что при входе в систему ii.ivanov) проходит поиск в моей БД, находит среди пользователей ii.ivanov и впускает пользователя в систему?

ежели найдешь и мне расскажи плиз))

Я делал в свое время через ntlm. Теперь не варик

Я через https://github.com/adldap/adLDAP делал. Там тривиально:

Спасибо. сейчас посмотрю

В крайнем случае все есть тут - https://www.php.net/manual/ru/book.ldap.php

Заодно и это глянь - https://github.com/ldaptools/ldaptools

Можно я Вам в личку напишу?)

Я ничего более нового не скажу )) Я в свое время встроенные (ну не совсем встроенные) в PHP функции юзал.

Ок))) спасибо за помощь

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

другой вариант - вход осуществлять через единый сервис входа, и при входе - передавать в качестве параметра jwt какой-нибудь от сервиса (но тут будет редирект), в общем, все зависит от задачи бизнеса, и такие решения принимаются коллективно всей компаниец

Спасибо

Херассе, значит я уже сеньор? )))) Насчет кэшировать - категорически не согласен. Админы в домене учетку отключили, а мы по кэшу еще авторизуемся какое-то время. Имхо это не правильно. А LDAP для того и создавали шоб быстро обслуживать туеву хучу запросов.

Мегафон, кстати форк OpenLDAP для себя написал (точней для Мегафона написали), когда столкнулся с тем, что с их нагрузками OpenLDAP не справляется. А там не веб-какой нибудь, а жесткий рилтайм... https://github.com/erthink/ReOpenLDAP

кеширование имеет свойство сбрасываться при действии, если с учёткой произошло что-то, то мы обновляем кеш

А теперь подробней как со стороны того же AD сделать это...

зачем со стороны ад? со стороны бека, который принимает запрос и идёт в ад чтобы посмотреть информацию об учетке, в общем, думаю тебе стоит создать тестовую среду такого формата, и поиграться со сценариями, и сделать латенси тяжеловатый между службами, тогда вот почувствуется, будет супер если опубликуешь в паблик - я буду первым, кто скачает твоё решение, чтобы поиграться

Админы отключили учетку в АД. У нас на бэке она закеширована. Как бек об этом узнает? Или каждый раз идем в AD и смотрим статус? Нахрена тогда кэширование? ))) Можно извратиться, и со стороны AD вызывать вебхук при удалении учетки, но во первых автору вопроса это явно не нужно, во вторых у меня в лесу доменов из нескольких тысяч компов десятки запроов в секунду к DC, которые стягивают всех юзеров, включая их фотки из AD. Ничего не тормозит. Но правда фотки я потом переписал, и кэшировать стал, просто от нечего делать. И так все работало.

А теперь самая главная проблема пароль или хэш пароля ты от AD не получишь. И толку то тогда от такого кэширования? Ну да, кэшировать статус можно будет. Но пароль в AD поменялся, как его на беке получить? Только заставлять юзера вводить еще раз и хэш в базу класть. Короче не вижу я плюсов от такого решения...

все индивидуально, если тебе летенси не важно, то можно без кеширования, если важно, то кеширование

зачем пароль кешировать? блин, ещё раз, построй систему, потом фантазируй, все что ты пишешь - бессмысленное обсуждение воды

Ткните носом в небессмысленное решение проблемы.

все зависит сугубо от задачи, нужно - кешируешь - не нужно - не кешируешь, если тебе не важен опыт пользователя, а важно удобство для админов - не кешируешь, важно удобство пользователя, кешируешь, ты мыслишь как разработчик, а не как бизнес

Вы в крупной конторе работали? Где СБшники лично контролируют отключение доменных учеток при увольнении Топов или ИТшников? Какое там нафиг кэширование??? Они наоборот требуют гарантий что уволенный больше никак не сможет в корпоративные сервисы подключиться.

да, я работаю в корпорации, точнее, в её дочке, у нас есть сб, и? ещё раз, узнай про бизнес, потом строй решения? че ты до меня пристал со своими "кеширование в ад это плохо"

а по образованию я как раз таки СПЕЦИАЛИСТ В ОБЛАСТИ ЗАЩИТЫ ИНФОРМАЦИИ, да ещё и работал как безопасник в государственной организации 🤔🤔🤔

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

а я так понял, что продукт из масс сегмента в рамках экосистемы какой-то

это не обязательно делать тут 😂