[Azure AD]Google AppsとのSSO設定でのポイント

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

これまでも本ブログや各種記事で何度も紹介してきたAzure Active Directory（Azure AD）とクラウド・アプリケーションとのシングルサインオンですが、その中でもGoogle Appsが非常に手軽かつ利用シーンも多いので、何度も設定例として取り上げてきました。

しかし、実はAzure ADとGoogle Appsのシングルサインオンを行う際、2点はまりポイントがあります。

簡単に解説します。

◆サインオン時にGoogle Apps側で「ログイン資格情報を確認できない」と言われる

これはダブルバイト圏ならでは悩みと言えますが、原因は「Azure AD上のユーザ名に日本語（ダブルバイト文字）が含まれている」ことです。
Azure ADはSAML AssertionのAttribute Statementに必ず氏名の情報を含めてしまうため、ダブルバイト文字がAssertionに含まれてしまい、Google Appsが解釈できずにエラーとなる、という具合です。

一見なぜエラーになっているのかよくわからないため、タチが悪いと言えます。
Azure ADでログオンした後、Google Appsへリダイレクトされた際、以下のエラーが表示されます。

SAML Assertionの中身をトレースするとダブルバイト文字が入っていることがわかります。（SAML Tracerで見ると文字化けしてます）

対策としては、Google AppsはNameIdentifierさえあればシングルサインオンできるので、不要なAttribute Statementを消してしまえばOK、と思いきやAzure ADのSAML Assertionの編集画面で不要な属性を消しても、以下の属性が必ずAssertionに含まれてしまいます。
・tenantid
・objectidentifier
・identityprovider
・givenname
・surname
・name
・displayname

仕方がないので、日本語が入る可能性がある、givenname、surname、name、displayname属性にダミーの文字列を固定で入れてしまいます。

尚、displaynameについては初期状態の属性一覧には出ていないにも関わらず、Assertionの中を見ると値が飛んでいるので、属性定義を追加してから他の属性と同じくダミーの値を入れます。
ちなみに属性名は「http://schemas.microsoft.com/identity/claims/displayname」です。

必要な属性について編集を行い、保存します。以下が編集後の属性マッピング設定です。

これで実際のAssertionを見ると、ダミーのシングルバイト文字列がAssertionに含まれるようになり、エラーが出ることは無くなりました。

◆ログアウトするとエラーになる

シングルサインオンは良いのですが、Google AppsからログアウトするとAzure ADのサインアウト画面でエラーが出る、というケースがあります。

こんな画面が出ます。正しいSAMLプロトコル・メッセージではないというエラーが出ています。

これは、Azure ADがSAML2.0のシングルログアウトに対応していないにも関わらず、Azure ADがGoogle AppsのログアウトURLにSAMLのエンドポイントを設定していたことが原因です。（ws-federationのサインアウト設定を行う必要があります）
ちなみに、現在はこの問題は解決されているので、新規にシングルサインオン設定を行うとちゃんとws-federationのエンドポイントが設定されます。

以前の設定（エラーが出る）：https://login.windows.net/｛テナントID｝/saml2
現在の設定（エラーは出ない）：https://login.windows.net/common/wsfederation?wa=wsignout1.0

現在は、以下のようにちゃんとサインアウトできます。

このようにアプリケーションとのシングルサインオン設定はたまに更新されるので、定期的に設定を見直しておいた方が良いかもしれません。

ちなみに余談ですが、同一テナント上に複数のドメインが設定されており、かつフェデレーション・ドメインが含まれるケースにおいてはシングルログアウトの際に、全IdPのセッションをクリアしに行きます。
そのため、サインアウト時にIdPが落ちていたりして疎通できないと、うまくセッションがクリアできませんので、注意が必要です。（そのドメイン上のユーザかどうかに関係なく必ずセッション・クリアに行ってしまいます）

こんな感じで、落ちているIdPへもアクセスしようとしてエラーが出ます。

