WCF CustomRoleProvider и основные разрешения - PullRequest
Новая
       51

WCF CustomRoleProvider и основные разрешения

1 голос
/ 09 марта 2012

РЕДАКТИРОВАТЬ: Я думаю, что проблема может быть связана с проблемой ниже, так как я также использую SSL PrincipalPermission.Demand (), сбой после перемещения службы WCF в SSL

Я работаю над безопасным набором веб-служб, я реализовал CustomRoleProvider и CustomMembershipProvider для аутентификации пользователей.

Это прекрасно работает, однако я бы хотел ограничить доступ кБольшинство сервисных вызовов, если пользователь не аутентифицирован.

Я планировал использовать следующее для выполнения этого 

[PrincipalPermission(SecurityAction.Demand, Authenticated=true)]

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

public class CustomMembershipProvider : MembershipProvider
{
    public string UserType;

    public override bool ValidateUser(string username, string password)
    {
           //Custom logic to work out if user exists and password is correct

           //If the user exists and password matches we will get a populated user
           //object containing their username and usertype

            if (user == null)
            {
                return false;
            }
            else
            {
                return true;
            }
        }
    }

В рамках моего вызова службы проверки подлинности я проверяю, возвращает ли поставщик членства значение true и устанавливает ли файл cookie проверки подлинности форм. 

        if (Membership.ValidateUser(username, password))
        {
            FormsAuthentication.SetAuthCookie(username, false);
        }

Я настроил сервис авторизации в моей веб-конфигурации следующим образом: 

    <behavior name="SecureAuthServiceBehavior">
      <serviceAuthorization principalPermissionMode="UseAspNetRoles" roleProviderName="CustomRoleProvider"/>
      .... 
     </behaviour>

Любая помощь будет принята с благодарностью, Спасибо

РЕДАКТИРОВАТЬ:

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

[PrincipalPermission(SecurityAction.Demand,Role="A" )]
public bool DoWork()
{
    IPrincipal p = HttpContext.Current.User;
    if (p.IsInRole("A"))
    {
        return true;
    }
    else
    {
        return false;
     }
}

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

1 Ответ

1 голос
/ 10 августа 2012

PrincipalPermission проверяет Thread.CurrentPrincipal, а не HttpContext.Current.User, поэтому с закомментированным атрибутом Principalpermission ваш DoWork () возвращает true, но с этой строкой возвращает false (поскольку Thread.CurrentPrincipal не установлен ни к чему).

В конструкторе моего класса обслуживания я установил Thread.CurrentPrincipal = HttpContext.Current.User, и теперь они совпадают правильно. Атрибут Principalpermission затем блокирует / разрешает, как и следовало ожидать.

...