Привет

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

гугл дал кучу примеров как использовать сертификаты, а на мой вопрос так ничего и не ответил

Здравствуйте, shurik., Вы писали:

S>т.е. я хочу чтобы вызывать методы сервиса могли только несколько пользователей.
Зависит от конкретного биндинга.
http://wcfsecurity.codeplex.com

Конкретнее — http://wcfsecurity.codeplex.com/wikipage?title=Know%20your%20authentication%20options&referringTitle=Guidelines

S>Ну и соответственно как на клиенте указать под каким пользователем конектиться (желательно не используя имперсонацию)?
http://stackoverflow.com/questions/975894/impersonate-client-identity-in-wcf-w-nettcpbinding

P.S. WCF особо не занимаюсь. Потребовалось 5 минут гугля.

Здравствуйте, shurik., Вы писали:

S>а как вам такой вопрос — как разрешить общаться с сервисом только конкретным пользователем домена? т.е. я хочу чтобы вызывать методы сервиса могли только несколько пользователей. Ну и соответственно как на клиенте указать под каким пользователем конектиться (желательно не используя имперсонацию)?

То есть "конектиться", вдобавок, нужно не от имени текущего пользователя, а от какого-то другого? А с чем это связано?

Здравствуйте, _FRED_, Вы писали:

_FR>То есть "конектиться", вдобавок, нужно не от имени текущего пользователя, а от какого-то другого? А с чем это связано?

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

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, shurik., Вы писали:

S>>т.е. я хочу чтобы вызывать методы сервиса могли только несколько пользователей.
S>Зависит от конкретного биндинга.
S>http://wcfsecurity.codeplex.com

книгу видел, скачал. просмотрел... там всего и много, может где-нибудь и есть ответ на мой вопрос, но я не нашёл

S>Конкретнее — http://wcfsecurity.codeplex.com/wikipage?title=Know%20your%20authentication%20options&referringTitle=Guidelines
хм..
как мне задать пользователей сервиса там не написано 8)

я бы хотел видеть что-нибудь типа такого

MyService svc = new MyService();
svc.AllowedUsers.Add(...);
svc.AllowedUsers.Add(...);

вместо это я везде вижу конфиги xml, сертификаты и т.п.


S>>Ну и соответственно как на клиенте указать под каким пользователем конектиться (желательно не используя имперсонацию)?
S>http://stackoverflow.com/questions/975894/impersonate-client-identity-in-wcf-w-nettcpbinding

Похоже то что надо...

S>P.S. WCF особо не занимаюсь. Потребовалось 5 минут гугля.

Спасибо 8)

Здравствуйте, shurik., Вы писали:

_FR>>То есть "конектиться", вдобавок, нужно не от имени текущего пользователя, а от какого-то другого? А с чем это связано?

S>скажем так — клиент может быть сервисом виндовс, запущенным от имени локал систем.

В таком случае нужно откуда-то знать некий пароль (пользователя, которому разрешено подключаться). Как вы предполагаете его узнавать? Передавать в открытом или зашифрованном виде через конфигурацию? Нет, секьюрно этого не сделать.

Кстати, а чем вызвано "(желательно не используя имперсонацию)?"

Здравствуйте, _FRED_, Вы писали:

S>>скажем так — клиент может быть сервисом виндовс, запущенным от имени локал систем.
_FR>В таком случае нужно откуда-то знать некий пароль (пользователя, которому разрешено подключаться). Как вы предполагаете его узнавать? Передавать в открытом или зашифрованном виде через конфигурацию? Нет, секьюрно этого не сделать.
на самом деле я просто так про сервис написал, думал после этого вопросы "зачем так делать" отпадут (хотя и такой вариант возможен, тогда будем шифрованный хранить в реестре). ну вобщем нужно креды явно указывать и всё тут 8)

_FR>Кстати, а чем вызвано "(желательно не используя имперсонацию)?"
да ничем, фаза луны на меня сегодня так повлияла, что сегодня не хочется мне имперсонации.. я же написал "желательно".
Но вообще с этим вопросом разобрались.. хочется узнать как сервер научить пускать только ограниченный круг лиц и вообще разобраться с аутентификацией (сейчас он у меня даже юзера запустившего сам сервис не пускает).
и чтобы без конфиг файлов, сертификатов и прочих модных штук. просто в коде сказать сервису — пускай этого и этого. всё. разве я так много хочу?

Здравствуйте, shurik., Вы писали:

S>>>скажем так — клиент может быть сервисом виндовс, запущенным от имени локал систем.
_FR>>В таком случае нужно откуда-то знать некий пароль (пользователя, которому разрешено подключаться). Как вы предполагаете его узнавать? Передавать в открытом или зашифрованном виде через конфигурацию? Нет, секьюрно этого не сделать.
S>на самом деле я просто так про сервис написал, думал после этого вопросы "зачем так делать" отпадут (хотя и такой вариант возможен, тогда будем шифрованный хранить в реестре). ну вобщем нужно креды явно указывать и всё тут 8)

То есть, настоящей секьюрности вам не надо, ибо подобные проверки не сказать, что бы являются защитой по-взрослому? ОК.

