Избегайте установки учетных данных клиента для каждого веб-вызова - PullRequest
0 голосов
/ 14 апреля 2011

Я сейчас пользуюсь безопасностью, и мне приходится устанавливать ClientCredentials до моих веб-звонков.

Это повторяющаяся вещь, поскольку у меня много веб-звонков, всегда проходящих одну и ту же вещь.

Чтохороший шаблон, чтобы избежать необходимости делать подобные вещи?

Ответы [ 2 ]

2 голосов
/ 14 апреля 2011

WCF реализует WS-SecureConversation.Это позволяет клиенту передавать учетные данные только один раз, и последующие вызовы автоматически используют маркер безопасности, сгенерированный безопасным рукопожатием между клиентом и службой.В WCF это называется контекстом безопасности или сеансом безопасности, и обычно оно включено по умолчанию в wsHttpBinding.При использовании контекста безопасности вы должны следовать основным правилам:

  • Ваш сервис стал экземпляром за сеанс, поэтому он является долгоживущим экземпляром сервиса, и вы должны устранить все недостатки и проблемы, связанные с истечением сеанса и т. Д.1006 * Сеанс безопасности создается между одним экземпляром прокси-клиента и экземпляром службы, поэтому он работает, только если вы используете один и тот же прокси-сервер.Если вы создаете новый прокси-сервер, вы должны отправить учетные данные еще раз, чтобы начать безопасный разговор.
  • Первый вызов службы выполняется медленнее из-за установления контекста безопасности.

Если вы не придерживаетесь этого подходаВы можете, например, реализовать пользовательский заголовок SOAP и инспектор сообщений, который будет включать заголовок на стороне клиента и проверять заголовок на стороне сервера.Это решение полностью выходит за рамки безопасности WCF и не может сочетаться с общим именем пользователя и паролем в WCF.Вы также должны отправить имя пользователя и пароль отдельно.

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

Но, как я понимаю, ваша проблема не в том, чтобы устанавливать учетные данные перед каждым вызовом - это означает, что вы используете новый прокси для каждого вызова.Таким образом, вы напишете много кода, в результате чего вам не нужно будет задавать имя пользователя и пароль для последующих вызовов, но вам придется устанавливать собственный токен, который будет проверяться в службе.Вам также придется управлять этими токенами в службе.

Вероятно, должно быть проще создать оболочку для вызова веб-службы, которая установит имя пользователя и пароль.

1 голос
/ 14 апреля 2011

Хорошим примером является отправка токена сеанса из службы клиенту после авторизации, а затем отправка его при каждом вызове вместо учетных данных.

...