PBC205ILL€¦ · 2.4. Задание 4: тестирование приложения в эмуляторе Windows Azure 26 2.5. Задание 5: развертывание приложения

PBC205ILL

Лабораторная работа

Использование

федеративной

аутентификации в веб-

приложении под Windows

Azure

2 Microsoft Tech∙Ed Russia 2011. Лабораторная работа.

Использование федеративной аутентификации в веб-приложении под Windows Azure.

Содержание

1. ОБЗОР ЛАБОРАТОРНОЙ РАБОТЫ ................................................................................................ 3 1.1. Описание 3

1.2. Краткое введение в Windows Identity Foundation для Windows Azure разработчиков 3

1.3. Краткое введение в Windows Azure для Windows Identity Framework разработчиков 3

1.4. Цели 4

1.5. Системные требования 4

1.6. Настройка 5

1.7. Использование фрагментов кода 5

1.8. Упражнения 5

2. УПРАЖНЕНИЕ 1: ИСПОЛЬЗОВАНИЕ ФЕДЕРАТИВНОЙ АУТЕНТИФИКАЦИИ В WINDOWS

AZURE .......................................................................................................................................................... 5 2.1. Задание 1: создание Windows Azure проекта и подготовка Windows Identity Foundation 7

2.2. Задание 2: создание локального STS 17

2.3. Задание 3: установление доверия между веб-ролью и STS 20

2.4. Задание 4: тестирование приложения в эмуляторе Windows Azure 26

2.5. Задание 5: развертывание приложения в Облаке 29

3. ЗАКЛЮЧЕНИЕ................................................................................................................................... 38

Внимание: 1. Для выполнения данной лабораторной работы

необходима учетная запись Windows Azure 2. Все описанные в данном документе материалы находятся

в каталоге C:\WAPTK\Labs\WindowsAzureAndPassiveFederation \

3. Пароль для входа в систему: Passw0rd!



1. Обзор лабораторной работы

1.1. Описание

Данная лабароторная работа предоставляет пошаговую инструкцию по развертыванию

веб-приложения в Windows Azure, которое принимает удостоверения от внешнего

провадера индентификации (Identity Provider). Схема позволяет абстрагироваться от

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

приложения. Предложенную схему можно легко построить за счет использования

библиотеки Windows Identity Foundation (WIF), ранее известной под названием Geneva.

Руководство содержит конкретные шаги для постороения данного сценария, которые

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

руководство включает комментарии для тех, кто хочет получить дополнительную

информацию или детально понять, как работает схема. Если вас интересуют только основы

и вашей целью является запуск сценария, то вы можете пропустить комментарии и

следовать дальнейшим инструкциям.

1.2. Краткое введение в Windows Identity Foundation для Windows

Azure разработчиков

Windows® Identity Foundation (WIF) – набор компонентов, который расширяет стандартные

возможности .NET Framework, добавляя расширенные функции по работе с

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

удостоверениям, предоставляет набор классов, которые без шовно интегрируются с .Net

Framework, контролирующих каждый аспект аутентификации, авторизации и работе с

удостоверениями приложения. Инструменты, встроенные в Visual Studio позволяют

разработчику легко настроить прием удостоверений от федеративного партнера

аутентификации, позволяя приложению или веб-сервису доверить функции управления

паролями и аккаунтами партнеру. WIF позволяет использовать открытые протоколы и

стандарты простым способом, абстрагируясь от общей сложности схемы безопасности.

Библиотека работает на .Net Framework 3.5 SP2 или новее.

Более подробную информацию можно найти на официальном сайте продукта.

1.3. Краткое введение в Windows Azure для Windows Identity

Framework разработчиков

Windows® Azure – облачная операционная система, предоставляющая сервисы и среду для

разработки, размещения и управления приложениями на платформе Windows Azure.

Платформа предоставляет разработчикам вычислительные мощности и хранилища

данных для размещения, масштабирования и управления веб-приложениями через

