WCF и Silverlight 4.0 в приложении N-Tier: проверка подлинности звонков в службу - PullRequest
Новая
       37

WCF и Silverlight 4.0 в приложении N-Tier: проверка подлинности звонков в службу

5 голосов
/ 05 августа 2011

У меня есть приложение N-уровня, которое построено следующим образом:
На стороне сервера в IIS7 находится приложение ASP.Net, которое предоставляет методы для службы WCF.Эти методы общаются с БД с помощью EF4.Клиенты, написанные в Silverlight 4.0, вызывают методы службы WCF.

Служба WCF предоставляет этот метод: 

[OperationContract]
void DeleteItem(int i_ItemId);

Я новичок в получении услуг WCF, но я думаю, что эти следующие наблюдения верны (поправьте меня, если я ошибаюсь):

1) Если я оставлю этот метод / службу как есть, любой, кто знает, что мой сервис находится в http://www.mysite.com/myservice.svc, может просто открыть VisualStudio, открыть «Добавить ссылку на службу» и начать вызывать DeleteItem ().

2) Если я попытаюсь решить вышеуказанное, удалив конечную точку MEX, вызовы в службу все еще могут быть сделаны с использованием некоторого ручного кодирования.

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

  <wsHttpBinding>
    <binding name="RequestUserName" >
      <security mode="Message">
        <message clientCredentialType="UserName"/>
      </security>
    </binding>

Попытка принять это решение, первое, что пришло мне в головуМысль была такова: когда пользователь входит в клиент, клиент использует имя пользователя и пароль в качестве учетных данных для вызова WCF.На стороне сервера эти учетные данные проверяются по БД.

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

Отсюда я пришел к двум решениям:

1) Вместо использования имени пользователя и пароля в качестве учетных данных, я буду использовать жестко закодированный ключ в клиенте.Скремблирование Dll внутри XAP может помешать кому-либо получить этот ключ.

2) Когда пользователь входит в систему на клиенте, сервер отправляет некоторый временный токен (GUID или что-то), который клиент может использоватьаутентифицировать его вызовы во время сеанса связи (скажем, до тех пор, пока пользователь не закроет клиент).

Мой вопрос:

Какой уровень безопасности обеспечивает первое решение и как много вам нужно для его взлома?

Если первое решение оченьтривиально взломать, есть ли в WCF встроенный способ управления системой токенов, о которой я упоминал во втором решении?

Приветствуются другие решения, которые могут охватить сферу применения.

1 Ответ

1 голос
/ 05 августа 2011

Я не уверен относительно уровня безопасности, о котором вы спрашиваете, но я не чувствовал бы уверенности в сохранении имени пользователя и пароля в файле XAP, запутанном или нет.

Я могу описать решение, которое я внедрил в производство.

По сути, я защищаю приложение с помощью стандартной проверки подлинности с помощью форм, но я не использую перенаправления, как это обычно происходит с ASP.NET, я использую веб-службу проверки подлинности, которая поставляется с проверкой подлинности с помощью форм ASP.NET.Таким образом, мой логин проходит через элементы управления Silverlight.У моего приложения есть хранилище пользователей, с которым я аутентифицирую службу аутентификации.

Чтобы подключиться к службе аутентификации, я делаю это в Global.asax: 

protected void Application_Start(object sender, EventArgs e)
{
    AuthenticationService.Authenticating += new EventHandler<AuthenticatingEventArgs>(AuthenticationService_Authenticating);
}

void AuthenticationService_Authenticating(object sender, AuthenticatingEventArgs e)
{
    try
    {
        bool authenticated = //Call your user store here.

        e.Authenticated = authenticated;
    }
    catch (Exception ex)
    {
        e.Authenticated = false;
    }
    e.AuthenticationIsComplete = true;
}

Вы бы обезопасили частивеб-сайт, как обычно, с формами, использующими элемент <authorization> с <deny users="?">.Браузер будет обрабатывать все куки для вас.Если вы хотите обезопасить службы, в разделе «Служба / папка» вы бы запретили пользователям, не прошедшим проверку подлинности.

В этом MSDN Post более подробно говорится о решении.

...