2016年6月22日水曜日

Rebirth! 東北の資料を公開しました

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

2016年6月18日に仙台で開催されたMicrosoft MVPによる東北復興支援イベント、「Rebirth! 東北」で、オンライン・アイデンティティの自己コントロールと活用について話をしてきました。

今回は、全編ノン・テクニカル、かつ人事(タレントマネジメント)領域でのコンサルティングのプロフェッショナルであるMVP for Business Solutionの齋藤さんとのディスカッションを中心にセッションを進めたので、資料だけでは何もわからないとは思いますが、一応資料を公開しておきます。




テーマと議論の流れはこんな感じです。

  • イントロ:オンライン・アイデンティティの現状とその課題
    • そもそもアイデンティティって自分で認識できるもの、他人が認識することによって形成されるものなど色々な要素によって構成されている
    • 特にオンライン・アイデンティティはコンピュータの特性上、忘れられない、という特徴を持っており、しばしば炎上やプライバシ上の課題を産む
    • そんな中、オンライン・アイデンティティをビッグデータとして収集・活用するという動きも出てきている
    • 自己主権型アイデンティティ(Self-Sovereign Identity)という考え方が注目を集めている
  • ディスカッション:グローバル企業におけるチームビルディングに関する課題と対応
    • 強いチームを作る際、採用活動がキーとなる
    • グローバルで役に立つ人材を獲得するためには「見えない特性=アイデンティティ」を見抜く必要がある
    • 体系的にスキルセットやポテンシャルを洗い出し、活用していく方法が実用化されてきている


ディスカッション側は内容的に公開しずらいものばかりなので、とりあえず資料と上記の議論から類推してみてください。


2016年6月16日木曜日

[告知]今週末は仙台でアイデンティティ!

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

ぎりぎりの告知になりますが今週末(6/18)、マイクロソフト MVP の有志による東北復興支援イベントが開催されます。

公式サイト
 Rebirth!東北
 http://retohoku2016.azurewebsites.net/


場所が仙台国際センターなので、いきなりは行きにくいとは思いますが、何しろ登壇者がゴージャスなので、週末の予定をキャンセルしてでも顔を出す価値はあると思います。

例えば、午前中のキーノートはマイクロソフトの西脇さん、澤さん、榊原さん、、と公式イベントでもここまで人がそろうことって中々ないんじゃないかな~と思うような顔ぶれです。(当然午後もJavaの寺田さんをはじめそうそうたるメンバです)


そんな中、私はたまには概念論を話そうかな~と思っていて、「オンライン・アイデンティティの自己コントロールと活用」というタイトルで MVP の齋藤さんと一緒に話をします。



以下、概要です。
昨今のtwitterへの不適切画像のアップロードやGoogleサジェストによるオンライン・アイデンティティへの望まないラベル付けが容易に行われてしまう一方で、採用など人事領域へのビッグデータ、人工知能の適用などオンライン・アイデンティティの重要性はますます大きくなってきています。
本セッションでは企業活動においてオンライン・アイデンティティの活用が進む中、どのように自身でコントロールしていくべきなのか、また企業側はどのように活用していくべきなのか、について議論します。

先週ニューオリンズで開催された Cloud Identity Summit 2016 でも頻繁に語られた Self-Sovereign Identity(自己主権型アイデンティティ)とか Respect Network の話です。私もそこまで詳しく知っている分野でもなく、かつかなり概念的なのでいつものSAMLやOpenID Connectネタとは違った眠りをご提供できるのではないかと思っております。はい。


是非、仙台でお会いしましょう!

2016年6月6日月曜日

[MIM]June CTPで遂にExchange Onlineをサポート

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

前回の4月版のCTPに続き、6月度のプレビュー版が公開されました。

 公式アナウンス
  Now Available MIM 2016 June Preview
  https://blogs.technet.microsoft.com/iamsupport/2016/06/03/now-available-mim-2016-june-preview/

 ダウンロードはこちら(要登録)
  https://connect.microsoft.com/site433/Downloads


なんといっても今回の目玉は、MIM Serviceの承認用メールにExchange Onlineが使えるようになった、という点です。

このエンハンスリクエストはずいぶん前から上がっていたのですが、なかなか実装されなかったので、待っていた人も多く、早く正式版にも実装してもらいたい機能ですね。

他には、

  • セルフサービス・グループ管理やプロファイル管理ページのChromeやスマホブラウザの対応
  • Windows Server 2016 Technical Preview、SQL Server 2016、SharePoint 2016への対応
  • Windows Server 2016の新機能に対応した特権アクセス管理用のコマンドレットの追加

