Я сначала опишу, чтобы мне хотелось получить, а потмо надеюсь вы подскажете, что мне больше подходит.
Есть методы службы, мне бы хотелось ограничить круг лиц, которые могли бы из вызывать. Например какие-то методы могут вызывать только зарегестрированные пользователи, каике-то только администраторы. ПРи этом информация о пользователях хранится в БД MySQL.
Вот вопрос, что посоветуете использовать.
Я несколько копался в МСДН по вопросам аутентификации и авторизации, но не совсем уверен, что правильно усвоил и остались не которые вопросы.
Вот как мне кажется, мне необходимо использовать авторизацию на основе ролей. Для этого мне необходжимо создать класс производный от RoleProvider (не проблема, считайте, что уже есть ), в файле web-config расскоментировать <roleService enabled="true"/>, также необходимо создать еще один файл svc (не совсем понял какое имя ему дать, или можно любое). В файле писать
<%@ ServiceHost Language="C#" Service="System.Web.ApplicationServices.RoleService" Factory="System.Web.ApplicationServices.ApplicationServicesHostFactory" %>
Далее надо создать обработчик событий SelectingProvider и в нем указать свой класс -поставщика ролей.


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

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

NdF>Я сначала опишу, чтобы мне хотелось получить, а потмо надеюсь вы подскажете, что мне больше подходит.

Может быть поможет доклад с techdays.ru про WCF Security ?

Можно сделать на основе WS Security, можно на основе claims, и т.п.

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

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

NdF>>Я сначала опишу, чтобы мне хотелось получить, а потмо надеюсь вы подскажете, что мне больше подходит.

G>Может быть поможет доклад с techdays.ru про WCF Security ?

G>Можно сделать на основе WS Security, можно на основе claims, и т.п.

Я видел эти доклады. Проблема в том, что почти везде рассматривается либо аутентификация Windows, либо Forms.
Мне не подходит ведь это. Служба будет висеть в сети Интернет на всеобщем обозрении, люди будут регистрироваться для работы с ней, вводя логин и пароль с любого компьютера, поэтому Windows аутентификация не подходит. Использование форм, как я понимаю, тоже мне не подходит, потому как клиентом службы будет диалог. Случай Form подходит при создании сайта.

Как я понимаю, WS Security в данном случае не обсуждается, потому что — это уже определение как будет защищаться канал, на уровне транспорта или сообщения или и там и там и т.д. . Меня же интересует именно механизм аутентификации (вроде как раз аутентификации, а не авторизации), т.е. порядок определение пользователя (кто он) и порядок предаствления ему прав (какие методы он может вызывать).
Пока думаю, что нужны роли, как я понимаю, это мне даст возможность над каждым методом службы выставлять аттрибут досутпа к этому методу, где я буду указывать какие роли могут его вызывать (декларативное обеспечение) или я смогу прямо в коде метода узнать роль пользователя и в соответсвии с этой ролью изменить логику метода (императивное). Меня это и устраивает.
Хотелось бы узнать, не ошибаюсь ли я, надо ли мне в этом случае реализовывать членства самому, правильно ли я понимаю процесс реализации ролей (то, что писал в первом посте)?

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

NdF>Я видел эти доклады. Проблема в том, что почти везде рассматривается либо аутентификация Windows, либо Forms.

Вечером пересмотрю, что-то мне кажется что все не совсем так.

NdF>Мне не подходит ведь это. Служба будет висеть в сети Интернет на всеобщем обозрении, люди будут регистрироваться для работы с ней, вводя логин и пароль с любого компьютера, поэтому Windows аутентификация не подходит. Использование форм, как я понимаю, тоже мне не подходит, потому как клиентом службы будет диалог.

Не очень понял про диалог, но ладно. Или вас смущает название Forms?

NdF>Как я понимаю, WS Security в данном случае не обсуждается, потому что — это уже определение как будет защищаться канал, на уровне транспорта или сообщения или и там и там и т.д. . Меня же интересует именно механизм аутентификации (вроде как раз аутентификации, а не авторизации), т.е. порядок определение пользователя (кто он) и порядок предаствления ему прав (какие методы он может вызывать).

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