このように、Azure ADを使うと、かなり簡単にクラウド・アプリケーションとのシングルサインオン設定を行うことが可能ですが、トラブル時に対応するためにはID連携プロトコルの中身について少し知っておくと非常に有用です。

[告知]Active Directory & Security Conference 2016

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

なんだか毎月イベントやってますね。先日のJapan Community Camp by MVPに続き、3月は「Active Directory & Security Conference 2016」（通称AD16周年）に登壇予定です。

日時：2016年3月18日（金）12:50～20:00
場所：日本マイクロソフト品川本社セミナルームA～D
イベント申込URL：
　http://events.msfthcp.com/?CR_CC=200764089&eventID=JA-EMS-IPVNT-FY16-03Mar-18-Active-Directory-Security-Coference%20&ls=Website&lsd=AzureWebsite
※結構埋まってきているみたいなので、お早めに。

私は、Deep DiveトラックでAzure Active DirectoryとアプリケーションのID連携について解説する予定です。Deep Diveということで、普段は抑え目にお話ししているフェデレーションの深いところを心置きなくしゃべれるようなので個人的に楽しみにしています。

こんなセッションにする予定です。

タイトル（仮）：Azure ADと外部アプリのID連携/SSO Deep Dive
内容（仮）：Azure ADの最大の特徴である、GoogleやSFDCなどの外部アプリケーションとのID連携/シングルサインオン機能について、具体的な連携方法やトラブルシューティング時に必須となるSAML/OpenID Connectなどのプロトコルの解説、実際の連携時の通信のトレース方法についてデモを交えて解説します。

もちろん、他にもとても楽しみなセッションがたくさん予定されていますし、一部（英語）というセッションがあるあたり、ゲストにも期待大です。

ぜひ、お申込みください。


あ、そういえばJapan Community Campの資料は以下にアップしていますので、よろしければどうぞ。

Azure ADとWindows 10によるドメイン環境の拡張 from Naohiro Fujie

[Windows 10]PIN対パスワード、そしてWindows Passport

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

昨年夏のリリース時から「パスワードは時代遅れです」というメッセージで世の中を混乱の渦に巻き込んできたWindows 10ですが、半年が経過した今でも「やっぱり意味がよくわからない」という声をしばしば耳にします。
※ちなみにTH2のビルドだと「PINのセットアップ」というメッセージになっています。

これまでも各所の記事やセミナなどでは簡単に話をしたことはあるのですが、ちょうど前回から書き始めているWindows 10のドメイン参加やサインインの仕組みの大前提になる話でもあり、良い機会でもあるので簡単にまとめておきたいと思います。
（ちなみに多分に私見が入っています）


◆何が議論されているのか？
まず、これまで起きている議論はどういうものなのか、簡単にまとめておきます。

Windows 10をセットアップすると「PINはパスワードを使用するよりも早くて安全です」というメッセージ表示されます。また、短いPINが長いパスワードより安全な理由として「PINはこのデバイスでしか動作しないからです」と説明されています。

これを見て、
「数字4桁のPINの方がなんでパスワードより安全なの？」
とか、
「Windows 10ではPINに数字以外が使えるようになったし桁数も増やせるから！！」
とか、
「Windows Helloで生体認証と組み合わせられるから安全なんだ！」
とか、
「PINは端末とセットだからパスワードより安全なんだ！」
など、色々な疑問や意見がやり取りされて来ました。


それぞれの疑問や意見を見ると、もっともらしいものもありますが、いまいち何の話をしているのかがよくわからない、というのが正直な感想です。


◆なぜモヤモヤするのか？
まず、これらの議論を考えるうえで圧倒的に欠けているのは、「安全かどうか？」という話の大前提は「相対論」である、という点だと思います。
つまり、疑問が発生するのは「何と何を」、「どうやって」比べて相対的に「安全」なのか？という前提が抜け落ちているからではないでしょうか？