が更新ポイントとして挙げられています。

更新のペースが速いのでなかなかテストができませんが、触ってみないと。。。

2016年6月1日水曜日

[Azure AD Connect]汎用LDAPやSQLなどの管理エージェントが同梱

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

全然気が付いていなかったのですが、先日のAzure AD Connectの最新バージョン(1.1.180)から以下の管理エージェントが同梱されています。


  • Generic LDAP
  • Generic SQL
  • PowerShell
  • Web Service


これが何を意味するか、というとこれまではあくまでオンプレミスのActive DirectoryからAzure Active DirectoryへのID同期を行うためのツールであったAzure AD Connectが「LDAPやSQLなど他のデータ・ソースを含めID同期を行うことが出来るようになった」、ということです。

Azure AD Connectにディレクトリ同期ツールが統合された際に、カスタムシステムとの接続を将来サポートする、という宣言はありましたが、ようやく第一歩を踏み出した、ということです。

 参考)カスタムシステムとのID同期は「FR(将来的にサポート)」となっています。
 https://azure.microsoft.com/ja-jp/documentation/articles/active-directory-hybrid-identity-design-considerations-tools-comparison/


Synchronization Managerで管理エージェントを作成すると、Azure ADとAD以外への接続を行う管理エージェントが出てきます。


拙作のカスタムのエージェントを導入してみました。
 汎用REST API管理エージェント
 https://restmafim.codeplex.com/



現状まだオフィシャルの文書は出てきていませんが、今後はAzure AD Connectを中心としたハイブリッドID管理がますます拡大していくことになると思いますので、FIM/MIMの知識がようやく?必要な世の中が来たのかも知れませんね。(ハードル高!)



2016年5月30日月曜日

Office365のSAML脆弱性に見るマルチテナントSP実装時の注意点

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

しばらく前に世間を騒がせたOffice365のSAML SP実装に関する脆弱性の話が色々と解説されているので、ちょっと動きを細かく見ていきたいと思います。

 騒動の元ネタ
  The road to hell is paved with SAML Assertions
  http://www.economyofmechanism.com/office365-authbypass.html

 OAuth.jpでのnov氏による解説記事
  Office 365 SAML Implementation Vulnerability
  http://oauth.jp/blog/2016/05/14/office-365-saml-implementation-vulnerability/

 John Bradley氏による解説
  Azure AD security issue
  http://www.thread-safe.com/2016/05/azure-ad-security-issue.html

 Internet2での解説
  Scoped User Identifiers
  https://spaces.internet2.edu/display/InCFederation/2016/05/08/Scoped+User+Identifiers


まぁ、起きていた事象と根本的な原因はIdPが発行したクレームを無条件に信じてしまっていたことにより他のテナントのユーザになりすましてしまうことが出来たよ、ということなので、ちゃんとVerifyしようよ、という話になっています。


◆何が起きていたのか再現してみる

と、言ってもすでにOffice365の脆弱性は修正済みなので、起きていたであろうことをAD FSとGoogle Appsを使って再現してみました。

AttackerとVictimの2つのIdPをAzure ADが収容して、共通のアプリケーションを利用する、という構図をGoogle AppsとAD FSを使って再現したのが以下の図のようなシステム構成になります。


Azure AD相当のAD FSが各IdPから渡ってきたEmailアドレスをストレートにNameIDに変換してアプリケーション(Google Apps)へ渡してしまうので、VictimにもAttackerにも同じメールアドレスのユーザが存在するとAttackerもGoogle Appsへログインできてしまいます。
(もちろん実際のOffice365/Azure ADではもう少し複雑な動きのはずですが、解説のためものすごく簡略化しています)

◆実際の動作

まず、各IdPに同じメールアドレスを持ったユーザを作成します。これは簡単ですね。Active Directoryのユーザとコンピュータからユーザのメールアドレス属性を編集してあげるだけです。

この状態でGoogle AppsへアクセスするとAzure ADに相当するAD FS(今回はHUBと呼びます)へリダイレクトされ、IdPの選択をするホームレルムディスカバリ画面が表示されます。これは、Office365の場合、メールアドレスのドメインパートで自動的に振り分けるような仕組みになっていますよね。


まずは正常系です。
ここでvictimを選択するとvictim側のAD FSへ再度リダイレクトされ、victim側のユーザでの認証が行われます。


もちろんここでログインすると問題なくGoogle Appsへアクセスできます。