NdF>Пока думаю, что нужны роли, как я понимаю, это мне даст возможность над каждым методом службы выставлять аттрибут досутпа к этому методу, где я буду указывать какие роли могут его вызывать (декларативное обеспечение) или я смогу прямо в коде метода узнать роль пользователя и в соответсвии с этой ролью изменить логику метода (императивное). Меня это и устраивает.

Для ответа на этот вопрос надо ответить на предыдущий. А вообще, механизм Membership и Roles для сайтов ASP.NET имеет достаточно недостатков, и немного устарел. Смысла прикручивать его к wcf-службе я не вижу.

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

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

NdF>>Я видел эти доклады. Проблема в том, что почти везде рассматривается либо аутентификация Windows, либо Forms.

G>Вечером пересмотрю, что-то мне кажется что все не совсем так.

Тоже еще раз гляну. Насколько я помню, по-моему вопросу там как раз первая часть.

NdF>>Мне не подходит ведь это. Служба будет висеть в сети Интернет на всеобщем обозрении, люди будут регистрироваться для работы с ней, вводя логин и пароль с любого компьютера, поэтому Windows аутентификация не подходит. Использование форм, как я понимаю, тоже мне не подходит, потому как клиентом службы будет диалог.

G>Не очень понял про диалог, но ладно. Или вас смущает название Forms?
Нет, смущает не название. Как я понял вся суть этого метода заключается в том, что создается страничка сайта и делается настройка, что эта страничка авторизации. Но у меня ведь не сайт, а клтиентский диалог (WinForms приложение), именно поэтому мне кажется, что этот метод не подходит. Во-первых эта страничка мне не нужна во все, потому как сервисом будут пользоваться только через клиента (WinForms приложение). А во-вторых, как это будет выглядеть, клиентское прилрожение будет посылать Post зыпрос этой страничке, чтобы провести регистрацию ..., почему-то кажется все это неубедительным, при условии, если я правильно понял этот метод.


NdF>>Как я понимаю, WS Security в данном случае не обсуждается, потому что — это уже определение как будет защищаться канал, на уровне транспорта или сообщения или и там и там и т.д. . Меня же интересует именно механизм аутентификации (вроде как раз аутентификации, а не авторизации), т.е. порядок определение пользователя (кто он) и порядок предаствления ему прав (какие методы он может вызывать).

G>Аутентификация — это первая часть, определить пользователя. Авторизация — предоставление доступа этому пользователю куда нужно и запрещение, куда не нужно, оно же проверка прав. Давайте начнем с первого, чтобы понять что вам нужно. Как вы собираетесь передавать логин-пароль (или аналоги) в ваш сервис? Откуда они будут браться, как вы собираетесь защищать эти данные при передаче, и т.п.
Представляю себе это примерно так. Запускается диалог авторизации, пользователь вводит логин и пароль, жмет ОК. Клиентское приложение вызывает метод аутентификации/авторизации (раз такая путаница, буду через слэш писать ), этот метод возвращает либо true/false, либо сразу объект класса пользователя в случае верных данных/null в случае ошибочных. Теперь пользователь хоет получить список товаров. Для этого требуется вызов метода сервиса "Получить товар". Этот метод могут вызывать только зарегестрированные пользователи. Т.е. если кто-то незарегестрированный попытается вызвать этот метод, то у него не должно ничего получиться (либо исключение, либо просто null). Пользователь захотел добавить товар, это может сделать не каждый пользователь, а только пользователь — администратор, соответсвенно пользователь должен им являться, иначе метод не вызывается. И т.д.
Не хотелось бы, чтобы учетные данные пользователя требовалось передавать при вызове методов. Вообще не хотелось бы думать об их передаче при написании кода. Т.е. желательно, чтобы было примерно так, пользователь прошел авторизацию/аутентификацию, клиент получил какой-нибудь маркер. И
этот маркер все время передавался службе при вызове ее методов. При этом хотелось бы, чтобы все это на себя взял Framework, т.е. мне бы не пришлось думать над тем какой маркер создавать, где его хранить, как передавать. Если это возможно конечно.
Служба, при вызове ее методов, получает маркер и понимает, что с ней общается такой-то пользователь и привелегии у него строго определнные. Характеристики пользователя и его привелегий служба черпает из базы MySQL. При этом я не против описать методы для получения логина, пароля пользователя, его привелегий. Но хотелось бы как-то исбежать реализации механизма передачи и обработки маркера, т.е. это было бы неплохо возложить на решения Майкрософт.