_FR>>Кстати, а чем вызвано "(желательно не используя имперсонацию)?"
S>да ничем, фаза луны на меня сегодня так повлияла, что сегодня не хочется мне имперсонации.. я же написал "желательно".
S>Но вообще с этим вопросом разобрались.. хочется узнать как сервер научить пускать только ограниченный круг лиц и вообще разобраться с аутентификацией (сейчас он у меня даже юзера запустившего сам сервис не пускает).
S>и чтобы без конфиг файлов, сертификатов и прочих модных штук. просто в коде сказать сервису — пускай этого и этого. всё. разве я так много хочу?

И при этом обязательно нужно разграничевать пользователей как доменных?

Вообще, с таким подходом: "на самом деле я просто так про сервис написал", "фаза луны на меня сегодня так повлияла, что сегодня не хочется мне имперсонации" каши [не то что вкусной, даже полезной] не сварить. Лучшее, что можно посоветовать, это почитать что-нибудь теоритическое на тему WCF и аутентификации/авторизации вообще Что бы понять, что именном нужно и для чего. А потом уже можно подумать над тем, как.

Здравствуйте, shurik., Вы писали:

S>как мне задать пользователей сервиса там не написано 8)
Вы сначала определитесь с биндингом. Потом останется почитать документацию — и всё станет ясно

S>я бы хотел видеть что-нибудь типа такого
S>вместо это я везде вижу конфиги xml, сертификаты и т.п.
Я ещё раз повторю: настройки зависят от конкретного биндинга. Для NetTcpIp — http://msdn.microsoft.com/en-us/library/system.servicemodel.nettcpbinding.security.aspx

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, shurik., Вы писали:

S>>>>скажем так — клиент может быть сервисом виндовс, запущенным от имени локал систем.
_FR>>>В таком случае нужно откуда-то знать некий пароль (пользователя, которому разрешено подключаться). Как вы предполагаете его узнавать? Передавать в открытом или зашифрованном виде через конфигурацию? Нет, секьюрно этого не сделать.
S>>на самом деле я просто так про сервис написал, думал после этого вопросы "зачем так делать" отпадут (хотя и такой вариант возможен, тогда будем шифрованный хранить в реестре). ну вобщем нужно креды явно указывать и всё тут 8)

_FR>То есть, настоящей секьюрности вам не надо, ибо подобные проверки не сказать, что бы являются защитой по-взрослому? ОК.

предлагаю на этом вопросе остановится поподробней, не в контексте этой задачи
имеем WCF или любой другой сервер, который требует виндовс аутентификации. Ещё имеем клиента (пусть он будет в виде сервиса виндовс). По вашему хранить зашифрованные креды это не по взрослому. А как по другому? сервису (который может быть запущен под кем угодно) по любому откуда-то эти креды нужно взять. Как тогда эта задача решается по взрослому? или вы имеете ввиду, что сама такая архитектура неверная с точки зрения секъюрити? а какая тогда верная? я это не из-за сарказма спрашиваю, просто может действительно я что-то упустил.

Здравствуйте, shurik., Вы писали:

_FR>>То есть, настоящей секьюрности вам не надо, ибо подобные проверки не сказать, что бы являются защитой по-взрослому? ОК.

S>предлагаю на этом вопросе остановится поподробней, не в контексте этой задачи
S>имеем WCF или любой другой сервер, который требует виндовс аутентификации. Ещё имеем клиента (пусть он будет в виде сервиса виндовс). По вашему хранить зашифрованные креды это не по взрослому. А как по другому? сервису (который может быть запущен под кем угодно) по любому откуда-то эти креды нужно взять. Как тогда эта задача решается по взрослому? или вы имеете ввиду, что сама такая архитектура неверная с точки зрения секъюрити? а какая тогда верная? я это не из-за сарказма спрашиваю, просто может действительно я что-то упустил.

По взрослому не бывает, что "сервис … может быть запущен под кем угодно". Если сервису требуется обращаться куда-то от имени определённого пользователя, то почему сервис "может быть запущен под кем угодно" Нет, конечно, может, но — во всеми вытекающими (нужно самому заниматься расшифровками пароля и обеспечить, что бы никто не смог бы этого предотвратить). Проблема безопастности, описанная вами, есть административная задача и решаться должна соответствующим образом.

Если же вы уверены (и вам этого хочется или требуется), что вы сможете реализовать надёжность хранения/дешифровки не хуже операционной системы — делайте конечно. Если вам требуется лишь защита от чайника — делайте. Если вам требуется защита — научитель использовать то, что уже есть. Что может быть проще-то? Если у вас уже есть сервер, который разрешает подключаться только строго определённым пользователям — это уже довольно не слабое такое ограничение. По сравнению с ним требования указания пользователя для запуска сервиса — ерунда.

Далее. Почему бы вообще не диктовать адинам клиентов, как проверять и как раздавать права? Предоставьте администратору самому настроить, кто сможет подключаться к вашему серверу. Предоставьте администратору самому настроить, от имени кого будет запускаться клиентский сервис. Это самое простое, самое гибкое и самое надёжное решение.

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

Ещё примеры: при установке сервиса можно создавать группу в домене, пользователям которой будет разрешён доступ в серверу (тут я не уверен на счёт специлальных экаунтов). Или, на клиенте имеются два сервиса — один "под кем угодно" делает всё что угодно, второй "под тем кем надо" ходит на сервер. Первывй просит втрого "сходить" и отдать первому результат. Главное — во всех вариантах вы избавлены от необходимости знания и проверки credentials пользователя.