【IDM】WIF Extension for SAML 2.0 Protocol Preview版

Posted over 3 years ago

by

junichia

2011/6/16 修正 Auth 2.0 用の Extension が公開されていることを失念していました

WIF（Winodws Identity Foundation）がビールの次に大好きだ！という WIF マニアの皆さま。お待たせしました。

待ちに待ったコンポーネントがリリースされました。

WIF(Windows Identity Foundation） Extension for SAML 2.0 Protocol です。

ダウンロードの詳細 | Microsoft Connect

Protocol ですよ！ Token Format ではありません。

これまでも、Token Format は SAML 2.0 をサポートしていました。が、それを乗せるプロトコルは、WS-*だったんですねぇ。

しかし、今日からは違います。

少なくとも、「WIF は SAML 2.0 に対応する気があるようだ！」と言えるのです。

WIF フリークの皆さまには、これまで本当につらい思いをさせてしまいました。

ちなみに、AD FS 2.0 は SAML 2.0 プロトコルに対応しています。

なので、今後は MS コンポーネントだけで SAML 2.0 を使用したアプリケーションが構築できます。

参考までに、2011年6月時点の MS 製品の各種プロトコルへの対応状況を以下にまとめておきます。

	プロトコル
製品	WS-*	SAML 2.0	OAuth WRAP	OAuth 2.0(Draft 13)	OpenID 2.0
AD FS 2.0	○	○	-	-	-
WIF	○	Preview	-	Preview	-
AppFabric ACS	○	-	○	○	○

残るは ACS ですねぇ。

参考サイト Announcing the WIF Extension for SAML 2.0 Protocol Community Technology Preview! - Claims-Based Identity Blog - Site Home - MSDN Blogs

【Azure for IT Pro】診断モニタにアクセスするための PowerShell スクリプト

Posted over 3 years ago

by

junichia

1 Comment

前回の投稿からかなり時間が経ってしまいました。

【Azure for IT Pro】Windows Azure Service Management（WASM）コマンドレット使い始め

WASMにはさまざまなコマンドレットが用意されているのですが、今回は診断モニタに関するコマンドレットをご紹介します。

Windows Azure のログは、診断モニタと呼ばれる機構により収集されて、ローカルのストレージを介してから Windows Azure ストレージに転送されるようになっています。

事前に、Visual Studio で以下の設定を行っておけば、細かな設定は後から PowrShell コマンドレットを使用して変更することができます。設定にあたっては、Windows Azure ストレージのアカウントとアクセスキーが必要なので、事前に準備しておきましょう。

診断モニタを使用して収集可能な診断ログは以下の5種類です。

ログのタイプ	ログの内容	設定するためのコマンドレット	備考
DiagnosticInfrastructureLogs	診断モニタ自身のログ。診断モニタの動作確認、トラブルシューティングに利用する	Set-InfrastructureLog
Logs	診断モニタの各種設定（ローカルストレージのサイズや転送のタイミングなど）が書かれたログ	Set-WindowsAzureLog
Directories	指定したディレクトリ配下のファイル（IISのアクセスログや独自のテキストログなど）	Set-FileBasedLog	テキストファイルに限らず収集可能
PerformanceCounters	パフォーマンスモニターのカウンターを元に収集されたログ	Set-PerformanceCounter
WindowsEventLogs	イベントログ	Set-WindowsEventLog

まず手始めに、指定したロールに設定されている診断ログの情報をかたっぱしから取得してみましょう。

まずは、以下のスクリプトを拡張子 .PS1 で保存してください。その際、赤で示した部分はご自身の環境の値を設定してください。

## Windows Azure Management Tools を読み込む
Add-PSSnapin AzureManagementToolsSnapIn

## Windows Azure のサブスクリプションID、サービス名、Deployment ID、ロール名
$SubscriptionID="caf29b8c-26de-431d-xxxx-xxxxxxxxxxxx"
$serviceName = "tfazureforitpro"
$deployid = "d8316264497849f4xxxxxxxxxxxxxxx"
$Role = "WebRole1"

## 格納先となるWindows Azure ストレージのアカウント名とキー
$storage = "xxxxxxxxxxxxxxx"
$key = "vHcvyMEyG63MzfWpxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxt8NMoPk4wp7kZJ4pWw=="

## 診断モニタが有効なロールインスタンスを取得して、それぞれの診断ログの設定値を取得する
$RoleInstances = Get-DiagnosticAwareRoleInstances $Role -DeploymentId $deployid -StorageAccountName $storage -StorageAccountKey $key

$RoleInstances | foreach {

$InstanceID = $_

Write-Host "**************" $InstanceID "**************"

    write-host "--- DiagnosticInfrastructureLogs ---"
    $Config = Get-DiagnosticConfiguration -RoleName $Role -InstanceId $InstanceID -StorageAccountName $storage -StorageAccountKey $key -BufferName DiagnosticInfrastructureLogs -DeploymentId $deployId
    $Config | FL

    write-host "--- Directories ---"
    $Config = Get-DiagnosticConfiguration -RoleName $Role -InstanceId $InstanceID -StorageAccountName $storage -StorageAccountKey $key -BufferName Directories -DeploymentId $deployId
    $Config |FL
    $config.DataSources |FL

    write-host "--- Logs ---"
    $Config = Get-DiagnosticConfiguration -RoleName $Role -InstanceId $InstanceID -StorageAccountName $storage -StorageAccountKey $key -BufferName Logs -DeploymentId $deployId
    $Config | FL

    write-host "--- PerformanceCounters ---"
    $Config = Get-DiagnosticConfiguration -RoleName $Role -InstanceId $InstanceID -StorageAccountName $storage -StorageAccountKey $key -BufferName PerformanceCounters -DeploymentId $deployId
    $Config |FL
    $Config.DataSources | FL

    write-host "--- WindowsEventLogs ---"
    $Config = Get-DiagnosticConfiguration -RoleName $Role -InstanceId $InstanceID -StorageAccountName $storage -StorageAccountKey $key -BufferName WindowsEventLogs -DeploymentId $deployId
    $Config | FL
    $config.DataSources |FL

    }

PowerShell のコンソールを開いてスクリプトを実行すると、$Role に指定したロールに含まれるすべてのロールインスタンスから設定情報を取得して画面に表示します（表示データを全く整形していないので見ずらいと思いますが）。

使用しているコマンドレットは2種類です。

Get-DiagnosticAwareRoleInstances は指定したロール（$Role）に含まれている診断モニターが正常に動作しているロールイスタンスの一覧を返します。

返されたロールインスタンスの一覧を Foreach を使用して１つづつ取り出し、Get-DiagnosticConfiguration で各診断ログの設定情報を収集しています。ログの設定を行う場合には、ログのタイプごとにコマンドレットが用意されているのですが、情報を収集する場合にはこのコマンドレットに引数として –BufferName <ログのタイプ> を指定します。

Get-DiagnosticConfiguration からの戻り値は $Config という変数に格納していますが、PerformanceCounters や Directories のように複数の値（パフォーマンスカウンターやログが格納されているディレクトリ）を持つ者は DataSources プロパティを使用すると詳細な中身を確認することができます。DataSources プロパティは、設定を行う際にも使用するので覚えておいてください。

出力結果例を以下に示します。

************** WebRole1_IN_0 **************
--- DiagnosticInfrastructureLogs ---

ScheduledTransferLogLevelFilter : Verbose
ScheduledTransferPeriod : 00:10:00
BufferQuotaInMB : 1024

--- Directories ---

DataSources : {Microsoft.WindowsAzure.Diagnostics.DirectoryConfiguration, Microsoft.WindowsAzure.Diagnostics.DirectoryConfiguration, Microsoft.WindowsAzure.Diagnostics.DirectoryConfiguration}
ScheduledTransferPeriod : 00:10:00
BufferQuotaInMB : 1024

Path : C:\Resources\directory\d8316264497849f4891e25fc3943ca09.WebRole1.DiagnosticStore\FailedReqLogFiles\Web
Container : wad-iis-failed-logfiles
DirectoryQuotaInMB : 1024

Path : C:\Resources\directory\d8316264497849f4891e25fc3943ca09.WebRole1.DiagnosticStore\LogFiles\Web
Container : wad-iis-logfiles
DirectoryQuotaInMB : 1024

Path : C:\test
Container : tflogs
DirectoryQuotaInMB : 1024

--- Logs ---

ScheduledTransferLogLevelFilter : Undefined
ScheduledTransferPeriod : 00:10:00
BufferQuotaInMB : 1024

--- PerformanceCounters ---

DataSources : {Microsoft.WindowsAzure.Diagnostics.PerformanceCounterConfiguration, Microsoft.WindowsAzure.Diagnostics.PerformanceCounterConfiguration, Microsoft.WindowsAzure.Diagnostics.PerformanceCounterConfiguration}
ScheduledTransferPeriod : 00:10:00
BufferQuotaInMB : 1024

SampleRate : 00:01:00
CounterSpecifier : \Processor(_Total)\% Processor Time

SampleRate : 00:01:00
CounterSpecifier : \Memory\Available Mbytes

SampleRate : 00:01:00
CounterSpecifier : \ASP.NET Applications(__Total__)\Requests/Sec

--- WindowsEventLogs ---

DataSources                     : {System!*, Application!*, Security!*}
ScheduledTransferLogLevelFilter : Verbose
ScheduledTransferPeriod         : 00:10:00
BufferQuotaInMB                 : 1024

System!*
Application!*
Security!*

つづきは以下で
IT Pro (IT 担当者) のための Windows Azure Platform 運用管理ガイド 1.0 PowerShell による管理の自動化

【Azure for IT Pro】Guest VM の C: ドライブは絶対に消えないか？

Posted over 3 years ago

by

junichia

1 Comment

前回の投稿で、Guest VM のアップデートが与える影響について触れ、記事の中で、「C:」ドライブだけは Guest VM のアップグレード時にも維持されると書きました。

【Azure for IT Pro】自動更新がホストサービスに与える影響について

C:ドライブは診断ログや構成ファイルなどが保存されている、非常に重要なドライブです。

では、C: ドライブはどんな時でも維持され続けるのでしょうか？

残念ながら、答えは NO です。

その理由は、Guest VM がのっている Host OS やサーバー自身が死んでしまうことがあるからです。

その場合は、Fabric Controller が新たなサーバーを用意し、そこに今までと同じバージョンの Guest VM を展開し、さらにアリケーションも展開してくれます。よって、サービスは継続されます。

ただし、これまでローカルストレージに蓄積してきたデータはすべてなくなります。そうならないように、大切なデータは永続的なストレージ、すなわち、Winodws Azure ストレージまたは SQL Azure に保存しておかなければなりません。

Windows Azure ストレージおよび SQL Azure は、自動的に複製が3つ作成されているため、いずれかが破損してしまっても残りの2つに複製が残されています。ロードバランサーは3つの複製それぞれへの経路を自動的に設定してくれるので、利用者がストレージの生死を意識する必要はありません。もちろん、複製のうちのいずれかが破損してしまった場合にも、ロードバランサーは自動的に経路を設定しなおしてくれます。

IT Pro が Windows Azure をインフラの一部として設計する場合に肝に銘じなければならないのは、以下の 3 点です。

コンピューティングとストレージは別のサービスである

データの保存は極力永続的なストレージ（SQL Azure ストレージ、SQL Azure）へ

コンピューティングサービスのローカルストレージは一時保管場所である

診断ログを含め、保存したデータは速やかに永続ストレージに転送しましょう

設定変更はスタートアップタスクで

リモートデスクトップで変更した設定は水物です

以下の表は、各種シチュエーションにおけるローカルストレージの状態を一覧にしたものです。

【Azure for IT Pro】自動更新がホストサービスに与える影響について

Posted over 3 years ago

by

junichia

1 Comment

*** IT Pro のための Windows Azure 運用管理ガイド 1.0 公開 ***
IT Pro (IT 担当者) のための Windows Azure Platform 運用管理ガイド 1.0

*** 6/15 Windows Azure Platform 最新情報をお届けする無償セミナー***
Windows Azure Platform 最新情報 2011 年 6 月版 & そろそろリアルな運用についても考えてみよう

***7/9 女子限定クラウド勉強会***
Azure 女子部勉強会申込み

Windows Azure を使用したことがある方であればご存知の通り、Windows Azure には展開したホストサービスに自動的に修正プログラムを適用する機能が用意されています。

以下の画面は、Windows Azure の管理ポータルで、ホストサービスの「Configure OS」を開いたところです。OS Version が [Automaric] に設定されていることがわかります。

ただし、オンプレミスにおける Windows Update とは仕組みが全く異なる点に注意しなければなりません。

オンプレミスでは、修正プログラムは以下のように適用されます。当たり前ですよね。誰でも知ってます。

では、Windows Azure ではどのように修正プログラムが適用されるのか...。図にすると、以下のような感じです。

修正プログラムが適用される...というよりも、「修正プログラムが適用されたOSに置き換えられる」と言ったほうが正確でしょう。Windows Azure 管理ポータルで「Configure OS」の OS Version をプルダウンすると、以下のようにGuest OSに多くのバージョンが用意されていることがわかります。それぞれの違いは、修正パッチやインストールされているSDKのバージョンです。

上の図では、アプリケーション部分がそのまま「横滑り」するようなイメージで書かれていますが、実際にはこれまでの Guest VM が破棄され、新しい「OSイメージ」と「アプリケーションイメージ」が再展開されます。

以下をご覧ください。これは、Guest VM を構成している VHD です。Guest VM を構成する VHD は全部で3つあり、OS 本体はD:ドライブに、開発したアプリケーションは E: ドライブにマウントされています。C:ドライブには構成情報や診断ログ等が格納されています。

これら 3つの VHD にはいずれも差分VHDが設定されており、運用中に発生した変更は差分VHDに書き込まれます。

ここで、Guest VM の OS バージョンをアップグレード（またはダウングレード）したとしましょう。古いOSイメージ（VHD）は破棄され、新しい OSイメージがファブリックコントローラーから Guest VM の領域に複製されてきます。さらに、アプリケーションが格納されている E: ドライブも同時に破棄され、キャッシュされているアプリケーションイメージが再展開されます。つまり、D: ドライブと E: ドライブに書き込まれた情報は、この時点ですべて廃棄されます。ただし、C: ドライブは差分VHDも含め、そのまま維持されます。

こうした動作を抑えておくことは、IT Pro にとっても開発者にとっても、非常に重要です。

アプリケーションを展開した後、リモートデスクトップで入り込んで OS の設定を変更したとしても、OS がアップグレードされると変更点はきれいさっぱり無くなります。アプリケーションの Web.config ファイルも同様です。

こうした仕様に対処するため、「スタートアップタスク」と呼ばれる仕組みが用意されています。スタートアップタスクについては、IT Pro (IT 担当者) のための Windows Azure Platform 運用管理ガイド 1.0 をご覧ください（6月10日公開予定です！）。

【Azure for IT Pro】インスタンスごとの Fault Domain を PowerShell で確認するその2

Posted over 3 years ago

by

junichia

1 Comment

前回、前々回と以下の投稿をしました。

前回は Web Role だけ20個でしたが、今度はこんな構成にしてみました。

Web Role * 10
Worker Role * 7

前回の投稿と同様、リモートデスクトップにログオンして、PowerShell の Get-RoleInstance コマンドレットで分散状況を表示してみます。

PS D:\Users\junichia> Get-RoleInstance

Id                          Role                       UpdateDomain FaultDomain
--                          ----                       ------------ -----------
WebRole1_IN_0               WebRole1                   0            0
WebRole1_IN_1               WebRole1                   1            1
WebRole1_IN_2               WebRole1                   2            0
WebRole1_IN_3               WebRole1                   3            1
WebRole1_IN_4               WebRole1                   4            0
WebRole1_IN_5               WebRole1                   0            1
WebRole1_IN_6               WebRole1                   1            0
WebRole1_IN_7               WebRole1                   2            1
WebRole1_IN_8               WebRole1                   3            0
WebRole1_IN_9               WebRole1                   4            1
WorkerRole1_IN_0            WorkerRole1                0            0
WorkerRole1_IN_1            WorkerRole1                1            1
WorkerRole1_IN_2            WorkerRole1                2            0
WorkerRole1_IN_3            WorkerRole1                3            1
WorkerRole1_IN_4            WorkerRole1                4            0
WorkerRole1_IN_5            WorkerRole1                0            1
WorkerRole1_IN_6            WorkerRole1                1            0

ちょっとわかりずらいので、図にしてみると以下の通りです。

Webロールも、Worker ロールも、一方に偏ることなくきれいに分散していることがわかります。

仮に、Fault Domain #0 が死んだとしても、Fault Domain #1 でサービスを継続できることがわかります。

【IDM】WIF Extension for SAML 2.0 Protocol Preview版

【Azure for IT Pro】診断モニタにアクセスするための PowerShell スクリプト

【Azure for IT Pro】Guest VM の C: ドライブは絶対に消えないか？

【Azure for IT Pro】自動更新がホストサービスに与える影響について

【Azure for IT Pro】インスタンスごとの Fault Domain を PowerShell で確認する その2

【Azure for IT Pro】インスタンスごとの Fault Domain を PowerShell で確認するその2