NdF>>Пока думаю, что нужны роли, как я понимаю, это мне даст возможность над каждым методом службы выставлять аттрибут досутпа к этому методу, где я буду указывать какие роли могут его вызывать (декларативное обеспечение) или я смогу прямо в коде метода узнать роль пользователя и в соответсвии с этой ролью изменить логику метода (императивное). Меня это и устраивает.

G>Для ответа на этот вопрос надо ответить на предыдущий. А вообще, механизм Membership и Roles для сайтов ASP.NET имеет достаточно недостатков, и немного устарел. Смысла прикручивать его к wcf-службе я не вижу.
А что вообще народ использует, в случае когда создает сервис общего пользования, а не сервис внутри локальной/корпративной сети.

В добавок к тому посту, что написал несколько минут назад. Вот взять роли. Там как я понимаю есть тот самый механизм меаркера, у них это IPrincipal, в которм передается информация о пользователе. Т.е. когда пользователь вызывает методо службы, этот IPrincipal улетает вместе с запросом на вызов метода, служба получает этот принципал (ServiceSecurityContext кажется для этого используется)и приступает к вызову метода. Смотрит, разрешено ли этой группе пользователей вызывать этот метод и если разрешено, то приозводит вызов. При этом есть Windows группы, есть SqlRoleProvider (это для счастливых пользователей MS SQL), а можно сделать свой провайдер. Как раз в том ролике (часть 2), девушка из Майкрософт сказала, что этотс случай как раз дял тех, у кого данные о пользователях хранятся в базе данных.
Метод заявок claim я не понял вообще , но вроде как для этого надо создавать сертфиикаты и видимо их надо тащить клиенту с собой, что уже не подходит.

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

Во-первых тебе нужно все таки разгрести кашу в голове. Аутентификация и авторизация это две разных вещи. Классическая схема секурности выглядит примерно так
1) Аутентификация. Суть процесса — на основании переданных удостоверений (credentials) нужно сделать вывод — корректные ли они, или нет. И если корректные — сформировать уникальный идентификатор пользователя — identity. В качестве credentials могут быть: пара имя пользователя/пароль, токен Windows-аутентификации, подписанный цифровой подписью сертификат и т.п. При передаче credentials по сети так же могут использоваться ряд протоколов. Понятно, что и протокол передачи, и способ проверки зависят от конкретного вида credentials.
Обрати внимание — никакого контроля прав на этом этапе не происходит, только проверка подлинности credentials.
2) Авторизация. Суть процесса — на основании identity сформировать некий набор разрешений (permissions), так или иначе описывающих права конкретного пользователя в системе. Ты правильно заметил — чаще всего эти права описываются в виде набора ролей.
3) Контроль прав. Проверка соответствия между правами пользователя, совершающего операцию над ресурсом, и ограничений на доступ к этому ресурсу (специального набора данных, обычно в виде ACL, Access Control List).