интернет, находящимися в дата центрах Microsoft.

http://www.microsoft.com/wif



Visual Studio содержи набор шаблонов Windows Azure приложений, которые могут быть

использованы для разработки ASP.Net приложений (веб-ролей) и рабочих ролей (фоновых

сервисов), которые в последующем могут быть опубликованы в облако. Инструменты

Windows Azure для Visual Studio включают эмулятор Windows Azure Compute, который

позволяет запускать приложения на локальной машине. Инструменты дают возможность

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

отладки и разработки, не имея доступа к реальному облаку.

Приложения Windows Azure могут быть упакованы с помощью Visual Studio или

инструментов командной строки и затем опубликованы в облако через Портал управления

Windows Azure.

Более подробную информацию можно найти в центре Windows Azure разработчика

Русского MSDN или на официальном сайте продукта.

1.4. Цели

В данной лабораторной работе вы узнаете как:

Создать простой ASP.Net сайт в проекте Windows Azure, настроить федеративную

связь с провайдером аутентификации. В качестве примера провайдера

аутентификации будет использован локальный тестовый Security Token Service

(STS).

Тестировать Windows Azure веб-роль в локальном эмуляторе.

Развернуть приложение в реальном облаке и проверить его работоспособность.

1.5. Системные требования

Необходимы следующие системные требования для выполнения лабораторной работы:

Microsoft® Windows® Vista SP2 (32-bits or 64-bits) , Microsoft® Windows Server 2008 SP2

(32-bit or 64-bit), Microsoft® Windows Server 2008 R2, Microsoft® Windows® 7 RTM (32-

bits or 64-bits)

Microsoft® Internet Information Services (IIS) 7.0 с IIS Metabase или IIS 6 configuration

compatibility

Microsoft® .NET Framework 4

Microsoft® Visual Studio 2010

Microsoft® Windows Identity Foundation Runtime

Microsoft® Windows Identity Foundation SDK 4.0

Windows Azure Tools for Microsoft Visual Studio 1.4

https://windows.azure.com/

https://windows.azure.com/

http://msdn.microsoft.com/ru-ru/windowsazure

http://msdn.microsoft.com/ru-ru/windowsazure

http://www.microsoft.com/azure/windowsazure.mspx

http://go.microsoft.com/fwlink/?linkid=186916

http://www.microsoft.com/visualstudio/en-us/products/2010-editions/

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=eb9c345f-e830-40b8-a5fe-ae7a864c4d76

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c148b2df-c7af-46bb-9162-2c9422208504

http://go.microsoft.com/fwlink/?LinkID=128752



1.6. Настройка

Необходимо выполнить следующие шаги для подготовки вашего компьютера к

лабораторной работе:

1. Открыть в Windows Explorer папку

C:\WAPTK\Labs\WindowsAzureAndPassiveFederation\Source\Setup

2. Запустить двойным кликом мышки файл Dependencies.dep, который установит все

необходимые для лабораторной работы компоненты и настройки. Также, он

устанавливает фрагменты кода и сертификат, используемый STS.

Заметка: Данная процедура может потребовать привилегированного режима запуска.

Формат .dep ассоциирован с инструментом Dependency Checker во время установки.

Дополнительную информацию, относящуюся к установке можно найти в Setup.docx в

папке Assets тренировочного комплекта.

Заметка: Данная процедура устанавливает само подписанный сертификат. Если у вас уже

установлен сертификат с именем CN=localhost, вам необходимо его сохранить и

восстановить после завершения процедуры.

1.7. Использование фрагментов кода

В ходе выполнения работы вам необходимо будет вставлять блоки кода. Для вашего

удобства большая часть кода предоставлена в виде Visual Studio Code Snippets, которые вы

можете использовать из Visual Studio 2010, не вставляя код вручную.

Если вы не знакомы с Visual Studio Code Snippets и хотите узнать как их использовать,

необходимую информацию можно найти в Setup.docx в папке Assets тренировочного

