Привет всем!
Запутался я совсем с аутентификацией и авторизацией в WCF. Информации море, но шибко широким фронтом охватить проблему хотят...
Что собственно нужно:
1. Аутентификация пользователя по доменным учетным записям Windows.
2. Роли пользователй никак не связаны с группами пользователей в Windows. Список ролей, их иерархия и включение в них учетных записей пользователей — все это хранится в базе данных.
3. Включение/исключение пользователей в роли задавать в рантайме.
4. Право на выполнение контрактов операций (методов, помеченных [OperatiornContract]) так же задается в рантайме.
5. Декларативно назначить контрактам операций способ авторизации. Т.е. не хочу в каждом методе, помеченном [OperatiornContract], писать код типа:

if (CurrentPrincipal.IsInRole(...))
{
...
}

Может быть можно авторизацию прописать в ServiceBehavior или OperationBehavior или еще где?

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

S>Привет всем!
S>Запутался я совсем с аутентификацией и авторизацией в WCF. Информации море, но шибко широким фронтом охватить проблему хотят...
S>Что собственно нужно:
S>1. Аутентификация пользователя по доменным учетным записям Windows.

Выполняется автоматически средствами IIS при наличии домена и включенной в IIS опции аутентификации Windows

S>2. Роли пользователй никак не связаны с группами пользователей в Windows. Список ролей, их иерархия и включение в них учетных записей пользователей — все это хранится в базе данных.

Microsoft Authorization Manager (AzMan) или http://netsqlazman.codeplex.com/

S>3. Включение/исключение пользователей в роли задавать в рантайме.

Непонятно зачем Включение пользователей в роли — достаточно редко выполняемая администратором операция.

S>4. Право на выполнение контрактов операций (методов, помеченных [OperatiornContract]) так же задается в рантайме.
S>5. Декларативно назначить контрактам операций способ авторизации. Т.е. не хочу в каждом методе, помеченном [OperatiornContract], писать код типа:
S>

S>if (CurrentPrincipal.IsInRole(...))
S>{
S>...
S>}
S>

S>Может быть можно авторизацию прописать в ServiceBehavior или OperationBehavior или еще где?

Декларативно — PrincipalPermissionAttribute на метод.
Императивно — CurrentPrincipal.IsInRole(). Других способов проверить разрешения не для целого метода, а для фрагмента — нету.

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

S>>1. Аутентификация пользователя по доменным учетным записям Windows.
B>Выполняется автоматически средствами IIS при наличии домена и включенной в IIS опции аутентификации Windows
У меня WinForm-клиент и сервер планируется в виде Win-службы. Для мороки с IIS не вижу серьезных аргументов. Полагаю, что какой-нибудь Thread.CurrentPrincipal даст мне возможность определить логин? Честно говоря, пока не пробовал, но, думаю, это не самый сложный аспект.

S>>2. Роли пользователй никак не связаны с группами пользователей в Windows.
B>Microsoft Authorization Manager (AzMan) или http://netsqlazman.codeplex.com/
Спасибо! Буду смотреть. На крайняк свой лесапед реализую: тоже не велика проблема.

S>>3. Включение/исключение пользователей в роли задавать в рантайме.
B>Непонятно зачем Включение пользователей в роли — достаточно редко выполняемая администратором операция.
Операция редкая, но какие альтернативы? Админ-то тоже включать/исключать пользователей в роли должен через GUI с кнопочками, Grid'ами и списками.

S>>5. Декларативно назначить контрактам операций способ авторизации. Т.е. не хочу в каждом методе, помеченном [OperatiornContract], писать код типа:
B>Декларативно — PrincipalPermissionAttribute на метод.
B>Императивно — CurrentPrincipal.IsInRole(). Других способов проверить разрешения не для целого метода, а для фрагмента — нету.
Насколько я понял, PrincipalPermissionAttribute предполагает ЖЕСТКОЕ указание логинов пользователей или имен групп, которые имеют право на выполнение метода, помеченного этим атрибутом. Мне же нужно чтобы в процессе эксплуатаци программы, по указанию руководства, без перекомпиляции и редактирования config-файлов (например, внеся некие изменения в таблицы базы данных) можно было отобрать право на выполнение метода X у группы пользователей А и дать право на выполнение метода Y группе пользователей Б. По-моему не удаляя/добавляя атрибуты PrincipalPermissionAttribute в коде сделать этого не удастся. Я ошибаюсь?
Вариант с CurrentPrincipal.IsInRole() мне совсем не нравится, потому что: можно банально забыть в очередном методе контракта выполнить проверку.
Кстати, меня интересует именно разграничение прав на метод, помеченный [OperatiornContract], в целом, а не на отдельные фрагменты его содержимого...

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

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

S>>>1. Аутентификация пользователя по доменным учетным записям Windows.
S>У меня WinForm-клиент и сервер планируется в виде Win-службы.

Можно и службами, если сервер способен аутентифицировать клиента в домене

S>>>2. Роли пользователй никак не связаны с группами пользователей в Windows.
S>Спасибо! Буду смотреть. На крайняк свой лесапед реализую: тоже не велика проблема.

Не, не рекомендую )

S>>>3. Включение/исключение пользователей в роли задавать в рантайме.
S>Операция редкая, но какие альтернативы? Админ-то тоже включать/исключать пользователей в роли должен через GUI с кнопочками, Grid'ами и списками.

GUI управления есть и в AzMan, и в NetSqlAzMan

S>>>5. Декларативно назначить контрактам операций способ авторизации. Т.е. не хочу в каждом методе, помеченном [OperatiornContract], писать код типа:
S>Насколько я понял, PrincipalPermissionAttribute предполагает ЖЕСТКОЕ указание логинов пользователей или имен групп, которые имеют право на выполнение метода, помеченного этим атрибутом. Мне же нужно чтобы в процессе эксплуатаци программы, по указанию руководства, без перекомпиляции и редактирования config-файлов (например, внеся некие изменения в таблицы базы данных) можно было отобрать право на выполнение метода X у группы пользователей А и дать право на выполнение метода Y группе пользователей Б. По-моему не удаляя/добавляя атрибуты PrincipalPermissionAttribute в коде сделать этого не удастся. Я ошибаюсь?

AzMan вводит понятие операции — это константа, которая соответствует некоей бизнес-процедуре. Например, CREATE_ORDER, EDIT_ORDER, DELETE_ORDER. С его помощью также можно сконфигурировать разрешение той или иной роли на выполнение той или иной операции, а также проверить, разрешено ли текущему принципалу (включенному в одну или несколько ролей) выполнять эту операцию. Короче, речь идёт об ACL. Кто будет дергать проверку разрешений — атрибут или метод — совершенно неважно, и я бы не старался подстроить свой код под стандартные дотнетовские классы Code Access Security. Можно вообще написать свой атрибут, а к проекту приделать какой-нибудь PostSharp, который определит контекст вызова метода и выполнит все проверки... Как-нибудь так:

[OperationContract]
[PermissionCheck(Constants.CREATE_ORDER)]
public void CreateOrder()
{
  // Здесь PostSharp способен определить контекст вызова метода,
  // получить Name текущего Principal,
  // получить имя операции из атрибута,
  // слазить в хранилище AzMan для того, чтобы посмотреть, имеет ли текущий пользователь 
  // право выполнять операцию CREATE_ORDER,
  // и, если не имеет, то кинуть SecurityException
  ...
}