Самый простой способ реализовать это - использовать wsHttpBinding с такой конфигурацией:
<bindings>
<wsHtttpBinding>
<binding name="securitySession">
<security mode="Message">
<message clientCredentialType="UserName"
establishSecurityContext="true"
negotiateServiceCredentials="false" />
</security>
</binding>
</wsHttpBinding>
</binding>
Эта привязка настраивает полное обслуживание состояния с сеансом безопасности.Если ваши клиенты создают прокси-сервер для службы, он должен передать имя пользователя и пароль в начальном рукопожатии безопасности, выполненном внутри.Во время этого рукопожатия WCF создает экземпляр службы, связанный с маркером безопасности.Маркер безопасности передается обратно клиентскому прокси, и прокси хранит его внутри.Все последующие вызовы из того же экземпляра прокси-сервера содержат этот токен, который аутентифицирует их и связывает их с правильным экземпляром службы.
Чтобы эта конфигурация работала в настраиваемой среде, необходимо настроить службу для использования сертификата, который будет защищать связь (в противном случаекто угодно может перехватить связь и ввести имя пользователя и пароль или токен).Вы также должны использовать пользовательский валидатор имени пользователя и пароля (или членство в ASP.NET) на стороне службы.
Как это соответствует вашему решению?
Ваш ASP.NET приложение может использовать пользовательскую форму аутентификации, используя сервис для запуска сеанса безопасности.На стороне ASP.NET вам нужно будет сохранить прокси в сеансе ASP.NET, а тайм-ауты для безопасности и сеанса ASP.NET должны быть правильно настроены так, чтобы срок сеанса ASP.NET истекал до сеанса безопасности WCF.Вы будете использовать cookie для получения правильного сеанса ASP.NET для последующих клиентских вызовов.
В своем приложении WPF вы можете использовать тот же подход и сохранять прокси для каждого запуска приложения.Вы просто должны убедиться, что прокси-сервер не будет превышать время ожидания или обработать время ожидания, и снова войти в систему.Клиентские машины также должны будут доверять сертификату, используемому вашей службой.
В случае WPF вы также можете избежать сеанса безопасности и выставить вторую оконечную точку своей службы с помощью establishSecurityContext="false".В этом случае имя пользователя и пароль будут включены в каждый вызов из приложения WPF, и вам не придется бороться со многими проблемами, связанными с долгоживущим прокси-сервером, используя полный сервис состояния.Без контекста службы безопасности для вашего приложения WPF будет меньше состояния.Причина, по которой вы не хотите использовать это с ASP.NET, заключается в том, что вам придется хранить имя пользователя и пароль в сеансе.
Каковы недостатки этого решения?
Это решение с большим весом.Контекст безопасности обеспечивает функциональность, которую вы ищете, без какого-либо кодирования на вашей стороне, но это имеет свою цену.Вам придется использовать сессию в приложении ASP.NET для поддержки прокси-сервера WCF, у вас будет полный сервис состояния, чего обычно следует избегать, и вам придется много работать с настройками производительности и памяти, если вы ожидаете большой нагрузки в вашем приложении.,Вы должны будете следить за тем, чтобы сеансы были корректно освобождены, а все прокси-серверы WCF были правильно закрыты и расположены так, чтобы экземпляры служб также освобождались.Вам придется поиграть с регулированием в WCF, чтобы поддерживать достаточно одновременно работающих экземпляров службы.
4 года назад я успешно использовал аналогичный подход в веб-приложении для Интернета с большой нагрузкой, но нам потребовалось некоторое время, чтобы найти все проблемы, правильно настроить все таймауты и правильно обработать освобождение всех объектов.
В качестве альтернативы вы можете найти федеративный сценарий, в котором у вас будет одна дополнительная служба, обрабатывающая аутентификацию и предоставляющая маркер безопасности, который будет использоваться для аутентификации в вашем приложении ASP.NET и вашей службе WCF.Я думаю, что OAuth должен справиться и с этим сценарием.