комплекта.

1.8. Упражнения

В ходе данной лабораторной работы вы выполните следующие упражнения:

1) Использование федеративной аутентификации в Windows Azure

2. Упражнение 1: использование федеративной аутентификации

в Windows Azure

Защитить ASP.Net приложения с помощью WIF очень просто. Используя Visual Studio вы

кликаете по проекту, запускаете простой мастер, в котором вы указываете необходимого

федеративного провайдера партнера, от которого хотите принимать удостоверения, и все



готово. У вас даже есть возможность создать локальный тестовый провайдер, который

может быть использован во время разработки, пока у вас нет реальных партнеров.

В случае Windows Azure вам необходимо выполнить дополнительные простые шаги,

которые позволяют произвести необходимые настройки Windows Azure, которые

обусловлены особенностями устройства платформы. Например, хранение сертификатов и

ссылки, используемые приложением.

В данном упражнении вы увидите, как создать Windows Azure веб-роль, настроить её на

использование локального STS и изменить Windows Azure проект для запуска в эмуляторе

Windows Azure. В итоге вы опубликуете проект в реальном облаке и увидите, что оно по-

прежнему работает во всех средах.

Данная лабораторная работа иллюстрирует базовые, наиболее распространенные

сценарии интеграции WIF и Windows Azure. Например, в качестве реального провайдера

аутентификации может быть использован ADFS 2.0.

Рисунок 1

Резюме по предстоящим шагам данного упражнения. Вы начинаете с того, что

создаете ASP.Net веб-сайт (RP – relying party, зависимая сторона) в Windows Azure веб-

роли, STS (провайдер аутентификации) для него и устанавливаете между ними связь.

Для заключительного тестирования вы публикуете веб-роль в тестовое и рабочее



окружение облака. Для упрощения разработки и тестирования на протяжении всей

работы используется локальный STS.

2.1. Задание 1: создание Windows Azure проекта и подготовка

Windows Identity Foundation

1. Запустите Visual Studio 2010 в привилегированном режиме.

2. Создайте новый проект File -> New -> Project

3. В диалоге выберите шаблон Cloud

4. Выберите тип проекта Windows Azure Project

5. Выберите уникальное имя для вашего проекта. Установите имя решения Begin и путь

до папки

%YourInstallationFolder%\Labs\WindowsAzureAndPassiveFederation\Source\Ex1-

AzureFederatedAuthentication\. Убедитесь в том, что выбрана опция Create directory for

solution и версия .NET Framework 4. Нажмите OK для создания проекта.

Рисунок 2

Создание нового Windows Azure проекта

Заметка: Почему нужно задавать собственное уникальное имя для проекта, а не

указать такое же имя как у решения?

Каждый Windows Azure сервис публикуется по уникальной ссылке вида

<projectname>.cloudapp.net



6. В новом Windows Azure Project диалоге раскройте роли для Visual C# и выберите ASP.NET

Web Role из списка доступных ролей нажатием стрелки (>) для добавления экземпляра

роли в решение. Перед закрытием диалога нажмите на карандаш у выбранной роли и

измените её имя на FederatedIdentity_WebRole. Нажмите OK для создания Windows Azure

решения.

Рисунок 3

Назначение ролей Windows Azure проекту

7. Создайте само подписанный сертификат для использования SSL веб-сайтом. Для

вашего удобства, лабораторная работа содержит скрипт, который выполняет все

необходимые действия. Он создает сертификат с указанным вами именем и

устанавливает его в LocalMachine/Personal хранилище сертификатов и добавляет его в

LocalMachine/Trusted Root Certification Authorities (для предотвращения ошибок в IE

при просмотре страниц приложения). Откройте Visual Studio command prompt от

имени администратора (Start -> All -> Programs -> Microsoft Visual Studio 2010 -> Visual

Studio Tools -> Visual Studio Command Prompt (2010)).

8. Измените текущую директорию на

