European Identity & Cloud Conference 2019でBYOID＋DIDの話をします

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

昨年に引き続き今年もミュンヘンで開催されるEuropean Identity & Cloud Conferenceでお話させていただくことになりました。

公式サイト
　https://www.kuppingercole.com/events/eic2019

アジェンダを見ていると、AIとDecentralized Identity（ブロックチェーン）が半々くらいですかね。

私は昨年に引き続きBYOID（Bring Your Own Identity）のテーマでケーススタディ＋昨年シンガポールで開催されたConsumer Identity World APACで少し頭出しをしたBYOID＋Decentralized Identityのテーマで、動くものを少しお見せしようと思っています。

こんな感じの仕組みです。

外部ユーザを招待してOffice365（Teamsとか）を使ってもらうシナリオの一種ではあるんですが、通常のAzure AD B2Bでゲストの招待だとドメインのホワイトリストやTOU（Term of Use/利用規約）への同意くらいしか相手を確認する方法が無いので、その部分でDecentralized IdentityのVerifiable Claimsを使って証明書を提出させて本人確認を行う、というシナリオです。

このことにより、外部ユーザは組織アカウントでもLINEやFacebookなどの個人アカウントでのサインアップ＋証明書を提出することによりTeamsやAzure ADに参加したPCへのログインなどが出来るようになります。この辺りをAzure AD B2CやAzure Functionsなどを使って自動化をしています。
外部IDを受け入れる側の組織ではID管理やパスワード管理をする必要が全くありませんので、組織の形態にもよると思いますが使える場面も出てくると考えています。

こんなことも出来るようになります。

ちなみにID Proofing周りはOSSテクノロジー社のLibJeIDとuPortを使って実装しています。

おいおいこの辺りの話しも解説したいと思います。
（月末に開催されるde:code 2019でも触れる予定です）

