【IDM】AD FS 関連 TIPS 集

Posted over 4 years ago

by

junichia

TechNet の US サイトに Wiki サイトがあるのをご存知でしたか？まだ Beta ですし、日本語サイトでは未実装ですが…。

TechNet Wiki
http://social.technet.microsoft.com/wiki/

位置づけとしては「コミュニティコンテンツ」となります。つまり、社員だけでなく、MS テクノロジーに造詣の深い方であればコンテンツを投稿することができるようになっています。

現時点で、AD FS に関連した TIPS が多く掲載されていますので取り急ぎご紹介しておきます。全部英語ですが…すんません。

http://social.technet.microsoft.com/wiki/tags/AD+FS/default.aspx

【IDM】AD FS 2.0 カスタムルール（カスタム規則）の作り方 1/2

Posted over 4 years ago

by

junichia

9/11 は MVP 瀬尾さん主催の「技術ひろば」で AD FS 2.0 のお話をさせていただきました。本日の資料を以下にアップロードしましたので参考になさってください。ちなみに10月の勉強会はエバンジェリスト松崎による SharePoint 開発 らしいです。お好きな方にはたまらないかと。

さて、私のセッションの中で カスタムルール を使用したデモンストレーションを行いましたが、その作成手順を説明できなかったのでこちらにまとめておきます。カスタムルールについては以下も参考にしてください。

【IDM】AD FS 2.0 で属性ストアとしてSQL Server を使用する

■想定するシナリオ

Active Directory にログオンした回数 (LogonCount) によって利用者の利用状況を判断し、WEB アプリケーションに表示するメニューを変えたい。例えば、100 回以上ログオンしたことがあるユーザーは「操作に慣れたユーザー」であると判断して、使えるアプリケーションを増やしてあげるとか…。（適当なシナリオですんません）

■作業概要と若干の事前解説

AD FS 2.0 ではクレームを作成しやすくするため、以下に示すような「要求規則テンプレート」というものが用意されています。

このテンプレートで吸収できない規則（ルール）を使用したい場合には、「カスタムルール」を作成しなければなりません。

カスタムルールの書式は一見シンプルなのですが、実は意外と奥が深かったりします。書式に関する情報や事例が、現時点ではあまり多くなく、ちょいと苦労するかもしれません。

カスタムルールを作成するのにうってつけの参考書は、既存の要求規則テンプレートでしょう。例えば、「入力方向の要求をパススルーまたはフィルター処理」という要求規則テンプレートを使用して、

『役割』というクレームに『Manager』が入っている場合のみクレームをスルーする

という規則を作ってみると、以下のようになります。

ここで、画面の下部にある「規則言語の表示」をクリックしてください。画面の設定内容が「要求規則言語」で表示されます。

言語部分は、以下のように書かれています。

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", Value =~ "^(?i)Manager$"]
=> issue(claim = c);

要求規則言語は大きく2つの部分に分かれます。1つが条件部で、もう1つが発行部です。両者は「=>」で結ばれ、条件部が True の場合にのみ処理が発行部に渡されてクレームが発行されます。

今回の例では、以下のように条件部と発行部が記述されています。

条件部 c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", Value =~ "^(?i)Manager$"]
発行部 issue(claim = c);

条件部に何が書かれているか、勘の良い方ならばおわかりですよね。「Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"」が評価対象となるクレームタイプです。クレームタイプとは「クレームの識別名」だと思っていただければ結構です。AD FS 2.0 管理コンソールの [サービス] - [要求記述] でクレームタイプ（要求の種類）の一覧を確認することができます（必要に応じて追加することもできます）。ちなみに、以下の画面で「ログオン回数」や「名前」というのは、この「管理コンソール内での識別名」なので注意してください。クレームは企業間やクラウド間でやり取りをすることを想定しており、システムが混乱しないように「世界で一意」でなければなりません。そのために URI での表現が採用されています。

「Value =~ "^(?i)Manager$"」は「=~」からもわかるとおり、正規表現を使用しています。「Type として指定したクレームに格納されている値が、この正規表現に合致するならば…」という意味になります。ちなみに「"^(?i)Manager$」は、「大文字と小文字を問わず”Manager”という文字にピッタリ合致する」という意味になります。「MANAGER」「manager」「mAnaGer」などが合致しますが、「Senior Manager」や「Manager Role」は合致しません。

先ほど、「要求規則テンプレート」で表現できない場合にはカスタムルールを作成する..と書きましたが、もう1つ、カスタムルールを作成しないと吸収できない場合があります。それは、AD FS 2.0 の管理コンソールにあらかじめ用意されていない「属性」をクレームに放り込みたい場合です。