%YourInstallationFolder%\Labs\WindowsAzureAndPassiveFederation\Source\Assets, где

папка %YourInstallationFolder%, в которую была установлена лабораторная работа, и

запустите CreateCert.cmd скрипт, который принимает в качестве параметра имя вашего

проекта.



Заметка: ОЧЕНЬ ВАЖНО! Убедитесь в то, что имя сертификата задано в нижнем

регистре.

Пример:

Visual Studio Command Prompt

CreateCert.cmd yourprojectname

Во время выполнения скрипта вас попросят ввести пароль для защиты закрытого ключа

сертификата. Введите abc!123 и нажмите OK.

Рисунок 4

Выбор пароля для защиты закрытого ключа

Рисунок 5

Ввод пароля для установки ключа во второе хранилище

Когда вы устанавливаете сертификат в Trusted Root Certification Authorities хранилище,

вам покажут предупреждение, на которое нужно ответить Yes для успешной установки

сертификата.



Рисунок 6

Добавление сертификата в trusted root

9. Откройте Solution Explorer и перейдите в <yourproject>/Roles/FederatedIdentity_WebRole.

Нажмите правую кнопку мышки и выберите свойства веб-роли.

Рисунок 7

Изменение свойств FederatedIdentity_Webrole



10. Перейдите в раздел Configuration и убедитесь в том, что выбрана опция Full Trust.

Рисунок 8

Установка full trust для FederatedIdentity_WebRole

Заметка: Почему требуется установить полный уровень доверия?

Библиотека WIF и многие части WCF, занимающиеся криптографией требуют запуска в

окружении с полным доверием.

11. Перейдите на вкладку Certificates и нажмите Add Certificate.

Рисунок 9

Выбор сертификата

12. Введите имя вашего проекта <projectName> в поле Name и нажмите на колонку

Thumbprint для выбора сертификата, который был создан на предшествующих шагах.



Рисунок 10

Выбор сертификата, который был создан ранее

13. На вкладке Endpoints добавьте новую Https точку. Для этого нажмите Add Endpoint и

установите следующие значения:

◦ Name: HttpsIn

◦ Type: Input

◦ Protocol: https

◦ Public Port: 8080

◦ SSL Certificate Name: <yourprojectname>

Рисунок 11

Добавление Https точки

14. Удалите HTTP точку. Выберите существующую точку “Endpoint1” и нажмите Remove

Endpoint.



Рисунок 12

Удаление Http точки

15. Нажмите Ctrl-S для сохранения параметров.

16. В Solution Explorer кликните правой кнопкой мыши по FederatedIdentity_WebRole и

выберите Add Reference. На вкладке .NET выберите Microsoft.IdentityModel и нажмите

OK.

17. В папке References проекта FederatedIdentity_WebRole выберите Microsoft.IdentityModel

и нажмите F4 для открытия свойств. Установите свойству Copy Local значение True и

Specific Version значение False.

Заметка: Зачем выставлять Copy Local значение True?

Библиотеки Microsoft.IdentityModel нету в GAC Windows Azure Compute, поэтому её

необходимо скопировать локально и залить в рамках пакета приложения.

18. Добавьте необходимые пространства имен в Default.aspx.cs в FederatedIdentity_WebRole.

(Code Snippet – Federated Authentication for WebRole Guide – RP Usings)

C#

using System;

using System.Collections.Generic;

using System.Linq;

using System.Web;

using System.Web.UI;

using System.Web.UI.WebControls;

using Microsoft.IdentityModel.Claims;

using System.Threading;

19. Вставьте следующий код в тело функции Page_Load.



(Code Snippet – Federated Authentication for WebRole Guide – RP Page_Load Body)

C#

namespace FederatedIdentity_WebRole

