Pull to refresh

Comments 8

прежде чем обратиться к серверу, клиент посылает сообщение KDC, а KDC в свою очередь направляет каждому участнику сеанса копии сеансового ключа, действующие в течение небольшого промежутка времени.

Всё-таки KDC (TGS) не контактирует с двумя сторонами, когда клиент запрашивает соединение.

Клиент (принципал), чтобы проийти взаимную проверку подлинности с запрашиваемым ресурсом, отправляет запрос TGS-REQ в сторону TGS. В этом запросе содержатся TGT клиента и наименование запрашиваемого ресурса (servicePrincipalName, например, как и у вас в статье). TGS возвращает клиенту в ответ TGS-REP, в котором содержатся служебный билет и сеансовый ключ для сеанса между клиентом и ресурсом. А уж потом клиент делает запрос к ресурсу с этим билетом, в ходе которого клиент и ресурс проходят взаимную проверку подлинности.

TGS незачем что-то передавать ресурсу — всё есть в TGS-REP, и это довольно экономичное решение с точки зрения количества передаваемых данных.

А статья полезная. Лет 7 назад как подумывал об использовании Kerberos для OTRS, никогда руки не доходили.
Ни в коем случае не оспариваю ваше утверждение, более того, понимаю что так оно намного проще и должно быть. Ещё когда пытался разобраться с Kerberos, так себе и представлял этот механизм. Но упрямая википедия немного ввела в диссонанс, сообщив что:

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


Решил не спорить с ней и написал в статье как написано там.
Хотя в той же вики написанно

на практике применяется другая схема управления паролями, которая делает протокол Kerberos гораздо более эффективным


Возможно речь идёт о механизме сеансовых мандатов, о которых, как я понимаю вы и говорите.
Спасибо, пробежался подиагонали, действительно очень доходчиво)
Это все, конечно, замечательно, но держать в продукиве апач только ради SSO как-то не охота. А nginx, когда я последний раз смотрел, с керберосом особо не дружил.
Приходится пользователям немного страдать все еще…
А что поделаешь? Альтернатива — либо за (не столь существенный на мой взгляд) прирост производительности отказаться от Apache в пользу nginx, но это значит отказаться от Kerberos (а это не только SSO, это в принципе безопасная аутентификация), либо ставить OTRS на IIS, а тут вам ещё и прожорливую графику придется держать и за лицензию платить)
Так что из трех зол, как говорится.
Хотя кто-то ради пары освобожденных мегабайт оперативки на сервер готов заставить по несколько раз вводить пароли тысячный штат организации, держать в актуальном состоянии соответствующую базу и восстанавливать по 10-20 забытых паролей в день.
На мой взгляд дискуссия на тему SSO но на Apache или на nginx но без SSO, не имеет смысла. Ответ очевиден.
^(.+?)@.+?$

Я и сам опасаюсь магии регулярок, особенно когда её надо понять и модифицировать, но по сравнению с магией — это детский спиритический сеанс. Символы ^ и $ обозначают начало и конец строки. Значит, вся строка целиком должна подпадать под структуру. Символ "." (точка) обозначает любой текстовый символ. Символ + обозначает, что предыдущих групп символов будет не менее одной. Далее, у нас есть такая последовательность .+? — это значит, что должно быть, как наверное, уже понятно — хотя бы один символ. Чем точнее описание искомой структуры, тем с большей вероятностью регулярное выражение его удовлетворит. Если мы рассмотрим ^.+?@.+?$, то это точно покрывает, например, строку «vasya.p@mail.ru», потому что у нас в строке есть @, до него идёт более 1 текстового символа, так же, как и после него. Последнее, (.+?) — это то, что надо вычленить из обрабатываемой строки и вернуть, поэтому ^(.+?)@.+?$ вернет нам из примера «vasya.p».
Я же говорю, МААААГИИИИЯЯЯ)
При это вполне понятная мне конструкция типа username = replace(username,'@DOMAIN.RU') хоть ты тресни, не прокатывает.
Only those users with full accounts are able to leave comments. Log in, please.