Как защитить ваши приложения Silverlight

В моей статье затрагиваются многие технические концепции, которые подробнее освещаются в других статьях (в том числе в этом журнале).По этой причины я не стану детально рассматривать их.Цель моей статьи в другом — «соединить точки» и показать, как использовать эти концепции для защиты ваших приложений.

Планируя защиту приложения, полезно подумать о трех «A»: аутентификации, авторизации и аудите.

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

Авторизация — процесс подтверждения того, что аутентифицированный пользователь действительно имеет соответствующие разрешения на выполнение определенной операции или на доступ к конкретному ресурсу.

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

Я сконцентрирую внимание на первых двух — аутентификации и авторизации в контексте приложения Silverlight.Так как подобное приложение одновременно является RIA-приложением (Rich Internet Application), большинство концепций, описанных в этой статье, равно применимо к приложениям AJAX (Asynchronous JavaScript and XML) или другим программам, построенным на принципах RIA.Мы также обсудим, как предотвратить нежелательный доступ к файлам вашего приложения Silverlight.

Топология

Silverlight — кросс-браузерный плагин, который использует многие графические концепции, впервые появившиеся в Windows Presentation Foundation (WPF) и позволяющие веб-разработчикам создавать приложения с гораздо большей функциональностью, чем это было возможно только при применении HTML и JavaScript.

Silverlight — в отличие от ASP.NET — клиентская технология, поэтому ее исполняющая среда работает на компьютерах пользователей.Следовательно, разработка на Silverlight имеет больше общего с разработкой на основе Windows Forms или WPF, чем на основе ASP.NET.Во многих отношениях это одно из самых крупных преимуществ Silverlight, так как оно снимает целый ряд проблем, вызванных самой природой веб-приложений, которые не поддерживают сохранение состояний.Однако, поскольку весь UI-код выполняется на клиентских компьютерах, вы больше не можете ему доверять.

Сервисы

Silverlight в отличие от Windows Forms работает в изолированной программной среде («песочнице») браузера и обладает сокращенным набором возможностей, что само по себе обеспечивает более высокую степень безопасности (хотя в Silverlight 4 пользователи могут определять некоторые приложения как доверяемые и поднимать привилегии таких программ до уровня, позволяющего взаимодействовать с COM).Ввиду этого Silverlight не может напрямую подключаться к базе данных, и вы должны создать уровень сервисов, которые обеспечивают доступ к вашим данным и прикладной логике.

Как правило, вы размещаете эти сервисы на своем веб-сервере — так же, как и веб-формы ASP.NET, к примеру.Из-за того, что код Silverlight выполняется за границами доверия между вашими серверами и реальным миром (рис. 1), основное внимание нужно уделять защите сервисов.

Рис. 1 Silverlight выполняется за границами доверия

Реализовать жесткие проверки защиты в самом коде для Silverlight особого смысла не имеет.В конце концов, атакующий может легко миновать ваше приложение Silverlight и напрямую запускать ваши сервисы, тем самым обойдя любые реализованные вами меры безопасности.В качестве альтернативы злоумышленник мог бы воспользоваться такой утилитой, как Silverlight Spy или Debugging Tools for Windows, для изменения поведения вашего приложения в период выполнения.

Важно понимать, что сервис не знает наверняка, какое приложение вызывает его и что это приложение каким-то образом не модифицировано.А значит, ваши сервисы должны гарантировать, что вызвавший код:

• Аутентифицирован должным образом;
• Авторизован на выполнение запрошенной операции

По этим причинам большая часть статьи посвящена тому, как защитить сервисы способом, совместимым с Silverlight.Конкретнее, я рассмотрю два типа сервисов, размещаемых через ASP.NET в Microsoft IIS.Первый тип — сервисы, созданные с использованием Windows Communication Foundation (WCF), которая предоставляет унифицированную модель программирования для построения сервисов.Второй тип — WCF Data Services (ранее ADO.NET Data Services), которые на основе WCF позволяют быстро обеспечивать доступ к данным, применяя стандартные команды HTTP; этот подход известен под названием Representational State Transfer (REST).

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