AD FS 2.0 では、Active Directory から取ってこられる属性が既定されています（以下の図を参照）。つまり、これ以外の属性についてはカスタムルールを定義して独自に取ってこなくてはなりません。もちろん、今回のシナリオで想定している LogonCount なんて属性は、マニアックすぎて既定では用意されていません。

また、Active Directory から取ってきた属性は、クレームに格納しないとはじまりません。しかし格納先の箱となるクレームが都合よく用意されているとは限りません。上のほうで「要求記述」の話をしましたが、要求記述としてリストされていないクレームタイプは、AD FS 2.0 で使用することができないので、自分で定義してあげる必要があります。

今回のように「ログオン回数」を格納するためのクレームなんてのは、当然用意されていないので、独自に定義する必要があります。ちなみに、既定では以下のクレームタイプが用意されています。この作業が「面倒でいや！」な場合には、あらかじめ用意されているクレームタイプに放り込んでしまっても動作上の支障はありません。が…アプリケーションがクレームを受け取るときに混乱するのでお勧めできません。だって、「ログオン回数」が「Name」に入っていたら気持ち悪いですよね。なので、必要に応じて混乱が生じないクレームタイプを定義するようにしましょう。

ということで、次回は上記のシナリオを実装するための手順について書きます。

つづき

【Azure for ITPRO】サービス証明書の準備

Posted over 4 years ago

by

junichia

昨日以下の投稿をしました。この記事では既に証明書が存在するものとして書いてしまいましたが、よくよく考えてみれば「証明書を取得するまで」が結構不明な点が多かったりしますよね。

【Azure for ITPRO】証明書の管理について

ということで、今回はサービス証明書の準備手順についてまとめておきます。サブスクリプション証明書については問題ないですよね。

Windows Azure 上にアプリケーションを展開した場合、その URL は以下の通りです。

http://hogehoge.cloudapp.net/～～