今度は先ほどのIdP選択画面でattackerを選択してみましょう。
同じくattackerのログイン画面が表示されるので、attackerのユーザでログインしてみます。


すると、意図しないユーザであるにも関わらずGoogle Appsへのログインができてしまいます。

右上のユーザ名を見るとvictimのユーザとしてログインできていることがわかります。

これが問題です。


◆構成を見てみる

では、この環境がどのように構成されているのか見ていきましょう。

まずはHUBとなるAD FSの構成です。

Relying Partyには当然Google Appsが構成されています。

HUBとなっているので、IdPから渡ってくるEmailアドレス属性をNameIDへマッピングして出力を行うクレーム・ルールが設定されています。


次に、HUBのIdP(Claim Provider)設定を見てみます。マルチテナントで構成されているので当然victimおよびattackerがIdPとして登録されています。

そして、各IdPのクレーム・ルールを見ると単純に各IdPから渡ってくるEmailアドレスをパススルーしています。ここが大きな問題です。


取り敢えず問題は置いておいて、次に行きます。

次は各IdP側のRP設定を見ていきます。
当然、victim側にもattacker側にもRPとしてHUBが登録されています。

こちらがvictim側です。

こちらがattacker側です。

この辺りは特に不思議なところはありません。
クレーム・ルールも共通で以下の通り、ADのEmailアドレスをそのまま発行しています。



構成はこれで終わりです。
次はSAML Tracerを使って動きを見てみます。

◆SAML Assertionの中身の確認

まず、正常パターンです。victimで認証されてSAML ResponseがHUBへ返ります。


属性ステートメントにメールアドレス属性が正しく入っていることがわかります。

同様にattackerも見てみます。


先のルールだとattackerからもメールアドレス属性をそのまま発行することになるので、HUBへのSAML Responseにはメールアドレスが入ります。これは正常な動きです。

では、attackerからのResponseを受けたHUBがGoogle Appsへ返すSAML Responseを見てみます。


いけませんね。NameIDにvictimのメールアドレスが入ってしまっています。

Google Appsから見るとこのResponseはあくまでHUBから返ってきており、AssertionのIssuer(HUB)および署名(HUBのAD FS Token Sign)の検証が出来てしまうので、正しいAssertionだと認識してしまい、ログインが完了してしまいます。

◆どうやってなりすましを防ぐか?

では、ここからが対策です。
要するにHUBが配下のIdPから飛んでくるクレームを無条件に上位のアプリケーションへ発行してしまっているのが問題なので、フィルタリングを入れておきたいと思います。

具体的には、victimから飛んでくるメールアドレスはvictimの、attackerから飛んでくるメールアドレスはattackerの固有のドメインパートを持っている、という暗黙の前提の通りになっているかどうか?を確認し、正しければスルーしますし、異なっていたらフィルタリングしてしまいます。


AD FSにおいて、この設定はClaim Providerのクレーム・ルール設定で行います。

以下がvictim側の設定です。


次にattacker側の設定です。


この状態における実際のAssertionはどうなっているでしょうか?

まずは正常系(victim)です。メールアドレスがvictimorg.xyzで終わっているのでスルーされてAssertionに値が入ります。


しかし、attacker側ではメールアドレスがattackerorg.xyzで終わることが期待されるところにvictimorg.xyzが入ってきているのでフィルタされ、Assertionに値が入りません。

こうなるとGoogle Appsへのログインは失敗し、なりすましはできなくなりました。


◆対策とまとめ

結局のところは、「外部のIdPとフェデレーションを行う際はIdPの信頼性の担保が出来ているかどうかを確認すべし!」という話なんですが、「じゃあ、どうやって?」というところで例えばメールアドレスを使うOffice365やGoogle Appsなんかの場合は、暗黙の前提となっているドメインパートに正しい値が入ってくるであろう、という部分を排除してきっちりとフィルタリングをするという対策が必要になりますし、他の属性を使う場合でも、その属性に入ってくる値は当該のIdPで正しさが保証されているものなのか?を中間IdPやRP側でも確認をすることは必須である、ということが出来ます。

オンプレミスのActive Directoryの信頼関係でも同じですが、技術的につながるからと言って無条件につなぐと当然セキュリティ・ホールが出来上がるので、文字通り「信頼」をするためには必要な対策をちゃんとしましょう、ということです。

また、これはSAMLでもws-federationでもOpenID Connectでも全く同じことですので、うちのサービスはSAMLじゃないから大丈夫、と言ってスルーしないでください。



参考までに、ですがAD FSでは外部IdPから発行されたクレームを無条件にパススルーしようとすると以下のワーニングが表示されます。