На сегодняшний день двумя самыми распространенными способами аутентификации, которыми пользуются веб-разработчики на платформе Microsoft, являются аутентификация средствами Windows и на основе форм.

Аутентификация средствами Windows

При аутентификации средствами Windows для проверки удостоверений пользователя применяется Local Security Authority или Active Directory.Во многих случаях это дает большое преимущество; вы можете централизованно управлять пользователями средствами, привычными системным администраторам.К тому же можно использовать любую схему, поддерживаемую IIS, в том числе базовую, дайджест- и интегрированную аутентификацию (NTLM/Kerberos), а также сертификаты.

Чаще всего при аутентификации средствами Windows выбирают интегрированную схему, так как она не требует от пользователей повторно вводить свои имя и пароль.Как только пользователь входит в Windows, браузер может переслать его удостоверения в виде маркера или подтверждения идентификации данной личности.В интегрированной аутентификации есть некоторые недостатки, поскольку и клиенту, и серверу нужно видеть домен пользователя.В итоге этот вариант лучше всего подходит для применения в интрасетях.Более того, хотя в Microsoft Internet Explorer он работает автоматически, в других браузерах вроде Mozilla Firefox потребуется дополнительная настройка.

Базовая и дайджест-аутентификация обычно требуют от пользователей повторного ввода своих имен и паролей, когда они инициируют сеанс с вашим веб-сайтом.Но, являясь частью спецификации HTTP, эти виды аутентификации работают в большинстве браузеров и даже при доступе извне вашей организации.

Silverlight использует коммуникации через браузер, поэтому аутентификацию средствами Windows легко реализовать с помощью любых только что рассмотренных способов аутентификации IIS.Детальное описание того, как это делается, рекомендую прочитать в пошаговом руководстве «How to: Use basicHttpBinding with Windows Authentication and TransportCredentialOnly in WCF from Windows Forms” по ссылке msdn.microsoft.com/library/cc949012.В этом примере на самом деле используется тестовый клиент Windows Forms, но этот же подход применим и к Silverlight.

Аутентификация на основе форм

Это механизм, который предоставляет простую поддержку собственной аутентификации в ASP.NET.Как таковая, она специфична для HTTP, а значит, ее легко задействовать в Silverlight.

Пользователь вводит комбинацию имени и пароля, и она передается на сервер для проверки.Сервер проверяет это удостоверение в доверяемом источнике данных (чаще всего это база данных о пользователях) и, если оно корректно, возвращает cookie с именем FormsAuthentication.Затем клиент при последующих запросах передает и этот cookie.Файл cookie подписывается и шифруется, поэтому расшифровать его сможет только сервер — злоумышленник не сумеет ни расшифровать его, ни модифицировать.

Запуск аутентификации на основе форм зависит от того, как именно вы реализуете свой экран входа.Например, если вы использовали веб-форму ASP.NET, которая после проверки удостоверений пользователя перенаправляет на страницу вашего приложения Silverlight, то вам, вероятно, больше ничего делать с аутентификацией и не надо.Файл cookie уже будет передан в браузер, и ваше приложение Silverlight будет использовать этот cookie при каждом запросе в данный домен.

Однако, если вы хотите реализовать экран входа в приложении Silverlight, вам придется создать сервис, который предоставляет ваши способы аутентификации и посылает соответствующий cookie.К счастью, в ASP.NET уже есть то, что вам нужно, — сервис аутентификации.От вас требуется лишь включить его поддержку в приложении.Рекомендую прочитать подробное руководство «How to: Use the ASP.NET Authentication Service to Log In through Silverlight Applications” по ссылке msdn.microsoft.com/library/dd560704(VS.96).

Еще одна важная особенность аутентификации через ASP.NET — ее расширяемость.Провайдер членства в группах описывает механизм, по которому проверяются имя и пароль пользователя.В составе ASP.NET есть несколько провайдеров членства в группах, в том числе такие, один из которых может использовать базы данных SQL Server, а другой — Active Directory.Но, если провайдера, отвечающего вашим требованиям, нет, создать собственную реализацию не так уж сложно.