[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

[Windows 10/Azure AD]ハイブリッド環境におけるドメイン参加とシングルサインオン①

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

Azure Active Directory（Azure AD）に参加したWindows 10デバイスでのデバイス・サービス間のシングルサインオンの仕組み（Microsoft Passport）については、これまでもidconや本ブログなどでも解説をしてきました。

　[Windows10]デバイス＆サービス間のシングルサインオンの仕組み
　　http://idmlab.eidentity.jp/2015/05/windows10.html
　[FIDO/Windows10]idcon vol.20（別名fidcon）が開催されました
　　http://idmlab.eidentity.jp/2015/05/fidowindows10idcon-vol20fidcon.html


しかし、現実のエンタープライズ・シナリオでは一気にAzure ADへPCを参加させて、クラウドだけで生きていく、ということは考えにくく、まずは現存のオンプレミスのドメインとWindows 10をどうやって組み合わせて活用していくのか？が焦点になっていくものと思われます。

と、いうことで今回はオンプレミスのドメインにWindows 10のPCを参加させて、Azure ADと連携することで得られる利点について解説していきたいと思います。いわゆるハイブリッドID基盤をWindows 10を使うことで更に活用できますよ、というシナリオです。

ちなみに、やれることは単純にデバイスへのログインと社内アプリ、社外アプリへのシームレスなログイン（シングルサインオン）ですが、この環境を実現するためのシナリオとしては複数の方法があります。

１）AD FSを構築してAzure ADとID連携する方法
　現在も主流となっているオーソドックスな方法です。PCはあくまでオンプレのAD DSに参加、ログインをして利用しますので、社外で利用する場合は社内ネットワークへVPN接続するか、Web Application Proxy（WAP）を用意してForm認証する必要があり、AD FSがダウンすると全滅するという弱点がありました。

２）Azure AD WAPを使う方法
　上記１のパターンと似ていますが、PCはAzure ADに参加して社内アプリへのアクセス時だけAzure AD WAPを使うため、可用性の面では改善されたものの、社内にいても社内アプリケーションへのアクセスはあくまでAzure AD WAP経由となるため、ファイルサーバなどの非Webアプリケーションへの対応ができない、など機能面で現実的な選択ではありませんでした。

３）Windows Server 2016のAD FSを使い、Microsoft Passport for Workを利用する方法
　おそらく今後の本命になると思います。社外はAzure ADを使ったMicrosoft Passport、社内はMicrosoft Passport for Work、社内外のつなぎはAzure ADとAD FSの連携という形になるので、オンプレのAD DSに参加したPCでもAzure ADに参加したPCでもシームレスに社内外のアプリケーションを利用できます。非WebアプリケーションについてもMicrosoft Passport for Workではカバーする予定らしいので、そうなると無敵です。弱点は基盤構築が超面倒なところですかね。SCCMとかIntuneとかのMDMが必要になりそうです。

４）Azure AD Connectを使いMicrosoft Passportに使うデバイス情報をオンプレ・クラウド間で同期する方法
　今回紹介する方法です。PCはオンプレのADへ参加するので従来通り社内リソースは統合Windows認証で利用し、社外アプリケーションはAzure ADとMicrosoft Passportで利用する形をとります。認証する局面においてクラウド・オンプレの間で連携がないので、完全に環境を切り離すことが可能なので、可用性はあんまり気にしなくても良いのが利点です。ただ、この後解説しますが現状はちょっと環境を選びます。


では、さっそく解説します。

◆実現すること
おさらいですが、以下を実現します。
・ドメイン参加したWindows 10 PCがAzure ADと連携されているアプリケーションへSSO（PCログインとアプリログインのSSO）できるようにする
・社内ファイルサーバなどへのログインは従来通り統合Windows認証を利用
　※つまり、Windows Server 2016のAD FSを使ったMicrosoft Passport for Workシナリオではありません。
・社外アプリ（Azure AD連携アプリ）へのログインはMicrosoft Passportを利用

◆前提および制限事項
実現するためには以下の前提や制限があります。
・Azure ADとAD DSはAzure AD ConnectでID同期を行っている
・Azure ADとAD DSはフェデレーションしていない（AD FSを使っていない）
・Azure ADとAD DSの間はパスワードハッシュ同期を行っている
・PCはWindows 10（TH2以降）
・ドメインコントローラはWindows Server 2012R2以降
・オンプレドメイン名とAzure ADドメイン名は同一であること
　（Azure AD ConnectでメールなどUPN以外の属性でオブジェクト・マッチングをするとNG。代替UPNでも良いので同一UPNが必要）
・実際にデバイスがAzure ADに登録されるまでには結構時間がかかります。（ログイン、Azure AD Connectによる同期、ログインの順で処理が走るので、同期の前後でログインをする必要があります）


◆準備作業
まず、準備として以下の2点を行います。
１．クライアントPCが自動的にデバイス登録（Workplace Join）を行うためのタスクの有効化

　グループポリシーの設定を行います。
　Windows Server 2016のドメインだと、
　　コンピューターの構成
　　　⇒ポリシー
　　　　⇒管理用テンプレート
　　　　　⇒Windowsコンポーネント
　　　　　　⇒デバイスの登録
　から「ドメインに参加しているコンピューターをデバイスとして登録する」を有効にします。
　※2012 R2サーバだと、「社内参加（Workplace Join）」という名前の項目になっています。

　このポリシーを有効にすることで、クライアントPCにユーザがログインしたタイミングでデバイスを登録するためのタスクスケジューラ（dsregcmd.exe）が起動するようになります。
　（このあたりの細かい動きは次回解説します）


２．有効化されたタスクがAzure AD DRSのドメイン、テナントを解決するためのエントリ（SCP：Service Connection Point）をAD DS上に登録

　１の作業で有効化したタスクがデバイスを登録する先となるAzure ADのサービス名（ドメイン名およびテナントID）をAD DS上に登録する作業です。
　実際の作業としてはAzure AD Connectに含まれるPowerShellのコマンドレット「Initialize-ADSyncDomainJoinedComputerSync」を実行することになります。

　こんな感じです。

　これを行うと、CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=example,DC=comにazureADNameとazureADIdという二つの情報が登録されます。先のタスクスケジューラはこの値を見てデバイス情報を登録する先のAzure ADを判別します。
　※ちなみに、Azure ADのディレクトリ内に複数のドメインが存在する場合、意図しないドメイン名が登録されてしまうことがありますので、その場合は直接AD DS上の値を修正する必要がありそうです。（これが原因かどうかはわかりませんが、うまく動かないことがありました）

◆PCをドメインに参加させ、ドメインユーザでログイン、そして同期する
ここは特に何もいりません。通常の手順です。

ただ、グループポリシーが正常に適用されると「Automatic-Device-Join」というタスクが自動的に実行されているはずです。

結果、いくつかのことが発生します。

まずは、初回ログインの際、ドメインに登録されたコンピュータオブジェクトのuserCertificate属性に証明書がセットされます。（タスクの中で自己証明書を発行します）

このあとAzure AD Connectでデバイス情報の同期を行います。Azure AD Connectの同期ルールを見るとuserCertificateに値が入っていないとAzure ADへコンピューターオブジェクトを同期しないので、この段階で初めて同期対象となるためです。

同期されるとAzure AD上にデバイスが登録されます。登録状態はGraph Exploreで確認するしか方法がありません。

そして、再度ドメインユーザでログインします。
するとAzure AD上に登録されたデバイスとログイン時に実行されるタスクによる登録要求の突合が行われ、Microsoft Passportに必要なKey Registration Serviceエンドポイントでの認証に必要なクライアント証明書がダウンロードされます。
この後、Windows 10はキーペアを生成し、秘密鍵をTPMに、公開鍵をKey Registration Serviceへ登録し、Microsoft Passportのデバイス登録フェーズが完了します。

次回Azure ADへログインする際はTPM上の秘密鍵で署名したリクエストによりPrimary Refresh Token（PRT）が取得できるので、そのあとは必要なアクセストークンを取得してアプリケーションを利用、という流れでシングルサインオンが実現します。

この際、ユーザのアカウント設定のページにはAADTokenBrokerが発現、紐づけられたAzure AD上のアカウント情報が表示されます。

◆Azure ADと連携したアプリケーションへアクセスする
ここまで来れば、これまで紹介したものと同じです。
アクセスパネルにアクセスするとAzure ADでのログインを求められることなく、アクセスできます。

かなりややこしいフローになるため、次回は少し深いところの仕組みを解説し、なぜこのような動きをするのか？を解説したいと思います。

[告知]Azure AD Join / Microsoft Passportの中身を知りたい人は11/10 OpenID Summitへ

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

4年ぶりの開催となる、OpenID Summitが来月開催されます。

海外勢は米国OpenID FoundationやPing Identity、Microsoftから大御所が、もちろん日本国内からも総務省、経済産業省といったGovernment系をはじめ、アイデンティティ関係やPKI関係の各種重鎮が終結する超豪華イベントです。

公式サイト：参加登録はこちらから。
　https://openid.or.jp/summit/2015/index.html


私も末席ながらエンタープライズ領域でのフェデレーション活用やIDaaSの可能性についてAzure Active Directory（Azure AD）を例にお話しさせていただきますが、個人的に注目しているセッションは、Microsoft CorporationのAnthony NadalinによるFIDO 2.0のセッションです。

FIDO 2.0といえばWindows 10のAzure AD Joinで使われているMicrosoft Passportの核となるテクノロジです。

私も過去に何度かこのブログでポストしたり、idconなどでお話しさせていただいたことがあるテーマですが、実際にMicrosoftで技術の標準化を進めているAnthony NadalinからFIDO 2.0の話が聞けるのは非常に貴重な機会になると思います。

参考）
　[FIDO/Windows10]idcon vol.20（別名fidcon）が開催されました
　http://idmlab.eidentity.jp/2015/05/fidowindows10idcon-vol20fidcon.html

　[Windows10]デバイス＆サービス間のシングルサインオンの仕組み
　http://idmlab.eidentity.jp/2015/05/windows10.html

　[Windows10/AAD]クラウド・ドメイン参加を試す
　http://idmlab.eidentity.jp/2015/02/windows10aad.html


参加費用も無料ですし、ぜひご参加ください。

[告知]9月はイベント三昧。ID&IT Management ConferenceとJapan SharePoint Group

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

9月にある2つのイベントに登壇することになったので、告知です。

１．ID&IT Management Conference 2015

世界3大アイデンティティ・イベントの一つである「ID&IT Management Conference」が9月18日に開催されます。今年で5回目になるんですね。

私もなんだかんだでほぼ毎年関わらせていただいているんですが、今年もパネル・セッションにパネリストとして参加させていただきます。

私は「エンタープライズIDの正しい捉え方、活用方法」というセッションでNTTデータの山田さん、NIIの中村先生、エクスジェンの江川さんと一緒にパネルディスカッションをする予定です。社内管理部門、学認、パッケージ、SIerという複数の立場からエンタープライズにおけるアイデンティティのあり方みたいな話ができると思います。

以下、セッション概要（イベントページより引用）です。

エンタープライズIDの正しい捉え方、活用方法 (パネルセッション)

認証基盤システム整備のための予算を確保するのに苦労する組織は、大変多いのではないでしょうか。

これは認証基盤整備が、セキュリティ確保や内部統制を主目的とし、また既に稼働中の基盤システムに対する再構築である場合が多く、利益増を主目的とする企業にとっては優先課題にはなりづらいからではないでしょうか。

IDを適切に運用、管理することで実現される理想像を描けているにも関わらず、我々には乗り越えないといけない様々な現実的な(技術論ではない）問題が多くあります。大規模認証基盤システム構築事例を元に、パネリストがそれぞれの立場から、様々な壁を乗り越える策を議論します。

以下のURLから申し込みが可能なので、お早めに！
　http://nosurrender.jp/idit2015/index.html



２．Japan SharePoint Group

2つ目はこれまでもたまにお手伝いさせていただいておりますMVP山崎さんが主宰しているJapan SharePoint Groupで9月12日に開催されます。こちらも20回目の開催になるんですね。

同日にSystem Center User Group Japanが品川で開催され、そちらがActive Directory特集ということなので、スピーカー不足ということで招集がかかりましたｗ

SharePointグループということでどちらかというと情報系アプリケーションの開発者の方や社内管理者の方が多く参加されると思いますので、テクニカルというよりもハイブリッドな認証/ID管理基盤の基礎的な話、プロジェクトの進め方、Windows 10のAzure AD Joinなんかの話が出来ればいいかな、と考えています。

こちらも以下のURLから申し込みが可能です。
　http://jpsps.com/event/20150912/

時間的に国井さんのセッションとダダ被りですね。。。。

[Windows10]K-Byte Fingerprint Security ReaderでWindows Hello

先日のポストでIntel RealSense F200でWindows Hello（顔認証）を試して玉砕した話は書きましたが、今度は指紋認証デバイスを試してみます。

　前回のポスト：[Windows10]Intel RealSense F200でWindows Hello
　http://idmlab.eidentity.jp/2015/06/windows10intel-realsense-f200windows.html


今回使ったのは、K-ByteのFingerprint Security Readerです。
日本のAmazonでは売っていないので、USのAmazon.comで探すとたったの$12で購入することができます。（USからの送料を入れると$33ちょっとで購入できます。Express Shippingを使ったので5日くらいで届きました）

こちらから購入できます。
http://amzn.to/1S7fFYr

特にドライバをインストールする必要もなく、生体認証デバイスとして認識されます。

デバイスを正しく認識できれば、アカウント設定のサインインオプションのWindows Helloのところに指紋認証のセットアップメニューが出てきます。

さっそくセットアップをしてみます。

Windowsのご挨拶。。。。なかなか素敵な翻訳です。

「開始する」をクリックするとPINの入力を求められます。

次に指紋の登録を求められるので、数回スキャンをします。

何度かスキャンします。

うまく行くと登録が完了しますので、さっそくログアウトしてみます。

ログイン画面にサインインオプションとして指紋が追加されます。
※画面ショット取得の都合上、ここから英語OSの画面を掲載しています。
　（単純にログイン画面の画面ショットを撮るためにVM上に構成したのですが、手元のVMが英語版しかなかったので。。。設定は物理マシン上の日本語OSで画面ショットを取得しています）

ここで指紋をスワイプし、うまく認識されるとログインできます。

ちなみに、うまく認識できないと以下のようなエラーが出ます。

単純に指紋認証だとWindows8.1のころとそれほど変化がないので、個人的にはやはり早く顔認証を使ってみたいなぁ、、と思います。


追記）
　尚、現状だとMicrosoftアカウントもしくはローカルアカウントだとWindows Helloが使えますが、AAD JoinしたAzureAD上のアカウントでログインするとBioEnrollmentHost.exeがクラッシュしてWindows Helloのセットアップができません。
（バグなのか、環境が悪いのかはわかりませんが）