ワーニングにはちゃんと意味があるので、みなさん従いましょうね。

2016年5月18日水曜日

[Azure AD Connect]Synchronization Rules Editorが大幅改善

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

コンスタントにバージョンアップを続けるAzure AD Connectですが、これまで同期ルールがUserもGroupもDeviceも同列にずらずらと出てきてしまい、どのルールを編集すると何が起きるのか?の把握が非常に困難でした。

このUIについて、しばらく前から改善要求を挙げていたのですが、直近の1.1.180へのバージョンアップでSynchronization Rules Editorのユーザ・インターフェイスが大幅に改善、かなり使いやすくなりました。

◆以前の課題

先に書いた通り、ずらずらと同期ルールが並んでおり、どのルールを編集すると何が変わるのかがよくわかりませんでした。


◆Version 1.1.180での改善

対象のコネクタ、オブジェクトタイプ、属性等によってフィルタリングができるようになり、例えば「オンプレミスのADのユーザのメールアドレスを変更すると、どの同期ルールが適用されるのか?」といった影響範囲の把握が楽になりました。



例えば、オンプレミスのAD上のsAMAccountName属性が変更された場合に影響があるルールを特定したければ、
・Connector : オンプレミスのAD
・Connector Object Type : User
・Connector Attribute : sAMAccountName
という条件を設定すると以下のように関連するルールが出てきます。



特に実際の本番環境ではデフォルトのルールだけでは運用できないケースも多く、例えばAzure AD Connectのバージョンアップ時に新しいマッピングが追加されたりすることもあるので、カスタマイズの範囲や影響度合いをしっかり把握することは重要です。
今回のエンハンスはそのような環境においては非常に便利なので、上手に活用していきたいですね。

2016年5月16日月曜日

[Azure AD]SAMLアサーションへのカスタム属性マッピングがサポート

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

全国7000万人のSAMLフリークの方に朗報です!!

ついに、Azure Active Directory(Azure AD)が発行するSAML Assertionにカスタム属性をマッピングすることが出来るようになりました。

 公式Blogでのアナウンス
  #AzureAD now supports custom unique IDs in SAML tokens for gallery apps
  https://blogs.technet.microsoft.com/ad/2016/05/13/azuread-now-supports-custom-unique-ids-in-saml-tokens-for-gallery-apps/


これで何がうれしいか?というと、例えばSAML AssertionのこれまではnameIdentifierにuserPrincipalNameやmail属性など限定的な属性しかマッピングできなかったが故に例えば、Google AppsのカスタムドメインとAzure ADのカスタムドメイン名をきっちり合わせておかないとSSOできなかったり、特に複数のSaaSアプリケーションを契約していて各SaaSアプリのnameIdentifierが異なる形式だったときに不具合が起きたり、、ということが解消するんです!



 ちょっと視点は異なりますが、以前Google AppsへのSSO時のSAML Assertionのマッピングのワークアラウンドについて書きました。この辺りもカスタム属性マッピングで解消できるポイントの一つです。
  [Azure AD]Google AppsとのSSO設定でのポイント
  http://idmlab.eidentity.jp/2016/02/azure-adgoogle-appssso.html



早速見ていきましょう。

◆準備1)Azure AD Connectで拡張属性の同期ルールを設定する

まずは、Azure AD上のextensionAttributeに値をセットしてあげないといけません。今回はオンプレミスのActive Directory上の属性をAzure AD Connectを使って同期することにします。

変更が必要なのは、
 オンプレAD⇒Metaverse
 Metaverse⇒Azure AD
の同期ルールです。今回は、オンプレADの「説明」属性をAzure ADのextensionAttribute1へ同期することにしたので、まずはAzure AD ConnectのSync Rules Editorを開き、以下の通りルールを作成(編集)します。

方向ルール名Flow TypeTarget AttributeSource AttributeApply OnceMerge Type
InboundIn from AD - User CommonDirectextensionAttribute1descriptionチェックなしUpdate
OutboundOut to AAD - User IdentityDirectextensionAttribute1extensionAttribute1チェックなしUpdate


※本番環境では既存のルールを編集するのではなく、追加ルールを新規作成することをお勧めします。

こちらがオンプレADの説明属性をMetaverseのextensionAttribute1へ同期するInboundルールです。

次にこちらがMetaverseのextensionAttribute1をAzure ADのextensionAttribute1へ同期するOutboundルールです。


◆準備2)オンプレADに属性値をセットする

