WCF реализует WS-SecureConversation.Это позволяет клиенту передавать учетные данные только один раз, и последующие вызовы автоматически используют маркер безопасности, сгенерированный безопасным рукопожатием между клиентом и службой.В WCF это называется контекстом безопасности или сеансом безопасности, и обычно оно включено по умолчанию в wsHttpBinding
.При использовании контекста безопасности вы должны следовать основным правилам:
- Ваш сервис стал экземпляром за сеанс, поэтому он является долгоживущим экземпляром сервиса, и вы должны устранить все недостатки и проблемы, связанные с истечением сеанса и т. Д.1006 * Сеанс безопасности создается между одним экземпляром прокси-клиента и экземпляром службы, поэтому он работает, только если вы используете один и тот же прокси-сервер.Если вы создаете новый прокси-сервер, вы должны отправить учетные данные еще раз, чтобы начать безопасный разговор.
- Первый вызов службы выполняется медленнее из-за установления контекста безопасности.
Если вы не придерживаетесь этого подходаВы можете, например, реализовать пользовательский заголовок SOAP и инспектор сообщений, который будет включать заголовок на стороне клиента и проверять заголовок на стороне сервера.Это решение полностью выходит за рамки безопасности WCF и не может сочетаться с общим именем пользователя и паролем в WCF.Вы также должны отправить имя пользователя и пароль отдельно.
Если вы хотите включить пользовательское решение в конвейер WCF, вы можете ожидать очень сложную задачу, потому что интеграция такого решения в конвейер безопасности WCF требует настраиваемой политики авторизации, cutom token, tokenменеджер, аутентификатор токена, распознаватель токена и учетные данные клиента.
Но, как я понимаю, ваша проблема не в том, чтобы устанавливать учетные данные перед каждым вызовом - это означает, что вы используете новый прокси для каждого вызова.Таким образом, вы напишете много кода, в результате чего вам не нужно будет задавать имя пользователя и пароль для последующих вызовов, но вам придется устанавливать собственный токен, который будет проверяться в службе.Вам также придется управлять этими токенами в службе.
Вероятно, должно быть проще создать оболочку для вызова веб-службы, которая установит имя пользователя и пароль.