Аутентификация в SIP |
|
Протокол SIP обеспечивает для аутентификации stateless-механизм на основе запроса аутентификации, который базируется на принципах аутентификации для протокола HTTP Всегда, когда прокси-сервер или UA получает запрос (кроме исключений, описываемых ниже), он может потребовать от инициатора запроса удостоверить свою подлинность. Для удостоверения подлинности в протоколе SIP определен только один механизм - аутентификация на базе схемы «Digest». Дело в том, что в соответствии с последней рекомендацией для протокола SIP схема «Basic» ввиду своей недостаточной безопасности была запрещена для использования. Серверы не должны принимать значения отклика аутентификации, использующие схему аутентификации «Basic», а также не должны запрашивать аутентификацию с использованием этой схемы. В протоколе SIP UAS использует ответ с кодом 401 (Unauthorized) для того, чтобы запросить аутентификацию UAC. Кроме того, registrar и сервер переаД' ресации могут использовать для запроса аутентификации ответ с кодом 40 (Unauthorized), а прокси-серверы - нет; вместо этого они могут использовать о вет с кодом 407 (Proxy Authentication Required). Во время прохождения процедуры аутентификации должна быть четко определена область аутентификации, т.е. та область, для доступа к которой клиент должен передать отклик аутентификации. Область указывается в поле realm запроса аутентификации, переданного сервером клиенту. Для удобства к значению поля realm предъявляются следующие требования:
Например: INVITE sip: This e-mail address is being protected from spambots, you need JavaScript enabled to view it SIP/2.0 Authorization: Digest realm=«bamlex.com», <...> Каждая область аутентификации имеет свой список имен пользователя (usernames) и паролей (passwords). Если сервер не требует аутентификации для определенного запроса, он может по умолчанию принять имя пользователя «anonymous» и не требовать пароля. Подобным образом, клиенты агента пользователя, представляющие многих пользователей, такие как шлюзы ТфОП, могут иметь свое собственное, зависящее от устройства имя пользователя и пароль для их области. Когда UAC получает запрос подтверждения подлинности, он должен отобразить пользователю содержимое поля realm, содержащегося в нем, если программному модулю UAC не известно значение отклика аутентификации для области, указанной в запросе аутентификации. Несмотря на то, что сервер может запрашивать проведение процедуры аутентификации при поступлении большинства SIP-запросов, существуют два запроса, требующие особого похода к решению задачи аутентификации, - АСК и CANCEL. При использовании схемы аутентификации, использующей ответы для переноса запроса процедуры аутентификации (например, схемы «Digest»), могут возникнуть трудности для запросов, на которые не приходит ответ; на данное время таким запросом является АСК. По этой причине любое значение отклика аутентификации в запросе INVITE, который был принят сервером, должен быть принят тем же сервером и для подтверждения АСК. Клиенты агента пользователя, создающиесообщение АСК, продублируют значения всех полей заголовков Authorization и Proxy-Authorization запроса INVITE, в которых содержатся отклики аутентификации. Серверы не должны пытаться запрашивать аутентификацию при получении подтверждения АСК. Несмотря на то, что на сообщение CANCEL приходит ответ, серверы также не должны запрашивать значение отклика аутентификации при получении запросов этого типа, так как они не могут быть переданы заново. Если сервер получает верное значение отклика аутентификации, процедура аутентификации успешно завершается. Если же значение отклика не является действительным, или сервер, требующий подтверждения подлинности, не принимает значение отклика по какой-либо другой причине, сервер может повторить свой запрос или передать ответ с кодом 403 (Forbidden). UAC не должен повторно пытаться передавать запрос со значением отклика аутентификации, которое было отклонено. |