同期ルールの設定が出来たので、対象の属性(今回は「説明」)に最終的にSAML AssertionのnameIdentifierに入れたい値を設定します。
テストをGoogle Appsでやりたいので、このユーザのuserPrincipalNameとはドメイン名の異なるメールアドレスを説明属性に設定しました。
ついでにmail属性をnameIdentifierへマッピングするテストもしてみたいので、メール属性に説明属性とは異なる値を入れてみます。
これで、マッピングを変えればAzure ADに設定をしていないドメインのGoogle Appsへ、かつnameIdentifierへマッピングする属性をメールと説明で変えれば別のユーザとしてログインできるようになるはずです。


ちなみにこちらがuserPrincipalNameです。先のドメイン名とは異なることがわかります。Azure ADへのログインはこの名前で行います。

実際にこれで同期が完了するとAzure AD上のオブジェクトの状態は以下のようになります。
Azure AD ConnectのConnector Spaceで確認すると、userPrincipalName、mail、extensionAttribute1の値がそれぞれ異なっていることがわかります。


◆準備3)SAML Assertionへの属性マッピングを変更する

いよいよAzure AD上のアプリケーション向けのSAML Assertionに含める属性のマッピング変更を行います。今回はGoogle Appsを例に解説をします。

アプリケーションをひらき、属性メニューからSingle Sign Onを見ると初期状態は以下のようにnameIdentifierにはuserPrincipalName属性のマッピングがされています。

このままだと、Azure AD上のuserPrincipalNameがそのままGoogle Appsへ渡るので、Azure ADとGoogle Appsのドメイン名が異なると動きません。

と、いうことで、ここを先に設定したextensionAttribute1にマッピング変更を行いたいと思います。

nameIdentifier属性の編集ボタンをクリックし、マッピングする属性としてextensionAttribute1を選択します。以前はここで拡張属性を設定することが出来ませんでしたが、今回のアップデートで選択できるようになりました。
※尚、mail属性とのマッピングは以前から出来ていたのですが、少なくとも私の環境ではマッピング変更を行っても実際のAssertionの中身を見ても正しくマッピングがされていませんでした。今回のアップデートでこの部分も解消されていました。



これで準備は完了です。

◆テスト1)Azure ADとは異なるドメインのGoogle AppsへSSOする

通常通り、Google AppsへアクセスするとAzure ADへリダイレクトされるので、Azure AD上のuserPrincipalName(今回だとGoogle Appsとは異なるユーザ名)でログインします。
※当然事前にGoogle Apps側にSSO設定をしています。


すると、異なるドメインにも関わらずGoogle Appsへサインオンできました!
ログインユーザ名を見るとオンプレADの「説明」属性に設定したユーザ名になっていることがわかります。


◆テスト2)SAML Assertionの中身を見てみる

正常にサインオンできたので、SAML Tracerを使って実際にどんなAssertionが発行されているのかを確認してみます。
想定通り、extensionAttribute1に入れた値がNameIDにマッピングされており、Assertionに含まれていることがわかります。


◆テスト3)別の属性にマッピングを変更して別ユーザとしてサインオンしてみる

先ほどはextensionAttribute1に入れた値をnameIdentifierにマッピングしましたが、メール属性にも
別のメールアドレスを設定してあったのを思い出してください。
追加のテストとして、このメール属性をマッピングしてみます。うまくいけば、別のユーザとしてGoogle Appsへサインオンできるはずです。

やり方は簡単ですね。Azure ADのアプリケーションの設定で属性マッピングをmailに変更するだけです。


この状態で先ほどと同じAzure ADユーザでGoogle Appsへサインオンすると想定通り、別のユーザとして扱われました。


◆まとめ

今回は、同じGoogle Appsを使ってテストをしましたが、このアップデートで例えば以下のことが実現でき、Azure ADのSAML対応アプリ連携の可能性がぐっと広がりました。

  • Azure ADとは異なるドメインのSaaSアプリケーションへSSOができる
    • これまではuserPrincipalNameにAzure ADのドメイン名が含まれてしまったので、アプリケーション側のドメイン名とAzure ADのドメイン名を一致させる必要があった。
  • オンプレのアプリケーションなど、従業員番号などメールアドレス形式以外のnameIdentifier属性を要求するアプリケーションとのSSOがやりやすくなった
    • これまでもExtractMailPrefix()関数でuserPrincipalnameのドメイン名を除いた値を使うことはできたが、必ずしもアプリケーションが要求する値がuserPrincipalNameのローカルパートになっているとは限らず、アプリケーション側でのID変更などが必要だった。