Проблемы безопасности WCF с именованными каналами

У меня есть немного сложная настройка, которая, конечно, прекрасно работает в XP, но задыхается на Windows 7. Это может показаться безумием, но в то время это имело смысл!

У меня есть приложение WPF, которое запускает, а затем запускает другое приложение, которое связывается с внешним устройством. После запуска он устанавливает связь с новым процессом, используя WCF (размещенный новым процессом) через именованный канал (net.pipe). Кажется, это работает нормально на любой ОС.

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

Затем я хотел сделать функциональность приложения WPF доступной через Интернет. Теперь важно, чтобы приложение WPF можно было запускать из учетной записи обычного пользователя, поэтому я подумал, что лучшим способом заставить эту работу работать в Windows 7 было бы создание службы Windows, которая обеспечила бы часть веб-службы и обеспечивала бы ее обратную связь. в приложение WPF через тот же именованный канал, который отлично работает для командной строки. Я реализовал это, и он работает нормально на XP, но он задыхается на Windows 7. Проблемаseems быть при попытке установить соединение именованного канала между службой Windows и приложением WPF.

Если я запускаю приложение WPF от имени администратора, оно работает нормально. Таким образом, представляется, что проблема с учетной записью, в которой запущена служба Windows, не может связываться с обычной учетной записью пользователя, которая размещает службу WCF через именованные каналы. Есть ли способ сделать эту работу? Кажется, что служба WCF, работающая в учетной записи обычного пользователя, может связываться с помощью именованных каналов с другим приложением, работающим в той же учетной записи, но, похоже, она не может делать то же самое с другой учетной записью.

Как ни странно, наоборот работает. Служба Windows фактически также предоставляет службу с привязкой именованного канала (она используется в качестве функции активации, поскольку служба работает все время). Я могу без проблем подключиться из приложения WPF к этому сервису.

Мои знания о безопасности несколько ограничены. Кто-нибудь может пролить свет на то, что происходит?

Ответы на вопрос(2)

Приложения (WPF / Console) создают именованные каналы локальной области (это происходит по умолчанию, когда они не могут создавать каналы глобальной области действия). Я предполагаю, что они могут общаться друг с другом, потому что они могут видеть друг друга именованными каналами, потому что они работают под одной учетной записью.

Служба Windows имеет более высокие привилегии и поэтому может создать именованный канал глобальной области видимости для клиентских приложений.

Вы можете проверить обсуждение наБлог Кристиана Вейера.

 Matt Burland24 апр. 2012 г., 17:41
Спасибо за ссылку. Я думаю, что вы правы и определили, в чем проблема. Теперь вопрос в том, есть ли решение? Считая, что единственный способ продвинуться вперед - это полностью изменить ситуацию и подключить хост службы Windows и приложение WPF. Но проблема в том, что именно приложение WPF должно в конечном итоге отвечать на веб-запросы.
Решение Вопроса

Этот вопрос был задан несколько раз ранее на SO. Например, см.Подключение через именованный канал от службы Windows к настольному приложению

Проблема состоит в том, что ваши пользовательские сеансовые приложения не обладают привилегией безопасности SeCreateGlobalPrivilege, необходимой для того, чтобы они могли создавать объекты в глобальном пространстве имен ядра, видимом для других сеансов, но только в локальном пространстве имен, которое видно только внутри сеанса. С другой стороны, службы, которые по умолчанию работают с этой привилегией, могут это делать.

Таким образом, не сам объект именованного канала ограничен локальным пространством имен, а другой именованный объект ядра, раздел с общей памятью, на который опирается привязка именованного канала WCF для публикации своим клиентам фактического имени объекта. канал, который представляет собой GUID, который изменяется каждый раз при запуске службы.

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

Ваш ответ на вопрос