{

public partial class _Default : System.Web.UI.Page

{

protected void Page_Load(object sender, EventArgs e)

{

IClaimsPrincipal icp = Thread.CurrentPrincipal as IClaimsPrincipal;

IClaimsIdentity ici = icp.Identity as IClaimsIdentity;

Response.Write("Welcome to Fabrikamair <br/><br/>:Claims:<br/>");

foreach (Claim c in ici.Claims)

Response.Write(c.ClaimType + "-" + c.Value + "<br/>");

}

}

}

20. Откройте файл Default.aspx и замените его содержимое на код ниже.

ASP.NET

<%@ Page Title="Home Page" Language="C#" AutoEventWireup="true"

CodeBehind="Default.aspx.cs" Inherits="FederatedIdentity_WebRole._Default" %>

21. Замените используемые пространства имен в FederetedIdentity_WebRole в Global.asax на

следующие.

(Code Snippet – Federated Authentication for WebRole Guide – RP Global.asax Using)

C#

using System;

using System.Collections.Generic;

using System.Web;

using System.Text;

using Microsoft.IdentityModel.Tokens;

using Microsoft.IdentityModel.Web;

using Microsoft.IdentityModel.Web.Configuration;

22. Добавьте метод WSFederationAuthenticationModule_RedirectingToIdentityProvider с

указанным ниже кодом:

(Code Snippet – Federated Authentication for WebRole Guide – RP Global.asax

RedirectingToIdentityProvider)

C#

public class Global : System.Web.HttpApplication



{

...

/// <summary>

/// Retrieves the address that was used in the browser for accessing

/// the web application, and injects it as WREPLY parameter in the

/// request to the STS

/// </summary>

void WSFederationAuthenticationModule_RedirectingToIdentityProvider(object

sender, RedirectingToIdentityProviderEventArgs e)

{

//

// In the Windows Azure environment, build a wreply parameter for the SignIn

request

// that reflects the real address of the application.

//

HttpRequest request = HttpContext.Current.Request;

Uri requestUrl = request.Url;

StringBuilder wreply = new StringBuilder();

wreply.Append(requestUrl.Scheme); // e.g. "http" or "https"

wreply.Append("://");

wreply.Append(request.Headers["Host"] ?? requestUrl.Authority);

wreply.Append(request.ApplicationPath);

if (!request.ApplicationPath.EndsWith("/"))

wreply.Append("/");

e.SignInRequestMessage.Reply = wreply.ToString();

}

...

}

Заметка: Зачем нужен

WSFederationAuthenticationModule_RedirectingToIdentityProvider?

Процесс федеративного входа, построенный на базе WIF, использует WS-Federation

протокол. Все не аутентифицированные пользователи должны быть перенаправлены на

доверенный STS, который позволит им аутентифицироваться, и создаст удостоверение

(токен). Редирект происходит на специальный адрес, в рамках которого идут различные

параметры, в том числе и параметр, содержащий адрес возврата. По умолчанию адрес

возврата хранится в web.config, который туда добавляется инструментами WIF при

настройке доверенного провайдера. При заливке в Window Azure данный параметр

должен измениться, потому что ссылка сайта изменится. Чтобы не менять каждый раз

настройки создается данный метод, который это делает динамически внутри

приложения.



Почему мы используем Host заголовок HttpContext.Current.Request.Url вместо

традиционного метода?

Windows Azure имеет сложную сетевую инфраструктуру. В результате чего свойство Url

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

обойти данное ограничение.

23. Добавьте метод OnServiceConfigurationCreated в Global.asax.cs.


ServiceConfiguration_Created)

C#


{

...

void OnServiceConfigurationCreated(object sender,

ServiceConfigurationCreatedEventArgs e)

{

//

// Use the <serviceCertificate> to protect the cookies that are

// sent to the client.

//

List<CookieTransform> sessionTransforms =

new List<CookieTransform>(new CookieTransform[] {

new DeflateCookieTransform(),

new

RsaEncryptionCookieTransform(e.ServiceConfiguration.ServiceCertificate),

new RsaSignatureCookieTransform(e.ServiceConfiguration.ServiceCertificate)

});

SessionSecurityTokenHandler sessionHandler = new

SessionSecurityTokenHandler(sessionTransforms.AsReadOnly());

e.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace(sessionHandler);

}

...

}

