TechSummitのおさらい①：Azure ADで非SSLアプリとのSSOを構成する

こんにちは、富士榮です。

ようやく秋口からのセミナーラッシュが落ち着いてきたので、先日のTechSummitでお話しした非公開ネタを解説していきたいと思います。

内容的にマイクロソフトの公式イベントでお話しするにはあまりにも非サポートだったり、別の会社の製品との組み合わせを紹介しすぎたり、と大人の事情満載だったので当日は撮影禁止＆資料・動画公開なしとさせていただいたネタです。

当日お話しした内容は公開可のモノも含めると以下の通りです。

1. 非SSLな開発環境とSSOを構成したい！
2. SaaSアプリとのSSO時のトラブルシュートあれこれ
3. Azure AD Premiumは買えないけど複雑なことをやりたい
4. SaaSアプリへのプロビジョニングがちょっとアレな話
5. マルチフォレストのオンプレADとの同期すときのあれこれ
6. マルチフォレスト構成時のパスワード同期元/先を制御したい！

と、言うことで順番に解説していきたいと思います。

今回は1番目の「非SSLな開発環境とSSOを構成したい！」です。

Azure ADがSSOを構成するアプリはSSLじゃないとダメ！？

すでにAzure ADをお使いの方はご存知だと思いますが、Azure ADを使ったアプリとのSSOを構成するには、アプリをSSL化しておくことが前提となります。

この時に困るのが、開発環境をどうするか？という話です。もちろん余裕のある方は開発環境を含めてSSL化しておくことも可能でしょうし、最近はLet's Encryptなど無償の証明書を発行してくれる機関もあるので、こちらを活用して行くことも可能なのでニーズは減ってきていると思いますが、やはり面倒ということもあり何とか手軽に非SSLな開発環境でもSSOを構成していきたいところです。

※もちろん非SSLな環境を推奨している訳ではありませんので誤解なきよう。。。

非SSLなアプリを構成しようとすると何が起きるか？

先ほど、標準のAzure ADだとアプリのSSL化が前提となっている、という話をしましたが、具体的に何が起きるのか？を先に説明しておきます。

といっても単純にSAMLアプリの場合はAssertion Consumer Service（ACS）、OpenID Connectアプリの場合はReply URIを設定する際にhttpsスキーム以外だと怒られて設定が出来ない、というだけです。

ここで、考えるべきなのは

• このエラーはUI上でのValidationの問題なのか？
• それともデータを保存する際のValidationの問題なのか？

ということです。

個人的な経験からすると、Azure ADの構成情報の実体データは割りと素な状態でストアされており、管理者はPowerShellやAPI（そしてオマケとして管理ポータル）で設定を行うという構造になっていますので、今回についてもACS/ReplyURIの元データを何とかして修正できれば目標を達成できるはず、と考えました。

Azure ADにおけるアプリ登録情報の実体

ということで、管理ポータルの存在は一旦忘れて登録されたアプリケーションの構造を生データで見ていきましょう。

まずは一番単純な方法としてPowerShellを使います。※ここは時間の関係でTechSummitでもお話ししなかった部分です。

Azure Active Directory Module for Windows PowerShellを使いますので、インストールしていない人は「Install-Module -Name AzureAD」あたりで先にモジュールをインストールしておいてください。

取り敢えず「Connect-AzureAD」でAzure Active Directoryへ接続しましょう。

次に登録済みアプリケーションの情報を確認するために「Get-AzureADApplication」を実行します。

登録されているアプリがずらりと出てきます。

この中から、構成をしたいアプリケーションを見つけて、ObjectIDを指定して再度「Get-AzureADApplication」を実行して構成情報を確認します。この時、パイプでflをつけると細かいパラメータが見えます。

こんな感じです。

「Get-AzureADApplication -ObjectId xxxxx | fl」

その中にReplyUrlsというパラメータが見えます。

SAMLだろうがws-federationだろうがOAuthだろうがOpenID ConnectだろうがReplyUrlsです。潔すぎです。

この値がSAMLの場合はACSのURL、ws-federationの場合はwreply、OAuth/OpenID Connectの場合はReplyURIですね。

PowerShellを使って値を変えてみる

アプリの構成を取得するときに使ったのが「Get-AzureADApplication」なら構成を変更するときに使うのは「Set-AzureADApplication」です。

ただ、このReplyUrlsは配列で値が入るので、セットしたい値は配列としてセットします。PowerShellの場合は「@("値1","値2")」という形式が必要です。

ということで、

「Set-AzureADApplication -ObjectId {アプリのGUID} -ReplyUrls @("http://{ACSのURL}")」

をしてあげます。

以上、終了です。

先ほどと同様にGet-AzureADApplicationで確認するとちゃんとhttpスキームでReplyUrlsが登録されていることがわかります。もちろんデフォルトのhttpsを残したままhttpのモノを追加してもOKです。単純に配列に値を追加すれば良いだけですので。

結果、非SSLなアプリケーションへもSSO出来るようになりました。

管理ポータルでも構成が出来る

どうしてもPowerShellに抵抗がある人は手を挙げてください。

はい、実は管理ポータルでも構成変更が出来ます。

（こちらがTechSummit当日にご紹介した内容です）

やり方は登録されているアプリのマニフェストを直接編集します。

変更する内容はPowerShellの場合と同じく、ReplyUrlsの値です。

スライドにも書いてありますが、ここを変えても元々のエンタープライズアプリケーションのSSOの設定の表示が変わるわけではありません。

取り敢えず今回は一つ目の話を解説しました。

2つ目以降についても順次紹介していきたいと思いますので、しばしお待ちください。