Теперь касаемо WCF. По первому пункту WCF предоставляет целую пачку готовых реализаций аутентификации, которые описаны в документации. Если готовые не устраивают — есть возможность реализовать собственный вариант.
По второму пункту в WCF готовой реализации по понятным причинам нет, но он предоставляет полный комплект средств для реализации этого при помощи собственного authorization manager. WCF организовывает итерационный процесс преобразования набора Claims до тех пор, пока все менеджеры не скажут, что они работу выполнили. Как входные данные для авторизации, так и результат авторизации представляется в виде отдельных Claims произвольного формата. Такая схема позволяет реализовать очень хитрые варианты авторизации.
По третьему пункту — тут все зависит от типа ресурса. Если в качестве ресурса — сервисы WCF и их операции, то контролировать доступ совсем несложно при помощи собственного behavior. Если в качестве ресурса выполнение какого то кода — несложным хаком можно включить в WCF поддержку стандартного для дотнета role based security на базе CAS. Контроль всех остальных видов ресурсов WCF реализовать тебе никак не поможет.

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

WCFSecurityGuide?

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

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

AVK>Во-первых тебе нужно все таки разгрести кашу в голове.
Это точно.
AVK>1) Аутентификация.
Возьмем мой случай. КАк я понимаю, мне подходит Custom. Т.е.
Мне надо либо создать свой Validator производный от UserNameValidator или прикрутить свой Membership. При этом WSHttpBinding binding настраиваю примерно таким образом. SecurityMode выбриаю допустим Message.
binding.Security.Message.ClientCredentialType=MessageCredentialType.UserName; (Windows и Certificate не подходят (сертификаты если и будем зазкаывать, то для SSL только))
binding.Security.Transport.ClientCredentialType=HttpClientCredentialType.None; (Windows и NTLM не подходит, с сертификатами позже надо разобратсья, при Basic учетные данные, как я понял берутся из ActiveDirectory, этого пока мне не надо)

Затем нужно провести настройки хоста, где указать, что используется Custom аутентификация и указать экземпляр моего провайдера.

В клиентском приложении мне нужно делать так
ServiceClient.Credentails.UserName.UserName="user";
ServiceClient.Credentails.UserName.Password="pwd";

Все вверно?


AVK>2) Авторизация. Суть процесса — на основании identity сформировать некий набор разрешений (permissions), так или иначе описывающих права конкретного пользователя в системе. Ты правильно заметил — чаще всего эти права описываются в виде набора ролей.

Так. Дл авторизации. Есть три вида авторизации:
1. на основе ролей Role Based (с ней вроде худо бедно ясно, но не без впросов).
Чтобы ее реализовать мне надо определить свой RoleProvider. Потом вот не совсем понятно. Надо полагать в behavior указываю RoleProvider. И все этого достаточно?
При этом использовать вроде как легко, т.е. помечаю метод (к котормоу хочу применить огпраничение по ролям) аттрибутом PrincipalPermission или вообще могу внутри метода проверить в какой роли пользователь
2. на основе заявок Identity-based.
Как я понял — это нечто типа role based, только чем-то более продвинуто и расширено. По ходу дела использовать надо ее? Для этого мне потребуется создать два класса производных от ServiceAuthorizationManaget, IAuthorizationPolicy. Вроде в видео-материалах как раз рассмотрен этот подход и вопросов у меня по этомук методу практически нет, по крайней мере пока .
Вот как использовать не совсем понял. В этом случае, как я понимаю, не надо ставить аттрибуты над методами. Вся политика определяется в методе CheckAccessCore класса ServiceAuthorizationManager. И как я понял императивный метод здесь не получится применить?
3. на основе ресурсов Resource-based
Как я понял эта как раз ACL. Вообще не понял что это и как работает. Что это за ACL, как его создавать и юзать. Дайте хоть пару примеров этих ACL.

AVK>3) Контроль прав. Проверка соответствия между правами пользователя, совершающего операцию над ресурсом, и ограничений на доступ к этому ресурсу (специального набора данных, обычно в виде ACL, Access Control List).
Вот опять этот ACL