Авторизация через ASP.NET

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

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

<system.serviceModel>
	<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
</system.serviceModel>
<system.web>
	<authorization>
		<deny users="?"/>
	</authorization>
</system.web>

В режиме совместимости можно предотвратить доступ неаутентифицированных пользователей, задействовав раздел authorization файла web.config, также показанный в предыдущем фрагменте кода.

Используя аутентификацию на основе форм, разработчик должен тщательно продумать то, какие части сайта нужно открыть для доступа даже неаутентифицированным пользователям.Например, если все части сайта доступны только аутентифицированным пользователям, то как на сайт сможет войти пользователь, еще не прошедший проверку подлинности?

Зачастую проще всего создать структуру папок, которая поддерживает ваши базовые требования к авторизации.В данном примере я создал папку Secured, содержащую файлы MyWcfService.svc и MyWcfDataService.svc, и развернул файл web.config.Структура папок показана на рис. 2, и в предыдущем фрагменте кода приведено содержимое файла web.config.

Рис. 2 Папка Secured, содержащая файл Web.config

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

Для сайтов, применяющих аутентификацию средствами Windows, многие вещи в этом отношении могут оказаться проще, так как аутентификация происходит до того, как пользователь обращается к ресурсу, содержащемуся в приложении, и в этом случае нет нужды в специальной странице входа.Используя такой подход, можно на самом деле разграничивать доступ к сервисам с большей детализацией, допуская к определенным ресурсам только конкретные группы пользователей или роли.Подробнее на эту тему см. «ASP.NET Authorization» (msdn.microsoft.com/library/wce3kxhd).

В этом примере авторизация реализована, но одна лишь авторизация уровня папок слишком груба в большинстве ситуаций.

Авторизация в WCF-сервисах

Применение атрибута PrincipalPermission — весьма простой способ потребовать, чтобы тот, кто вызывает некий метод Microsoft .NET Framework, был определен в конкретной роли.Этот пример кода демонстрирует, как такой вариант можно распространить на ServiceOperation в WCF, где вызвавший пользователь должен быть частью роли OrderApprovers:

[PrincipalPermission(SecurityAction.Demand, Role = "OrderApprovers")]
public void ApproveOrder(int orderId)
{
  OrderManag-er.ApproveOrder(orderId);
}

Это легко реализуется в приложениях, опирающихся на аутентификацию средствами Windows, — в этом случае применяется существующий механизм для создания групп Active Directory, обеспечивающих организацию пользователей.В приложениях с аутентификацией на основе форм можно задействовать другое отличное средство ASP.NET: провайдеры ролей (RoleProvider).И вновь в ASP.NET есть целый набор таких провайдеров, но, если вас не устраивает ни один из них, вы можете реализовать свой.

Конечно, даже авторизации для отдельных методов недостаточно для обеспечения всех потребностей безопансости, и всегда можно вернуться к написаниб процедурного кода в службах, как показано на рис. 3.

Рис. 3 Использование процедурного кода для реализации специфической авторизации

Public void CancelOrder(int orderId)
{
  // retrieve order using Entity Framework ObjectContext
  OrdersEntities entities = new OrdersEntities();
  Order orderForProcessing = entities.Orders.Where(o => o.Id ==
    orderId).First();

  if (orderForProcessing.CreatedBy !=
    Thread.CurrentPrincipal.Identity.Name)
  {
    throw new SecurityException(
      "Orders can only be canceled by the user who created them");
  }

  OrderManager.CancelOrder(orderForProcessing);
}

WCF — платформа с высокой степенью расширения, и, как в случае многих других вещей в WCF, существует много подходов к реализации авторизации в сервисах.Доминик Байер (Dominick Baier) и Кристиан Уейер (Christian Weyer) подробно обсуждали целый ряд возможных вариантов в октябрьском номере MSDN Magazine за 2008 г.В их статье «Authorization in WCF-Based Services» (msdn.microsoft.com/magazine/cc948343), в которой рассмотрена даже защита на основе заявок (claims-based security), показан структурный подход к организации авторизации в приложении.