Заметка: Зачем нужен ServiceConfigurationCreated ?

По умолчанию сессионные куки WIF шифруются с помощью DPAPI, который не доступен

в Windows Azure. Необходимо использовать альтернативный механизм. В данном случае

мы используем RsaEncryptionCookieTransform, который шифрует их с помощью того же

сертификата, что и SSL.



24. Зарегистрируйте обработчик OnServiceConfigurationCreated в методе Application_Start в

Global.asax.cs.


Application_Start)

C#

...


{

void Application_Start(object sender, EventArgs e)

{

FederatedAuthentication.ServiceConfigurationCreated +=

OnServiceConfigurationCreated;

}

...

}

2.2. Задание 2: создание локального STS

1. Нажмите правой кнопкой на решении и выберите Add -> New Web Site. Выберите шаблон

ASP.NET Security Token Service Web Site. Выберите адрес вашего сайта

https://localhost/[yourprojectname]_sts для создания его на локальном IIS. Убедитесь в

том, что вы используете .NET Framework 4 и нажмите OK.

https://localhost/%5byourprojectname%5d_sts



Рисунок 13

Создание локального STS веб-сайта

2. Откройте CustomSecurityTokenService.cs в

https://localhost/[yourprojectname]_sts/App_Code. Добавьте следующий метод в класс

CustomSecurityTokenService, над GetScope.

(Code Snippet – Federated Authentication for WebRole Guide – STS ValidateReplyTo)

C#

public class CustomSecurityTokenService : SecurityTokenService

