Comments 8
прежде чем обратиться к серверу, клиент посылает сообщение KDC, а KDC в свою очередь направляет каждому участнику сеанса копии сеансового ключа, действующие в течение небольшого промежутка времени.
Всё-таки KDC (TGS) не контактирует с двумя сторонами, когда клиент запрашивает соединение.
Клиент (принципал), чтобы проийти взаимную проверку подлинности с запрашиваемым ресурсом, отправляет запрос TGS-REQ в сторону TGS. В этом запросе содержатся TGT клиента и наименование запрашиваемого ресурса (servicePrincipalName, например, как и у вас в статье). TGS возвращает клиенту в ответ TGS-REP, в котором содержатся служебный билет и сеансовый ключ для сеанса между клиентом и ресурсом. А уж потом клиент делает запрос к ресурсу с этим билетом, в ходе которого клиент и ресурс проходят взаимную проверку подлинности.
TGS незачем что-то передавать ресурсу — всё есть в TGS-REP, и это довольно экономичное решение с точки зрения количества передаваемых данных.
А статья полезная. Лет 7 назад как подумывал об использовании Kerberos для OTRS, никогда руки не доходили.
Ни в коем случае не оспариваю ваше утверждение, более того, понимаю что так оно намного проще и должно быть. Ещё когда пытался разобраться с Kerberos, так себе и представлял этот механизм. Но упрямая википедия немного ввела в диссонанс, сообщив что:
Решил не спорить с ней и написал в статье как написано там.
Хотя в той же вики написанно
Возможно речь идёт о механизме сеансовых мандатов, о которых, как я понимаю вы и говорите.
Если клиент хочет обратиться к серверу, Он посылает сообщение KDC. KDC направляет каждому участнику сеанса копии сеансового ключа, действующие в течение небольшого промежутка времени. Назначение этих ключей – проведение аутентификации клиента и сервера
Решил не спорить с ней и написал в статье как написано там.
Хотя в той же вики написанно
на практике применяется другая схема управления паролями, которая делает протокол Kerberos гораздо более эффективным
Возможно речь идёт о механизме сеансовых мандатов, о которых, как я понимаю вы и говорите.
Есть отличная и доходчиво написанная статья о принципах работы Kerberos: Explain like I’m 5: Kerberos.
Это все, конечно, замечательно, но держать в продукиве апач только ради SSO как-то не охота. А nginx, когда я последний раз смотрел, с керберосом особо не дружил.
Приходится пользователям немного страдать все еще…
Приходится пользователям немного страдать все еще…
А что поделаешь? Альтернатива — либо за (не столь существенный на мой взгляд) прирост производительности отказаться от Apache в пользу nginx, но это значит отказаться от Kerberos (а это не только SSO, это в принципе безопасная аутентификация), либо ставить OTRS на IIS, а тут вам ещё и прожорливую графику придется держать и за лицензию платить)
Так что из трех зол, как говорится.
Хотя кто-то ради пары освобожденных мегабайт оперативки на сервер готов заставить по несколько раз вводить пароли тысячный штат организации, держать в актуальном состоянии соответствующую базу и восстанавливать по 10-20 забытых паролей в день.
На мой взгляд дискуссия на тему SSO но на Apache или на nginx но без SSO, не имеет смысла. Ответ очевиден.
Так что из трех зол, как говорится.
Хотя кто-то ради пары освобожденных мегабайт оперативки на сервер готов заставить по несколько раз вводить пароли тысячный штат организации, держать в актуальном состоянии соответствующую базу и восстанавливать по 10-20 забытых паролей в день.
На мой взгляд дискуссия на тему SSO но на Apache или на nginx но без SSO, не имеет смысла. Ответ очевиден.
^(.+?)@.+?$
Я и сам опасаюсь магии регулярок, особенно когда её надо понять и модифицировать, но по сравнению с магией — это детский спиритический сеанс. Символы ^ и $ обозначают начало и конец строки. Значит, вся строка целиком должна подпадать под структуру. Символ "." (точка) обозначает любой текстовый символ. Символ + обозначает, что предыдущих групп символов будет не менее одной. Далее, у нас есть такая последовательность .+? — это значит, что должно быть, как наверное, уже понятно — хотя бы один символ. Чем точнее описание искомой структуры, тем с большей вероятностью регулярное выражение его удовлетворит. Если мы рассмотрим ^.+?@.+?$, то это точно покрывает, например, строку «vasya.p@mail.ru», потому что у нас в строке есть @, до него идёт более 1 текстового символа, так же, как и после него. Последнее, (.+?) — это то, что надо вычленить из обрабатываемой строки и вернуть, поэтому ^(.+?)@.+?$ вернет нам из примера «vasya.p».
Я и сам опасаюсь магии регулярок, особенно когда её надо понять и модифицировать, но по сравнению с магией — это детский спиритический сеанс. Символы ^ и $ обозначают начало и конец строки. Значит, вся строка целиком должна подпадать под структуру. Символ "." (точка) обозначает любой текстовый символ. Символ + обозначает, что предыдущих групп символов будет не менее одной. Далее, у нас есть такая последовательность .+? — это значит, что должно быть, как наверное, уже понятно — хотя бы один символ. Чем точнее описание искомой структуры, тем с большей вероятностью регулярное выражение его удовлетворит. Если мы рассмотрим ^.+?@.+?$, то это точно покрывает, например, строку «vasya.p@mail.ru», потому что у нас в строке есть @, до него идёт более 1 текстового символа, так же, как и после него. Последнее, (.+?) — это то, что надо вычленить из обрабатываемой строки и вернуть, поэтому ^(.+?)@.+?$ вернет нам из примера «vasya.p».
Sign up to leave a comment.
OTRS 4.0.10. Ставим на Ubuntu + AD + Kerberos + SSO (Часть первая)