Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

Клиент RPC посылает запросы серверу и получает ответы на них в специальных сообщениях. Что должны содержать эти сообщения, чтобы клиент и сервер поняли друг друга?

Необходим идентификатор транзакции, определяющий соответствие между запросом и ответом. Запрос клиента должен указывать программу и процедуру, которую он хочет запустить. Клиенту необходим некоторый способ идентифицировать себя через мандат (credentials), доказывающий право использования службы. Наконец, запрос клиента должен содержать входные параметры. Например, запрос чтения NFS должен идентифицировать файл и количество читаемых байтов.

В дополнение к сообщению о результатах успешных запросов серверу необходим способ сообщения клиенту об отмене запроса и причинах такой отмены. Запрос может быть отклонен при несоответствии версий программы или ошибке при аутентификации клиента. Сервер должен сообщить об ошибках в параметрах или событиях, например: "Не могу найти файл".

На рис. 15.5 показано взаимодействие клиента с программой сервера. Клиент посылает запрос. Когда работа затребованной процедуры завершается, серверная программа возвращает ответ. Как видно из рис. 15.5, запрос включает:

■ Идентификатор транзакции

■ Текущий номер версии RPC

■ Номер программы

■ Версию программы

■ Номер процедуры

■ Мандат аутентификации

■ Проверочные сведения (verifier) аутентификации

■ Входные параметры

Рис. 15.5.Сообщения RPC

Если процедура выполнена успешно, ответ содержит результаты. Если при выполнении выявлены проблемы, ответ будет содержать информацию об ошибках.

Некоторые службы не нуждаются в защите. Для вывода времени дня на сервере служба RPC может быть оставлена открытой для общего доступа. Однако клиент, обращающийся к личным данным, должен обеспечить некоторую опознавательную информацию (проходить аутентификацию). В некоторых случаях важно, чтобы сервер также подтверждал свою подлинность. Не следует посылать номер своей кредитной карточки через систему интерактивных заказов, если не будет гарантии в подлинности сервера. Таким образом, в некоторых случаях аутентификационные данные должен предоставлять как клиент, так и сервер (они будут как в запросах, так и в ответах).

В сообщении запроса аутентификационные сведения RPC пересылаются в двух полях:

■ Поле мандата (credentials) — содержит идентификационную информацию.

■ Поле проверочных сведений аутентификации (verifier) — содержит дополнительную информацию и позволяет проверить идентификатор. Например, verifier мог бы содержать зашифрованный пароль и штамп времени.

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

В настоящее время каждый метод аутентификации называется flavor (оттенок). Тип такого оттенка, используемый в мандатах или полях verifier, идентифицирован целым числом в начале поля. Новые типы аутентификации могут быть зарегистрированы таким же образом, что и новые программы. Поля мандата и verifier начинаются с целого числа.

Нулевая аутентификация полностью соответствует своему названию. Не используется никакой аутентификационной информации — в полях мандата и verifier сообщений запросов и ответов содержатся одни нули.

Аутентификация систем моделирует аналогичную информацию операционной системы Unix. Мандат системы содержит:

Поле проверочных сведений аутентификации — нулевое.

Проверочные сведения аутентификации (verifier), возвращаемые сервером, могут быть пустыми или иметь оттенок short (краткие), означающий возвращение октета, определяющего систему. В некоторых реализациях этот октет используется как мандат в последующем сообщении от вызывающей стороны (мандат будет заменять информацию о пользователе и его группе).