Авторизация в WCF-сервисах данных

WCF-сервисы данных, как и предполагает название, опираются на WCF и обеспечивают доступ на основе REST к источнику данных — чаще всего такой источник является LINQ-to-SQL или LINQ-to-Entity Framework.Если в двух словах, это позволяет вам обеспечить доступ к своим данным по URL, который сопоставлен с наборами сущностей, предоставляемых вашим источником данных (набор сущностей обычно проецируется на таблицу в базе данных).Разрешения на доступ к этим наборам сущностей можно настроить в файле отделенного кода сервисов.На рис. 4 показано содержимое файла MyWcfDataService.svc.cs.

Рис. 4 Файл отделенного кода WCF-сервисов данных с конфигурацией правил доступа к наборам сущностей

Public class MyWcfDataService : DataService<SalesEntities>
{
  // This method is called only once to initialize service-wide policies.
  Public static void InitializeService(IDataServiceConfiguration config)
  {
    config.SetEntitySetAccessRule("Orders", EntitySetRights.AllRead);
    config.SetEntitySetAccessRule("Products", EntitySetRights.AllRead |
      EntitySetRights.WriteAppend | EntitySetRights.WriteDelete);
  }}

Здесь я выдаю разрешение Read для набора сущностей Orders и конфигурирую набор сущностей Products так, чтобы разрешить полное чтение, вставку новых записей и удаление существующих.

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

Рис. 5 Перехватчики запросов в WCF-сервисах данных

[QueryInterceptor("Products")]
Public Expression<Func<Product, bool>> OnQueryProducts()
{
  String userName =ServiceSecurityContext.Current.PrimaryIdentity.Name;
  return product => product.CreatedBy == userName;
}

[QueryInterceptor("Orders")]
Public Expression<Func<Comments, bool>> OnQueryOrders()
{
  bool userInPrivateOrdersRole =
    Thread.CurrentPrincipal.IsInRole("PrivateOrders");
  return order => !order.Private|| userInPowerUserRole;
}

Первый перехватчик применяется к набору сущностей Products и гарантирует, что пользователи смогут извлекать только те сущности, которые были созданы ими самими.Второй перехватчик обеспечивает чтение заказов с флагом Private лишь пользователями, включенными в роль PrivateOrders.

Аналогичным образом можно указать перехватчики изменений, выполняемые до вставки сущности, ее модификации или удаления:

[ChangeInterceptor("Products")]
public void OnChangeProducts(Product product, UpdateOperations operations
{
  if (product.CreatedBy != Thread.CurrentPrincipal.Identity.Name)
  {
    throw new DataServiceException(
      "Only products created by a user can be deleted by that user");
  }
}

При первом взгляде может показаться, что перехватчик изменений OnChangeProducts в этом примере кода создает дыру в защите, так как эта реализация полагается на данные, передаваемые из внешнего источника в параметре product.Но при удалении сущности в WCF Data Services клиент передает на сервер только ключ сущности.Это означает, что саму сущность — в нашем случае Product — нужно заново извлечь из базы данных и поэтому ей можно доверять.

Однако в случае обновления имеющейся сущности (например, когда параметр operations содержит UpdateOperations.Change) параметр product является десериализованной сущностью, которая отправлена клиентом, а потому ей нельзя доверять.Клиентское приложение могло быть модифицировано, чтобы в свойстве CreatedBy данного конкретного продукта содержалась идентификация злоумышленника, и тем самым он повысил бы уровень своих привилегий.А это позволило бы модифицировать сущность тому, у кого нет на это прав.Чтобы избежать этого, советую повторно извлекать исходную сущность из доверяемого источника данных, основываясь только на ключе этой сущности, как показано на рис. 6.

Рис. 6 Перехватчик изменений, предотвращающий несанкционированные операции вставки, обновления и удаления

[ChangeInterceptor("Products")]
Public void OnChangeProducts(Product product, UpdateOperations operations)
{
  if (operations == UpdateOperations.Add)
  {
    product.CreatedBy = Thread.CurrentPrincipal.Identity.Name;
  }
  else if (operations == UpdateOperations.Change)
  {
    Product sourceProduct = this.CurrentDataSource.Products.Where(p =>
      p.Id == product.Id).First();
    if (sourceProduct.CreatedBy != Thread.CurrentPrincipal.Identity.Name)
    {
      throw new DataServiceException(
        "Only records created by a user can be modified by that user");
    }
  }
  else if (operations == UpdateOperations.Delete &&
    product.CreatedBy != Thread.CurrentPrincipal.Identity.Name)
  {
    Throw new DataServiceException(
      "Only records created by a user can be deleted by that user");
  }
}

Поскольку эта реализация столь сильно полагается на свойство CreatedBy сущности Product, крайне важно, чтобы такая политика принудительно вводилась надежным способом с момента создания данных.На рис. 6 также показано, как достичь этого переопределением любого значения, переданного клиентом для операции Add.

Заметьте, что в текущем состоянии примера обработка операций типа UpdateOperations.Change не вызвала бы проблем с безопасностью.На рис. 4 сервис был сконфигурирован на прием операций только с разрешениями AllRead, WriteAppend (вставка) и WriteDelete применительно к наборам сущностей Products.Значит, ChangeInterceptor никогда не был бы вызван для операции Change, так как сервис немедленно отклонял бы любой запрос на модификацию сущности Product в этой конечной точке.Чтобы разрешить обновления, вызов SetEntitySetAccessRule на рис. 4 должен был бы включать WriteMerge либо WriteReplace или т то, и другое.

Междоменная аутентификация

Плагин Silverlight может выдавать междоменные HTTP-запросы.Междоменный вызов — это HTTP-запрос, адресованный домену, отличному от того, с которого было скачано приложение Silverlight.Возможность таких вызовов традиционно рассматривалась как уязвимость в защите.Благодаря ей злонамеренный разработчик мог бы выдавать запросы к другому сайту (например, вашему сайту онлайновых банковских операций) и автоматически пересылать любые cookie, сопоставленные с тем доменом.Потенциально это могло бы открыть атакующему доступ к другому сеансу в том же процессе браузера.

По этой причине сайты должны использовать поддержку междоменных вызовов только через развертывание файла междоменной политики.Это XML-файл, описывающий, какие типы междоменных вызовов разрешены, например из какого домена на какие URL.Более подробную информацию см. в статье «Making a Service Available Across Domain Boundaries» по ссылке (msdn.microsoft.com/library/cc197955(VS.95)).

Всегда проявляйте осторожность, решая, можно ли передавать какую-либо конфиденциальную информацию в междоменных вызовах.Но если вы решили, что этот вариант вам необходим для поддержки дополнительной аутентификации (alongside authentication), важно отметить, что способы аутентификации с использованием cookie вроде описанной ранее аутентификации на основе форм больше не годятся.Вместо этого вы должны подумать о применении удостоверений сообщений (message credentials), в которых имя и пароль пользователя передаются на сервер и проверяются при каждом вызове.WCF поддерживает такой вариант в режиме защиты TransportWithMessageCredential.Подробнее см. в статье «How to: Use Message Credentials to Secure a Service for Silverlight Applications” (msdn.microsoft.com/library/dd833059(VS.95)).

Конечно, этот подход напрочь исключает ASP.NET из процесса аутентификации, и использовать авторизацию средствами ASP.NET, рассмотренную ранее, будет весьма затруднительно.

Защита XAP-файлов Silverlight

Те, кто обеспокоен безопасностью Silverlight, часто спрашивают:«Как защитить свои XAP-файлы?». Иногда мотивация такого вопроса кроется в желании защитить интеллектуальную собственность, содержащуюся в самом коде.В таком случае вам нужно подумать о «затемнении» (obfuscation) кода, чтобы затруднить его анализ другими людьми.

Другой распространенный мотив — исключение вмешательства злоумышленников в код и возможности понять, как устроено данное приложение Silverlight; ведь это потенциально позволило бы нарушить работу ваших сервисов.

Обычно я отвечаю на это двумя тезисами.Во-первых, хотя скачивание вашего приложения Silverlight (файла с расширением .xap) можно ограничить кругом лишь аутентифицированных и авторизованных пользователей, нет никаких оснований доверять этим пользователям больше, чем любым анонимным.Так как приложение скачивается на клиентский компьютер, абсолютно ничто не может остановить пользователей от вмешательства в ваш код в попытке повысить свои привилегии или переслать библиотеки стороннему лицу.Затемнение кода может несколько усложнить этот процесс, но и не более того.

Во-вторых, крайне важно помнить:любой, кто может на законных основаниях вызывать сервисы через ваше приложение Silverlight, также может напрямую обращаться к этим сервисам, например используя браузер и написав немного кода на JavaScript.Вы никак не можете предотвратить это, так что гораздо важнее сосредоточить свои усилия на укреплении защиты своих сервисов.Делайте это правильно, и тогда не будет иметь никакого значения, что там сумеет выискать злоумышленник в коде вашего приложения Silverlight.Тем не менее, некоторые все еще считают, что нужно допускать к XAP-файлам только аутентифицированных пользователей.Это, конечно, возможно, но насколько сложно — зависит от используемой вами версии IIS и выбранного вами способа аутентификации.

Если вы применяете аутентификацию средствами Windows, то можете легко защитить свои XAP-файлы с помощью IIS Directory Security.Но, если вы используете аутентификацию на основе форм, дело несколько усложняется.В таком случае придется в FormsAuthenticationModule перехватывать и проверять cookie, сопутствующий каждому запросу, и разрешать или отклонять доступ к запрошенному ресурсу.

Поскольку FormsAuthenticationModule является модулем ASP.NET, запрос должен проходить через конвейер ASP.NET, чтобы такой анализ был возможен.В IIS6 (Windows Server 2003) и более ранних версиях запросы на XAP-файлы по умолчанию не проходят через конвейер ASP.NET.

В IIS7 (Windows Server 2008), однако, введен Integrated Pipeline, который позволяет всем запросам проходить через конвейер ASP.NET.Если у вас есть возможность развертывания в IIS7 и использования пула приложений, выполняемых в режиме Integrated Pipeline, тогда защитить XAP-файлы не труднее, чем SVC-файлы, как пояснялось в разделе по авторизации через ASP.NET.Но если вы должны выполнить развертывание в IIS6 или более ранних версиях, то, вероятно, вам придется проделать дополнительную работу.

Один из популярных подходов включает потоковую передачу байтов XAP-файла через другое расширение, которое обрабатывается конвейером ASP.NET.Типичный способ достигнуть этой цели — реализация IHttpHandler (в файле с расширением .ashx).Подробнее см. в «Introduction to HTTP Handlers» (msdn.microsoft.com/library/ms227675(VS.80)).

Другой подход — модифицировать конфигурацию IIS так, чтобы XAP-файлы проходили через конвейер ASP.NET.Однако, поскольку это потребует нетривиального изменения конфигурации IIS, предыдущей подход является более распространенным.

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

Вы можете выбрать один из двух подходов.

1. Необходимо иметь два отдельных приложения Silverlight.Первое должно содержать диалоговое окно входа и находиться в незащищенной области сайта.При успешном входе в систему оно перенаправит на страницу с указанием XAP-файла в защищенной области сайта.
2. Разбить свое приложение на два или более модуля.Начальный XAP-файл, размещенный в незащищенной области сайта, выполняет процесс аутентификации.В случае успеха этот XAP-файл запрашивает следующий XAP-файл в защищенной области, который может быть динамически загружен в приложение Silverlight.Не так давно я написал об этом статью в блоге (thejoyofcode.com/How_to_download_and_crack_a_Xap_in_Silverlight.aspx).