AVK>По третьему пункту — тут все зависит от типа ресурса. Если в качестве ресурса — сервисы WCF и их операции, то контролировать доступ совсем несложно при помощи собственного behavior. Если в качестве ресурса выполнение какого то кода — несложным хаком можно включить в WCF поддержку стандартного для дотнета role based security на базе CAS. Контроль всех остальных видов ресурсов WCF реализовать тебе никак не поможет.
Вот этот пункт тоже не ояень понял. В моем случае, я так понимаю, ресурсом служам методы службы? В behavior я могу указать методы авторизации и если они кастомные, то собственную реализацию. Правильно я понял.

AndrewVK, спасибо за ссылку. С английским хоть и туговато, но в книге есть классные примеры. Там как раз есть близкий мне случай — WinForms Client to Remote WCF using Message Security (мне пока только на уровне сообщений защиты хватит). Там предлагают создавать membership провайдер (его пример есть в МСДН, что уже хорошо), правда провайдер ролей там SQLный и тогда, если останавливаьтся на ролях, то возможно я без проблем реализую своего провайдера и без проблем прикручу его.

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

NdF>Я видел эти доклады. Проблема в том, что почти везде рассматривается либо аутентификация Windows, либо Forms.
Вот интересно, потенциально клиентами WCF могут выступать клиенты написанные на сильверлайте,а в сильверлайте, по крайней мере в третьем, заявлена поддержка Mac OS c safari. Интересно, как там будет выглядеть аутентификация windows
А по теме,в одном из создаваемых проектов, мы не стали прикручивать существующие инструменты, а создали свои собственые механизмы аутентификации и авторизации. и ничуть об этом не жалеем.

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

NdF>binding.Security.Message.ClientCredentialType=MessageCredentialType.UserName; (Windows и Certificate не подходят (сертификаты если и будем зазкаывать, то для SSL только))

Сертификаты не обязательно где то заказывать. Ты их сам можешь нагенерить.

NdF>Все вверно?

В целом да, но с деталями луше смотреть примеры к WCF.

NdF>Так. Дл авторизации. Есть три вида авторизации:
NdF>1. на основе ролей Role Based (с ней вроде худо бедно ясно, но не без впросов).
NdF> Чтобы ее реализовать мне надо определить свой RoleProvider. Потом вот не совсем понятно. Надо полагать в behavior указываю RoleProvider. И все этого достаточно?

Не не не. RoleProvider это из другой оперы, это ASP.NET.

NdF>При этом использовать вроде как легко, т.е. помечаю метод (к котормоу хочу применить огпраничение по ролям) аттрибутом PrincipalPermission

Это тоже их другой оперы — это CAS. Как я уже писал — использовать его можно, но нужно специально включать его поддержку в WCF.

NdF>2. на основе заявок Identity-based.

Это я вообще не понял. Ты про claims? Это просто внутренний механизм секурности в WCF — он, кстати, и для аутентификации используется.

NdF>Как я понял — это нечто типа role based, только чем-то более продвинуто и расширено.

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

NdF> По ходу дела использовать надо ее? Для этого мне потребуется создать два класса производных от ServiceAuthorizationManaget, IAuthorizationPolicy.

Не два обычно все таки, а какой нибудь один из них.

NdF>Вот как использовать не совсем понял. В этом случае, как я понимаю, не надо ставить аттрибуты над методами. Вся политика определяется в методе CheckAccessCore класса ServiceAuthorizationManager. И как я понял императивный метод здесь не получится применить?

Что значит использовать? Регистрируешь свой менеджер или политику, внутри проверяешь то что нужно. В MSDN и в поставке WCF есть примеры.

NdF>3. на основе ресурсов Resource-based
NdF>Как я понял эта как раз ACL. Вообще не понял что это и как работает. Что это за ACL, как его создавать и юзать. Дайте хоть пару примеров этих ACL.

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

NdF>Вот этот пункт тоже не ояень понял. В моем случае, я так понимаю, ресурсом служам методы службы?

Не знаю, это уж ты сам определяйся.

NdF> В behavior я могу указать методы авторизации и если они кастомные, то собственную реализацию. Правильно я понял.

Если ты реализуешь свой менеджер авторизации, то контроль можно в нем же реализовать.