例えば、桁数や複雑性を比較軸としてPINとパスワードを比べると、パスワードの方が安全、という結果になることが多いと思いますし、有効範囲（端末をまたいで使えるか）の広さを考えるとPINの方が安全（でも結局同じPINを使いまわすんじゃない？？？）みたいな話です。

このあたりがごっちゃになってしまっているので、ある一部分を切り取るとPINの方が安全に見えるし、違う見方をするとそうでもない、という話になり混乱を招いているといったところでしょう。


◆整理してみる
では、軸を整理してきちんと比較すればPINとパスワードのどちらが安全なのかが見えてくるんでしょうか？

まずリスクとなりうるポイントを洗ってみます。

＃	ケース	PIN	パスワード	コメント
①	のぞき見される	×	○	通常、複雑性はパスワードの方が有利
②	通信経路で盗まれる	○	×	PIN自体は通信経路を流れないのでPINの方が有利
③	フィッシングサイトに入力する	○	×	PINでサイトへログインすることは無いのでPINの方が有利
④	サービスのDBから漏えいする	○	×	PINでサイトへログインすることは無いのでPINの方が有利
⑤	リストを使ってサインインを試行	○	×	PINは端末とセットなので、漏れたPINで別端末へログインはできない
⑥	リスト攻撃される	○	×	PINでサイトへログインすることは無いのでPINの方が有利

いかがでしたか？
結論は出ましたか？


一見PINが安全に見えますが、やっぱりモヤモヤは止まりません。


◆ではマイクロソフトは何が言いたかったのか？
結論から言いますと、そもそも単純にPINとパスワードを比べてしまっている段階で間違えているんだと思います。
マイクロソフトが言いたかったのは、Windows 10で新たに採用された「Microsoft Passport」を使ったサインインは従来のIDとパスワードを使ったサインインに比べて安全である、ということを言いたかったんだと思います。

ただ、その安全性を正しく理解するには、ベースとなっているFIDOの考え方やデジタル署名やTPMなどの用語を説明し理解してもらう必要性がある中、メッセージを単純化しようとして「やりすぎた」んではないか？と私は思います。


Microsoft Passportを使ったサインインの本質は、端末内（TPM）に保存された秘密鍵を使ってデジタル署名をしたサインイン要求を、認証サーバ側にあらかじめ登録したペアとなる公開鍵を使って検証することをもって正当性を判断することにあります。

この仕組みにおいてPINなどユーザを認証するための情報（クレデンシャル）はリクエストに署名するための秘密鍵へアクセスするために端末内でだけ使われるため、ネットワーク上を流れず、従来のサインインに比べて安全である、ということです。

参考）Windows 10におけるサインイン時のフロー（Azure AD参加/Microsoft Passport利用）

これが認証サーバはデバイスを、デバイスは利用者を信頼・認証する、つまり「利用者の認証と端末の認証を分離する」というFIDO（https://fidoalliance.org/）そしてMicrosoft Passportの基本的な考え方です。

この考え方では利用者の認証手段を問いませんので、もちろん従来通りパスワードを使って問題はありませんが、
・端末内だけで使うため利便性を上げるにはシンプルな方法が望ましい
・パスワードは使いまわしや漏えいしていることが前提なのでもはや単体で使っても安全ではない
などの理由でPINがデフォルト、さらに利便性と安全性を高めるためにWindows Helloを使った生体認証を使うことが出来るように設計されているのだと考えられます。


つまり、最終的にマイクロソフトが言いたかったことは、
「安心してください、流れてませんから」
「Microsoft Passportという新しい仕組みを使うことでクレデンシャルの盗難が起きないようにしたから、パスワードのように運用上面倒なものを使わなくても安全ですよ」ということです。

少しはすっきりしましたかね。。。やっぱり難しいですね。

参考）昨年のidconで使った資料：FIDO in Windows 10
http://www.slideshare.net/naohiro.fujie/fido-in-windows10