{

...

/// <summary>

/// Validates replyTo and throws an exception if the replyTo refers to a

/// RP that is not on the local machine or is not hosted in Windows Azure

/// </summary>

/// <param name="replyTo">

/// The replyTo parameter in the request that came in (RST)

/// </param>

void ValidateReplyTo(string replyTo)

{

// if ReplyTo is empty, we have nothing to validate. We will default

// to AppliesTo, which is harder to compromise via redirect attack



if (!String.IsNullOrEmpty(replyTo))

{

string host = (new Uri(replyTo)).Host.ToLower();

if (!((host == "127.0.0.1")

|| (host == "localhost")

|| host.EndsWith(".cloudapp.net")))

{

throw new InvalidRequestException(

String.Format(

"The host in the ReplyTo address {0} is not valid.",

host));

}

}

}

/// <summary>

/// This method returns the configuration for the token issuance request. The

configuration

/// is represented by the Scope class. In our case, we are only capable of

issuing a token for a

/// single RP identity represented by the EncryptingCertificateName.

/// </summary>

/// <param name="principal">The caller's principal.</param>

/// <param name="request">The incoming RST.</param>

/// <returns>The scope information to be used for the token

issuance.</returns>

protected override Scope GetScope( IClaimsPrincipal principal,

RequestSecurityToken request )

{

ValidateAppliesTo( request.AppliesTo );

...

}

3. Добавьте вызов метода ValidateReplyTo после ValidateAppliesTo.

(Code Snippet – Federated Authentication for WebRole Guide – ValidateReplyTo Call)

C#

...



{

ValidateAppliesTo( request.AppliesTo );

ValidateReplyTo(request.ReplyTo);

//

// Note: The signing certificate used by default has a Distinguished name

of "CN=STSTestCert",



// and is located in the Personal certificate store of the Local Computer.

Before going into production,

// ensure that you change this certificate to a valid CA-issued

certificate as appropriate.

//

Scope scope = new Scope( request.AppliesTo.Uri.OriginalString,

SecurityTokenServiceConfiguration.SigningCredentials );

...

4. В конце GetScope закомментируйте текущий scope.ReplyToaddress и замените на следующий

код.

(Code Snippet – Federated Authentication for WebRole Guide – STS Redirect to ReplyTo)

C#



{

...

// Set the ReplyTo address for the WS-Federation passive protocol (wreply). This

is the address to which responses will be directed.

// In this template, we have chosen to set this to the AppliesToAddress.

scope.ReplyToAddress = String.IsNullOrEmpty(request.ReplyTo) ?

scope.AppliesToAddress : request.ReplyTo;

return scope;

}

2.3. Задание 3: установление доверия между веб-ролью и STS

1. В Solution Explorer нажмите правкой кнопкой на FederatedIdentity_WebRole и выберите

Add STS reference. Подтвердите предложенный адрес конфигурации и установите URI

приложения https://<yourProjectName>.cloudapp.net и нажмите далее.



Рисунок 14

Первый экран мастера настройки федерации

2. Выберите опцию Use an existing STS и укажите путь до файла с мета данными %your inetpub

folder%\wwwroot\<yourProjectName>_sts\FederationMetadata\2007-06\FederationMetadata.xml и

нажмите далее.



Рисунок 15

Второй экран мастера настройки федерации

3. Выберите опцию без шифрования No encryption и нажмите далее.



Рисунок 16

Экран шифрования федерации

4. Нажмите далее



Рисунок 17

Утверждения поддерживаемые STS.

5. Нажмите Finish



Рисунок 18

Заключение

6. Добавьте элемент serviceCertificate в Web.config веб-роли. Укажите верный отпечаток

сертификата. Его можно найти в ServiceConfiguration.cscfg.

(Code Snippet – Federated Authentication for WebRole Guide – ServiceCertificate)

XML

<microsoft.identityModel>

<service>

...

<serviceCertificate>

<certificateReference x509FindType="FindByThumbprint"

findValue="[yourCorrespondingThumbprint]"/>

</serviceCertificate>

</service>

</microsoft.identityModel>

7. Добавьте элемент certificateValidation с атрибутом certificateValidationMode = None

(Code Snippet – Federated Authentication for WebRole Guide – CertificateValidation)

XML



<microsoft.identityModel>

<service>

...

</serviceCertificate>

<certificateValidation certificateValidationMode="None"/>

</service>

</microsoft.identityModel>

8. ASP.NET по умолчанию проверяет все POST запросы к приложению, проверяет все входные

параметры. В случае если XML не закодирован, ASP.NET считает его опасным и выдает ошибку.

Токен является не шифрованным XML. Для исправления этой ошибки необходимо создать

валидатор, который будет проверять токен на его правильность.

Добавить SampleRequestValidator.cs из папки Assets в проект FederatedIdentity_WebRole.

Добавить в тот же проект в настройки следующие записи.

XML

...

<httpRuntime requestValidationType="SampleRequestValidator" />

</system.web>

2.4. Задание 4: тестирование приложения в эмуляторе Windows

Azure

В данном задание вы запустить веб-приложение в эмуляторе Windows Azure, в том время

как STS, созданный в задании 2 будет работать на локальном IIS.

Рисунок 19

Развертывание на локальной машине

В данный момент вы полностью готовы для тестирования приложения в Windows Azure

эмуляторе. Установите облачный проект как стартовый. Нажмите F5 для сборки и запуска

проекта. Браузер откроется на странице https://127.0.0.1:8080. На первом экране вы

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

https://127.0.0.1:8080/



IP адреса для обращения, а сертификат предназначен для определенного домена.

Нажмите продолжить.

Рисунок 20

Предупреждение о сертификате

После подтверждения вы будете перенаправлены на локальный STS. Нажмите Submit.



Рисунок 21

Страница аутентификации

STS издает токен и перенаправляет на веб-роль, размещенную в эмуляторе, WIF проверяет токен и

выдает пользователю доступ на сайт. В данном случае используется пассивная форма федерации,

в которой токен передается через не видимую автоматически отправляющуюся форму. WIF на

стороне STS автоматически создает страницу с этой формой и вызывает её.

Рисунок 22



Веб-приложение в работе

2.5. Задание 5: развертывание приложения в Облаке

Теперь, когда вы проверили работоспособность приложения в эмуляторе, можно

преступить к развертыванию в реальном облаке.

Рисунок 23

Развертывание в облаке

В данном задании вы развернете приложение в тестовом окружении (staging), протестирует его и

переместите в конечную, эксплуатационную среду (production).

1. Перейдите в браузере на портал http://windows.azure.com и войдите с помощью Live ID.

http://windows.azure.com/



Рисунок 24

Вход на портал управления

2. Создайте вычислительный компонент, который позволяет запускать код приложений. Для этого

создайте новый Hosted Service, нажмите New Hosted Service.

Рисунок 25



Создание hosted сервиса

3. В появившемся диалоге выберите подписку, в которой собираетесь создать сервис. Укажите

уникальное имя проекта внутри вашей подписки и url, который будем фактическим адресом

доступа к приложению (уникальный в системе). Выберите опцию развертывания Do not deploy и

регион размещений Anywhere Europe.

Рисунок 26

Создание нового hosted сервиса



4. Нажмите OK и дождитесь завершения процесса подготовки сервиса

Рисунок 27

Успешное развертывание Hosted сервис

Перед тем как залить пакет с нашим приложением нам необходимо убедиться в том, что в данном

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

5. В нашем окружении нет необходимого сертификата, необходимо его добавить. Для этого

выбираем сервис, папку Certificates и нажимаем Add Certificate.

Рисунок 28

Добавление сертификата

Необходимый сертификат находится по адресу

%YourInstallationFolder%\Labs\WindowsAzureAndPassiveFederation\Source\Assets\certs\<yourpPr



ojectName>.cloudapp.net.pfx. Для его успешного добавления необходимо ввести пароль, который

использовался при его создании.

Рисунок 29

Добавление сертификата

Рисунок 30

Добавленный сертификат

6. Теперь мы готовы к публикации приложения. Для публикации приложения необходимо сделать

пакет развертывания со всем кодом и данными. Для этого в Solution Explorer выберите облачный

проект и нажмите Publish. В диалоге выберите опцию Create Service Package Only и нажмите OK.



Рисунок 31

Создание пакета развертывания

7. Развернуть пакет можно с помощью портала, выбрав сервис и нажав New Staging Deployment

Рисунок 32

Развертывание пакета на портале

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

этапах и нажмите OK.



Рисунок 33

Развертывание в тестовом окружении

Рисунок 34



Пакет развернут в тестовом окружении и готов к работе

Необходимо некоторое время для успешного развертывания и инициализации приложения в

облаке (обычно это занимает 10 минут). После того как приложение получило статус Ready

перейдите по ссылке DNS name. Наше приложение будет располагаться по ссылке вида

<guid>.cloudapp.net. Теперь вы можете проверить работоспособность приложения.

Рисунок 35

Успешный запуск приложения в тестовом окружении.

8. После успешного запуска и выполнения приложения в тестовом окружении его можно

перенести в эксплуатационную среду. Для этого выберите текущий развернутый пакет и нажмите

Swap VIP.



Рисунок 36

Развертывание в эксплуатационном окружении

Теперь проект развернут и готов к работе. Приложение доступно по адресу

https://<yourProjectName>.cloudapp.net:8080

Рисунок 38

Успешное выполнение веб-приложения в эксплуатационном окружении



3. Заключение

Современные распределенные системы требуют единые механизмы контроля доступа.

Одним примером, из которых является система федеративной аутентификации.

В данной лабораторной работе вы узнали и научились как:

1) Создавать приложения с федеративной схемой аутентификации

2) Развертывать приложения, использующие сертификаты и удостоверения, в Windows

Azure

Documents

PBC205ILL€¦ · 2.4. Задание 4: тестирование приложения в эмуляторе Windows Azure 26 2.5. Задание 5: развертывание приложения