NdF>AndrewVK, спасибо за ссылку. С английским хоть и туговато, но в книге есть классные примеры. Там как раз есть близкий мне случай — WinForms Client to Remote WCF using Message Security (мне пока только на уровне сообщений защиты хватит).

Ну, в качестве примера можешь еще глянуть http://svn.rsdn.ru/svn/R.Server/Trunk/ . Там и UserName/Password внутри message используется, и кастомная ролевая авторизация, и собственная механика политик для доступа к сервисам и операциям.

NdF> Там предлагают создавать membership провайдер (его пример есть в МСДН, что уже хорошо), правда провайдер ролей там SQLный и тогда, если останавливаьтся на ролях, то возможно я без проблем реализую своего провайдера и без проблем прикручу его.

Забей ты на это аспнетное барахло. В данном случае вреда от него будет больше, чем пользы.

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

A>Вот интересно, потенциально клиентами WCF могут выступать клиенты написанные на сильверлайте,а в сильверлайте, по крайней мере в третьем, заявлена поддержка Mac OS c safari. Интересно, как там будет выглядеть аутентификация windows

В WCF есть два вида "аутентификации Windows". Один — это та аутентификация, которая использует свой протокол. Вот ее, наверное, не так просто под маками реализовать, хотя принципиальных проблем нет. А вторая просто передает username|password, но проверяет их на сервере средствами windows, и использовать ее под макос никаких проблем нет.

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


G>>Не очень понял про диалог, но ладно. Или вас смущает название Forms?
NdF>Нет, смущает не название. Как я понял вся суть этого метода заключается в том, что создается страничка сайта и делается настройка, что эта страничка авторизации.

Да, насчет каши Андрей точно заметил, не в обиду будет сказано. Нет, все ниженаписанное про forms неверно. Во-первых, оно из асп.нет (как и все остальное что ты хочешь использовать) и к WCF имеет мало отношения. Прикрутить можно, но смысла в этом 0. Тут просто надо подтянуть матчасть

NdF>Представляю себе это примерно так. Запускается диалог авторизации, пользователь вводит логин и пароль, жмет ОК. Клиентское приложение вызывает метод аутентификации/авторизации (раз такая путаница, буду через слэш писать ), этот

Вызывает метод у кого? На клиенте или на сервере? Если на сервере — то не надо ничего вызвать, нужно просто воспользоваться одним из стандартных механизмов аутентификации WCF. Если на клиенте — то это вообще жесть

Все ниженаписанное — оно не нужно, изобретение крайне вредных велосипедов.

Будет время — попробую состряпать примерчик.

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

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

NdF>>binding.Security.Message.ClientCredentialType=MessageCredentialType.UserName; (Windows и Certificate не подходят (сертификаты если и будем зазкаывать, то для SSL только))

AVK>Сертификаты не обязательно где то заказывать. Ты их сам можешь нагенерить.
Это ведь только относится к сертфикатам Х509? SSL по-любому же надо заказывать? Это я любопытствуа ради, потмоу как сертификаты не подходят, пользователю придется таскать его с собой.

NdF>>Все вверно?

AVK>В целом да, но с деталями луше смотреть примеры к WCF.

Ну хоть с аутентификацией разобрался.



AVK>Не не не. RoleProvider это из другой оперы, это ASP.NET.
Что значит "это ASP.NET". В смысле это решение подходит только при создании сайта или что? Я под ASP.NET понимаю технологию создания веб-приложений и веб-сервисов. В данном контексте я не врубаюсь, что имеется ввиду.

NdF>>При этом использовать вроде как легко, т.е. помечаю метод (к котормоу хочу применить огпраничение по ролям) аттрибутом PrincipalPermission

AVK>Это тоже их другой оперы — это CAS. Как я уже писал — использовать его можно, но нужно специально включать его поддержку в WCF.
Хм, ну да хрен с ней пока.