SSLを使用する場合、hogehoge.cloudapp.net で証明書を取得する必要がありますが、何を隠そう cloudapp.net は Microsoft 管理の CN であるため、認証局（たとえば Verisign 社）からは「Microsoft の CSR(Certificate Signing Request）をよこせ」と言われてしまいます。つまり、事実上 hogehoge.cloudapp.net では証明書を取得できない..ということになります。

じゃどうするか？2つの方法があります。

とりいそぎ自己署名証明書を作成して使用する
別名を使用する

いますぐテストしたい！場合には自己署名証明書が手軽ですね。自己署名証明書を作成するには MakeCert コマンドと Pvk2pfx コマンドを使用しますが、これについては別投稿でまとめます。

別名を使用する…とは、要は CNAME を使用するってことです。hogehoge.cloudapp.net では証明書を取得できないので、自社ドメインに即した名称（hogehoge.anno.com とか）を使用し、こいつで証明書を取得することになります。つまり、利用者がアクセスする場合には、

https://hogehoge.anno.com/

という url を使用することになるわけで、当然利用者にはこの url を案内しなければなりません。

証明書を取得するまでの手順を簡単にまとめると以下の通りです。証明書取得の経験のある方ならば、なんら難しいことではないですよね。

CNAME を決定し、外向けの DNS に登録します
CSR（Certificate Signing Request）を生成します
CSRとは、証明書の申請にあたり、認証局に提出するファイルです。なんと、この手順について Verisign 社のサイトにとてもわかりやすくまとめられていますので参考になさってください！
https://www.verisign.co.jp/ssl/help/csr/ciis7_new.html
（注意）上記ページでも解説されている通り、CSR の作成には、IIS の管理コンソールを使用しています。つまり CSR 作成にあたっては事前にIIS がインストールされたマシンを用意しておいていただく必要があります。CSR を発行した IIS サーバーには秘密キーが格納されており、これは後から PFX ファイルとともにエクスポートして Azure 上に登録することになります。くれぐれも CSR 作成後にサーバーを消してしまうことなど無いようにしてください。
認証局の指定する手順に従ってCSR を提出し、証明書が発行されるのを待つ
証明書（.CER）が発行されたら、CSRを作成したサーバーにインストールします
インストールした証明書から、PFX ファイルを作成します。このとき PFXファイルには秘密キーを含めてください
保存した PFX ファイルを Windows Azure Portal から登録します。手順は【Azure for ITPRO】証明書の管理についてで解説されている通りです

以上、簡単にまとめてみましたが、作業を行いながらまとめたわけではないので抜けがあるかもしれません…実運用に即して内容に不備がございましたらご指摘いただけるとうれしいです。

ちなみに、クラウドベンダーによっては、*.cloudapp.net のようなワイルドカード証明書を無償で提供しているところもあるようですね。ひとまずマイクロソフトは今後このようなサービスを提供する予定はないようです。

【Azure for ITPRO】証明書の管理について

Posted over 4 years ago

by

junichia

2010.9.2 証明書の準備について追記しました

Tech・Ed 2010 が終わり、ひとまず年度初めの一区切りといった感じです。

さて、今年度の私の大きなテーマは、Windows Azure Security & Management です。BLOG の投稿も、このあたりの情報が増えると思います。何かリクエストがあればぜひお送りください。

今回は Windows Azure における証明書の管理ついて解説しておきたいと思います。以下はMSDNの記事なのですが、実際にこのあたりの管理を行うのはインフラ屋さんですよねぇ（今後 TechNet にもクラウド情報をガンガン掲載していく予定です。MSDN になんか負けないぞ!っと）

Managing Service Certificates（英語です。すんません。）
http://msdn.microsoft.com/en-us/library/ff793095.aspx

上記の記事から、ITPROに必要な部分を抜き出して解説します。

Windows Azure で管理される証明書は2種類あります。「サブスクリプション証明書」と「サービス証明書」です。これらはいずれも俗にいう「サーバー証明書」ではありますが、使用する目的と管理方法が異なっています。

■サブスクリプション証明書

「サブスクリプション」とは、要は課金対象となる Windows Azure アカウントのことです。利用者はサブスクリプションにWindows Live ID を使用してログオンし、Windows Azure Portal 画面からホストサービスを追加したり、削除したり、ストレージアカウントを追加したり…各種操作を行うことができます。

では、そうした操作を独自のプログラムから行う場合にはどうしたらよいでしょう？ Windows Azure には、開発者用にサービス管理 API（SMAPI）という専用の REST APIが用意されています。開発者は、SMAPI を使用して独自の管理プロセスを作成することができますが、アプリケーションと SMAPI の通信には SSL が必須となります。このときに使用されるのがサブスクリプション証明書 です。

サブスクリプション証明書は X.509 V3（.CER）に対応し、最低 2048 bit キーを持っている必要があります。自己署名でもOkです。

サブスクリプション証明書を登録するには、以下の Windows Azure Portal 画面から行います。

■サービス証明書

サブスクリプション証明書が SMAPI に使用される一方で、サービス証明書はその名の通り、Windows Azure 上に展開したアプリケーションサービスへの HTTPS を使用したアクセスに使用されます。

サブスクリプション証明書の主体が SMAPI にアクセスするサーバー（例えば管理用アプリをホストした社内サーバー）であるのに対し、サービス証明書の主体は Winodws Azure 上のロールインスタンス（ひとまず Windows Azure 上の仮想マシンのことだと思ってください）です。なので、証明書を作成する場合には、利用者からのアクセスに使用する FQDN でなければなりません。つまり、Windows Azure に新しいホストサービスを展開する際に URL（xxxxxxxx.cloudapp.net）を指定しますが、これを使用して証明書を作成する必要があります。自己署名証明書でも大丈夫です。

(2010.9.3 追記）xxxxxxx.cloudapp.net では証明書の取得ができないですよね。失礼しました。以下をご覧ください。
【Azure for ITPRO】サービス証明書の準備

証明書の形式は 秘密キー付のPFXファイル で、各ホストサービスの管理画面から登録することができます。

証明書を登録すると主体（Subject）に加えて、Thumbprint が表示されます。システム管理者は、この Thumbprint と暗号化に使用したアルゴリズムを開発者に伝え、ロールインスタンスのサービス定義ファイルに設定してもらうことで、展開するホストサービスと証明書とが結びつきます。

面白いのは、アップロードした証明書がどういう経路を通ってロールインスタンスに展開されるかという点です。（あまり運用には関係ないのですが…）

Windows Azure には「ファブリックコントローラー」と呼ばれるソフトウェアが実装されています。ファブリックコントローラーについて説明すると長くなるのでやめておきますが、簡単に言ってしまうと、「重要でセキュリティ上危険を伴う処理はファブリックコントローラーを介して」行われます。証明書の登録もファブリックコントローラーを通ります。証明書が登録されると、これは一旦ファブリックコントローラー内の「安全な場所」に格納されます。これが「ルートOS」と呼ばれる管理用OSを経由してゲストOSに展開されます。

このように、証明書はホストサービスとは別に管理され、サービスとはThumbprint で関連付いているため、証明書の更新のたびにアプリケーションごとアップデートするといった必要はありません。

システム管理者は新しい証明書を追加したら、Thumbprint を Windows Azure Portal を使用して Service Configuration File に書き込むだけですので、再度開発者に依頼して作業する…といった必要はありません。