Протоколы обмена сообщениями
Далее описаны протоколы взаимодействия клиента и сервера и используемые при этом типы сообщений.
Протокол службы аутентификации.
Протокол службы аутентификации предназначен для обмена информацией между клиентом и сервером аутентификации (AS) Kerberos. Обычно обмен инициируется клиентом при попытке получения на сервере некоторой информации для идентификации. Для шифрования и дешифрования используется секретный ключ клиента! Этот протокол обычно применяется при инициализации сеанса входа в систему для получения информации идентификаций на TGS-сервере, который впоследствии будет использован для получения идентификационной информации других серверов без применения секретного ключа клиента.
Также протокол службы аутентификации может быть использован для запроса идентификационной информации у служб, доступ к которым не может быть получен с помощью службы выдачи билетов, а требует применения секретного ключа партнера по обмену данными. К таким службам относится, например, служба изменения пароля. Запрос на изменение пароля не может быть удовлетворен до тех пор, пока клиент не сообщит свой старый пароль – текущий секретный пароль пользователя, – иначе любой пользователь мог бы сменить чужой пароль.
Протокол службы аутентификации по сути никак не идентифицирует пользователя. Для аутентификации пользователя, входящего в локальную систему, идентификационная информация, полученная по протоколу службы аутентификации, сначала может быть использована при обмене с TGS-сервером для получения идентификационной информации локального сервера, о достоверности которой говорит успешное установление соединения между клиентом и локальным сервером.
Протокол службы аутентификации состоит из двух сообщений: KRB_, AS_REQ, отправляемого от клиента серверу Keiberos, и KRB_AS_REP или KRB_ERROR, приходящего в ответ.
Запрос, посылаемый клиентом в открытом текстовом формате, содержит свой собственный идентификатор и идентификатор сервера, для которого необходимо получить идентификационную информацию. Сообщение ответа, KRB_AS_REP, содержит билет, предназначенный для клиента, который необходимо представить серверу, и ключ сеанса, который является общим для клиента и сервера. Ключ сеанса и дополнительная информация зашифровываются с помощью секретного ключа клиента. Сообщение KRB_AS_REP содержит информацию, которая может быть использована для обнаружения отправки заранее перехваченных копий и ассоциирования ее с сообщением, в ответ на которое она была послана. При возникновении ошибок вместо KRB_AS_REP посылается сообщение KRB_ERROR. Сообщение об ошибке не шифруется. Информация сообщения позволяет ассоциировать его с соответствующим запросом, но отсутствие шифрования не позволяет обнаружить факт подмены таких сообщений.
— Регулярная проверка качества ссылок по более чем 100 показателям и ежедневный пересчет показателей качества проекта.
— Все известные форматы ссылок: арендные ссылки, вечные ссылки, публикации (упоминания, мнения, отзывы, статьи, пресс-релизы).
— SeoHammer покажет, где рост или падение, а также запросы, на которые нужно обратить внимание.
SeoHammer еще предоставляет технологию Буст, она ускоряет продвижение в десятки раз, а первые результаты появляются уже в течение первых 7 дней. Зарегистрироваться и Начать продвижение
Как правило, сервер аутентификации не знает, является ли клиент, приславший запрос, тем партнером по обмену данными, имя которого указано в запросе. Сервер просто посылает ответ. Его не интересует, кому он передает информацию. Это допускается, поскольку никто, кроме партнера по обмену данными, идентификатор которого указан в запросе, не сможет использовать ответ, т. к. вся информация зашифрована с помощью секретного ключа партнера, пославшего запрос. Первоначальный запрос содержит необязательное поле, которое может служить для передачи дополнительной информации, необходимой при инициировании обмена информацией.
Протокол аутентификации клиента и сервера.
Протокол аутентификации клиента и сервера используется сетевыми приложениями для аутентификации клиента на сервере и наоборот. Для успешного выполнения аутентификации клиент должен заранее получить с помощью службы выдачи билетов или TGS информацию идентификации сервера.
Протокол выдачи билетов.
Протокол выдачи билетов предназначен для обмена информацией между клиентом и сервером Kerberos, выдающим билеты (TGS). Он инициируется клиентом При необходимости получить информацию идентификации для определенного сервера (который может быть зарегистрирован в удаленном владении). С помощью полученной информации клиент сможет проверить или обновить существующий билет или получить proxy-билет. В первом случае клиент должен заранее получить билет с помощью службы выдачи билетов ТОТ. Обычно такой билет клиент получает при первоначальной аутентификации в системе, например при входе в систему. Формат сообщения протокола выдачи билетов практически совпадает с форматом сообщений протокола службы аутентификации.
Основное различие в том, что шифрование и дешифрование информации в протоколе выдачи билетов выполняются без использования ключа клиента. Вместо него используется ключ сеанса, находящийся в билете на получение билета, или ключ субсеанса, находящийся в аутентификаторе. Как в случае серверов приложений, билеты, срок действия которых истек, не принимаются в TGS. Поэтому после того как время работы обновляемого билета или билета на получение билета истекло, клиент должен с использованием специального протокола получить работоспособный билет.
— Разгрузит мастера, специалиста или компанию;
— Позволит гибко управлять расписанием и загрузкой;
— Разошлет оповещения о новых услугах или акциях;
— Позволит принять оплату на карту/кошелек/счет;
— Позволит записываться на групповые и персональные посещения;
— Поможет получить от клиента отзывы о визите к вам;
— Включает в себя сервис чаевых.
Для новых пользователей первый месяц бесплатно. Зарегистрироваться в сервисе
Протокол выдачи билетов состоит из двух сообщений: запрос от клиента к серверу Kerberos, выдающему билеты, – KRB_TGS_REQ – и ответ на этот запрос – KRB_TGS_REP или KRB_ERROR. Сообщение KRB_TGS_REQ несет информацию, аутентифицирующую пользователя, а также запрос на идентификационную информацию. Информация аутентификации содержит заголовок аутентификации (KRB_AP_REQ), включающий предварительно полученный клиентом билет на получение билета, обновляемый или неработоспособный билет. Если передается билет на получение билета, запрос может включать следующую дополнительную информацию: список сетевых адресов, набор типизированных данных авторизации, которые должны быть помещены в билет для дальнейшего использования в процессе авторизации сервером приложения, или дополнительные билеты.
Сообщение KRB_TGS_REP содержит запрошенную информацию идентификации, зашифрованную с помощью ключа сеанса, находящегося в билете на получение билета или в обновляемом билете, или с помощью ключа субсеанса, находящегося в аутентификаторе. Сообщение KRB_ERROR содержит код ошибки и текстовое объяснение причины ее возникновения. Это сообщение не шифруется. В сообщении KRB_TGS_REP находится информация, позволяющая обнаружить факт посылки заранее перехваченной копии данных, а также ассоциировать ответ с вызвавшим его запросом. Информация сообщения KRB_ERROR тоже позволяет ассоциировать его с соответствующим запросом, но отсутствие шифрования не позволяет обнаружить факт подмены таких сообщений.
Протокол KRB_SAFE.
Сообщение KRB_SAFE используется клиентами при необходимости обнаружения несанкционированной модификации сообщений, которыми они обмениваются. Модификация сообщений обнаруживается с помощью подсчета контрольной суммы данных пользователя и дополнительной контрольной информации. Контрольная сумма шифруется с помощью специального ключа, который выбирается в результате переговоров, или с помощью ключа сеанса.
Протокол KRB_PRIV.
При помощи сообщения KRB_PRIV клиенты при необходимости передают чрезвычайно конфиденциальные данные и обнаруживают несанкционированную модификацию сообщений. Это делается с помощью подсчета контрольной суммы данных пользователя и дополнительной контрольной информации.
Протокол KRB_CRED.
Сообщение KRB_CRED используется клиентами при необходимости отправки информации идентификации Kerberos от одного хоста другому хосту. Этот протокол предполагает отправку билетов вместе с зашифрованными данными, содержащими ключи сеанса и другую информацию, ассоциированную с билетами.