NdF>>2. на основе заявок Identity-based.
AVK>Это я вообще не понял. Ты про claims? Это просто внутренний механизм секурности в WCF — он, кстати, и для аутентификации используется.
NdF>>Как я понял — это нечто типа role based, только чем-то более продвинуто и расширено.
AVK>Нет. Это просто основа, поверх которой ты можешь почти любую схему реализовать.
Я вот что имею ввиду:

WCF supports the following three basic authorization approaches:
• Role-based. Access to WCF operations is secured based on the role membership of the
caller. The role store can be Windows groups, ASP.NET roles, or a custom role store.
• Identity-based. WCF supports an Identity Model feature, which is an extension to rolebased
authorization. Identity Model enables you to manage claims and policies to authorize
clients. With this approach, you can verify claims contained within the authenticated users’
credentials.
• Resource-based. Individual resources are secured using Windows access control lists (ACLs).
The WCF service impersonates the caller prior to accessing resources, which allows the
operating system to perform standard access checks. All resource access is performed using
the original caller’s security context.

NdF>> По ходу дела использовать надо ее? Для этого мне потребуется создать два класса производных от ServiceAuthorizationManaget, IAuthorizationPolicy.
AVK>Не два обычно все таки, а какой нибудь один из них.

NdF>>Вот как использовать не совсем понял. В этом случае, как я понимаю, не надо ставить аттрибуты над методами. Вся политика определяется в методе CheckAccessCore класса ServiceAuthorizationManager. И как я понял императивный метод здесь не получится применить?
AVK>Что значит использовать? Регистрируешь свой менеджер или политику, внутри проверяешь то что нужно. В MSDN и в поставке WCF есть примеры.
В основном все примеры сводятся к ролям ... Я про те дв класса ServiceAuthorizationManaget, IAuthorizationPolicy узнал благодаря видео на techdays, да на тему одну набрел на другом фйоруме.



NdF>> В behavior я могу указать методы авторизации и если они кастомные, то собственную реализацию. Правильно я понял.

AVK>Если ты реализуешь свой менеджер авторизации, то контроль можно в нем же реализовать.
В методе CheckAccessCore класса ServiceAuthorizationManager?


AVK>Ну, в качестве примера можешь еще глянуть http://svn.rsdn.ru/svn/R.Server/Trunk/ . Там и UserName/Password внутри message используется, и кастомная ролевая авторизация, и собственная механика политик для доступа к сервисам и операциям.
Ты вроде сказал, что мне кастомная ролевая авторизация не подходит, или я не так тебя понял?

AVK>Забей ты на это аспнетное барахло. В данном случае вреда от него будет больше, чем пользы.
Вот я вообще понять не могу, что значит "аспнетное". Но я уже выше об этом говорил.

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


G>Да, насчет каши Андрей точно заметил, не в обиду будет сказано. Нет, все ниженаписанное про forms неверно. Во-первых, оно из асп.нет (как и все остальное что ты хочешь использовать) и к WCF имеет мало отношения. Прикрутить можно, но смысла в этом 0. Тут просто надо подтянуть матчасть
Да обижаться-то не на что, корм и правда не в коня пошел.

G>Вызывает метод у кого? На клиенте или на сервере? Если на сервере — то не надо ничего вызвать, нужно просто воспользоваться одним из стандартных механизмов аутентификации WCF. Если на клиенте — то это вообще жесть
Да нет, вызывается метод сервиса.
До меня только сейчас дошло, что я не ту секцию МСДНа изучал ..., как раз смотрел ASP.NET. Правда там было пару тем, посвященных WCF, это меня и смутило.


G>Все ниженаписанное — оно не нужно, изобретение крайне вредных велосипедов.

G>Будет время — попробую состряпать примерчик.
Было бы прекрасно, но при условии, если время позволит, конечно.

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

NdF>Это ведь только относится к сертфикатам Х509?

К любым

NdF> SSL по-любому же надо заказывать?

Не обязательно, если ты сможешь организовать доставку сертификата до клиентской машины.

AVK>>Не не не. RoleProvider это из другой оперы, это ASP.NET.
NdF>Что значит "это ASP.NET".

То и значит, что эта механика предназначена для ASP.NET.

AVK>>Если ты реализуешь свой менеджер авторизации, то контроль можно в нем же реализовать.
NdF>В методе CheckAccessCore класса ServiceAuthorizationManager?

Да.

NdF>Ты вроде сказал, что мне кастомная ролевая авторизация не подходит, или я не так тебя понял?

Видимо не так понял.

Вопрос по аутентификации.
Создал свой класс — наследний MembershipProvider. Класс определен в той же сборке, что и служба. Запуск службы происходит с использованием Visual Studio Development Server.
В Web.config написал следующее (вроде как в МСДНн):

 <membership defaultProvider="ServiceMembershipProvider" userIsOnlineTimeWindow="15">
      <providers>
        <clear />
        <add
          name="ServiceMemberShipProvider"
          type="CP.Proj.Service.ServiceMemberShipProvider"
          connectionString="ConnectDB"/>
      </providers>
 </membership>

При запуске службы ошибка типа

Имя пользователя/пароль, указанные поставщиком Membership CP.Proj.Service.ServiceMemberShipProvider в конфигурации, недействительны. Такой поставщик не зарегистрирован в system.web/membership/providers.

ServiceMemberShipProvider — навзаниt класса
CP.Proj.Service.ServiceMemberShipProvider — пространство имен и класс

Ошибся где-то или что-то не сделал

Вопрос по аутентификации.
Создал свой класс — наследний MembershipProvider. Класс определен в той же сборке, что и служба. Запуск службы происходит с использованием Visual Studio Development Server.
В Web.config написал следующее (вроде как в МСДНн):

 <membership defaultProvider="ServiceMembershipProvider" userIsOnlineTimeWindow="15">
      <providers>
        <clear />
        <add
          name="ServiceMemberShipProvider"
          type="CP.Proj.Service.ServiceMemberShipProvider"
          connectionString="ConnectDB"/>
      </providers>
 </membership>

в behavior службы добавил слудеющее (из-за чего и ошибка)

<serviceCredentials>
      <userNameAuthentication userNamePasswordValidationMode="MembershipProvider"
       membershipProviderName="CP.Proj.Service.ServiceMembeShipProvider" />
     </serviceCredentials>

При запуске службы ошибка типа

Имя пользователя/пароль, указанные поставщиком Membership CP.Proj.Service.ServiceMemberShipProvider в конфигурации, недействительны. Такой поставщик не зарегистрирован в system.web/membership/providers.


ServiceMemberShipProvider — навзаниt класса
CP.Proj.Service.ServiceMemberShipProvider — пространство имен и класс

Ошибся где-то или что-то не сделал

Попрбовал так

<authentication mode="Windows"/>
    <membership defaultProvider="ProjMemberShipProvider" userIsOnlineTimeWindow="15">
      <providers>
        <clear />
        <add
          name="ProjMemberShipProvider"
          type="CP.Proj.Service.ProjMemberShipProvider, ProjService, Version=1.0.0.0" />        
              </providers>
    </membership>

<serviceBehaviors>
    <behavior name="ProjService.Service1Behavior">
     <serviceMetadata httpGetEnabled="true" />
     <serviceDebug includeExceptionDetailInFaults="false" />
     <serviceCredentials>
      <userNameAuthentication userNamePasswordValidationMode="MembershipProvider"
       membershipProviderName="ProjMemberShipProvider"/>
     </serviceCredentials>
    </behavior>
   </serviceBehaviors>
  </behaviors>
    </system.serviceModel>
</configuration>

ошибка пропала, но фугнкция  
public override bool ValidateUser(string username, string password)
        {
            return false;
            //if (username == "Ivan" && password == "1")
            //    return true;
            //return false;

        }

Судя по коду, доступ будет запрещен всегда, но пока  все наоборот. Судя по всему функция не вызывается.

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

С asp.net вопросы не ко мне.