Identiverse 2019参加メモ（Day3）

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

いよいよ3日目です。そろそろ疲れてきました。
これまでの日記はこちらから。

• 初日
• 2日目

ということで今日もはじめて行きます。
まずはキーノートから。

◆キーノート

• Digital Identity for the People by Richard Bird
• Chief Customer Information Officerの人
• 人々が自分のアイデンティティをデジタル社会に持つ時代になってきた
• シートベルトなどと同じく、Consumer保護の考え方はデジタル社会が始まった当時は存在せず、後からポリシーがついてきた
• GDPR、CCPAは果たしてConsumerの保護になっているのか？
• 現実問題、施行後にも4億以上のアカウント漏洩が発生している
• では何が足りないのか？
• データ保護≠アイデンティティ保護
• 結局のところ、アイデンティティの保護は人を守ること
• いくらそのリンクをクリックしてはいけないと言ってもクリックする
• 現実の数字として、
• US国民の20%が家に鍵をかけない
• 63%の強盗は押しいらなくても犯行ができてしまっている
• デジタル社会で自分を守るということは？
• データ保護とアイデンティティ保護は同一ではないことを認識する
• MFAなどでアイデンティティを守ることが必要

• Digital Identity - A Strategic Imperative by Grant Schneider
• US FederalのCISOの人
• 資料なしのプレゼンだったのであんまり拾えてないです
• アイデンティティ管理はセキュリティのために非常に重要なものであると考えている
• US連邦のサイバーセキュリティ戦略目標はデジタル社会におけるナショナルセキュリティと経済的なセキュリティを高めること、つまり「いかにして国家と国民の資産を保護するか」が命題
• そのために、色々と守らなきゃダメ
• Federal Cyber Security（税金や年金など）
• 重大インフラのセキュリティ（金融システムや交通システムなど）
• CEOやCIOがリスクマネージメントをできるように教育することも大事
• もちろんプライバシーも大事なので、ペルソナの使い分けなども意識しないとだめ
• アイデンティティ保証も大事だよ

• The next wave of Identity Standard by Alex Simons
• アイデンティティに関する標準の3つの波
• オンプレミス
• クラウドとモバイル
• 分権とプライバシー by デザイン
• オンプレミスにおける相互運用性と利便性の向上
• 全てがFirewallの内側にある前提
• ESSO、LDAPの組み合わせによるPasswordインジェクション
• KerberosによるトークンベースのSSO
• このころの攻撃はSlammerなどサーバの脆弱性を狙ったものが多かった
• クラウドとモバイルの世界のためのアイデンティティ
• SAML：広く使われるようになった最初の標準技術
• OAuth1.0：実装が難しかったよね
• OAuth2.0、OpenID Connect：現在のマイクロソフトのソフトウェアはPowerPointからAzureまでこの標準に従っている
• 2019年6月のデータではAzure ADに接続されているアプリケーションの95％がOAuthもしくはOpenID Connectを使っている
• このころになると攻撃手段が変わってきて、パスワード盗難がメインとなってきた
• 81%のデータ漏洩の原因がパスワード盗難に起因している
• こうなると多要素認証が必要となる
• FIDO2。すでにWindows10やAndroidは準拠している
• 次はパスワードレスの時代へ向かっている
• Azure ADのパスワードレスのデモ（YubikeyでOffice365ポータルへログオンしてます）
• 2019年7月にようやくAzure AD＋FIDOのパブリックプレビューがリリースされる
• 現状8億のユーザがパスワードレスを有効化している
• 月間8500万ユーザがパスワードレスでログインしている
• Token Binding
• TLSだけじゃない
• dPOPも
• SCIM
• 2019年6月のデータでは675万ユーザがSCIMでプロビジョニングされた
• Mark Wahlが新しいSCIMのプロファイルを提案している
• 分権とプライバシー by デザイン
• 全ての人が自分のアイデンティティを自分でコントロールできる世界へ
• DIDのデモ（昨日と同じもの） by Ankur Patel
• まだまだこれから
• とりあえず、今すぐやるべきこと
• OpenID Connect、OAuthを使いましょう
• モダンプロトコルに対応しましょう
• パスワードレスの時代です
• とにかく多要素認証を有効化しましょう。99%のID盗難は防げるよ

• Standards: The Bedrock of Identity
• パネルディスカッション
• モデレーター：Pamela Dingle
• パネリスト：Kim Cameron, Vittorio Bertocci, Brian Campbell, Annabel Backman
• パネルはきつい。。。あんまり拾えてないです
• それぞれがフォーカスしている／してきた標準仕様について紹介
• そういえばVittorioはws-*の人だったなぁ
• 標準化関連のミーティングはグローバルのあちこちで開催されるのは、みんなに参加してもらいたいから
• しかしSAMLはなんで800ページにも及ぶ巨大なモノリスになってしまったのか
• 何にでも対応できるように色々と組み込んでしまった
• 結果、拡張が難しい巨大な仕様になってしまった
• その反省を踏まえ、OAuth、OpenID Connectではシンプルなことをシンプルに実装できるように、という原則に則って設計をした
• SecEventの話し。
• SSOの世界ではリスクが顕在化した時にドミノ現象で伝搬してしまうので、リスクイベントの標準的な伝達方法が必要となった
• プロトコル設計をする時はシンプルにすることが大事
• DIDとOIDC、FIDOを組み合わせることで使いやすい姿を模索するなど
• これからこの世界をドライブしていこうとしている人たちへメッセージは？
• 標準化の世界へぜひ参加して
• コミュニティへ参加すること。メーリングリストがあるので、そこでユースケースや考えたことを共有するところから。Don't be shy!
• 言語の壁もあるかも知れないけど気にするな

◆ブレークアウトセッション

• The Identity Architecture Panel
• パネルディスカッション
• モデレーター：Barber Amin
• パネリスト：Kristina Williams, Greg Smith, Stephanie Kesler, Kim Cameron
• やっぱりパネルはきつい・・・
• ゼロ・トラストの世界。ブロックからモニター、緩和へ
• 企業は従業員にとってのIdentity Providerが、管理者はSAMLを知っているわけではないし、我々（IDaaS事業者）はインフラの形を変え管理者が何もしなくても良い世界を作ろうとしている
• プライバシーはコンシューマだけでなく従業員にとっても非常に重要
• CIAMのアプローチでは管理者はアイデンティティを管理することができない
• エンタープライズIAMの世界では管理者が従業員のアイデンティティを管理する
• コンテキストに合わせた柔軟なユーザージャーニーが必要である
• マイクロソフトは固定的なログインを柔軟にするためにIdentity Experience Framework（IEF）を提供している
• IEFを使えば、コンテキストに合わせた柔軟なユーザージャーニーを提供することが可能である
• 例えば、HRシステムの重要なデータへアクセスする際は追加の認証を要求する、なども考えなければならない
• どのようにして開発者にプライバシーを保護を意識させるのか？
• 教育なども重要
• データの分類と評価がまずは大事
• 昨年、テレコム企業の課金システムのリプレイスを行なった
• アーキテクチャの全面書き換えを行った
• 保護されたAPIやデータへのアクセスをトークンを使って制御することにした
• CCPAがあるけど、何かアドバイスは？
• まずはデータを特定して分類するところから始めましょう
• DIDについて
• iPhone上のデータは誰の持ち物？Appleもデータのコントロールできちゃうよね
• 個人データは借財。これは長くは続かない。DIDとかブロックチェーンが解決の糸口になるかもしれない
• 5年から10年くらいはかかるかな
• 今後我々はどんなテクノロジーをキャッチアップしていけばいい？
• AI（プライバシーも考慮して）
• FIDO2
• コンテキストに合わせたユーザージャーニー（IEF）
• マシンラーニング
• Decentralized Identity

• Blurring the boundaries between CIAM and IAM / Microsoft
• アイデンティティはセキュリティの要である
• 社内外とのコラボレーションのあり方の変化
• B2Bシナリオ
• パートナー側でアイデンティティを管理する
• つまりBYOID
• B2Cシナリオ
• セルフサインアップ
• 同じくBYOID
• こうやってみるとB2BもB2Cも同じ
• アカウントを作って
• 承認して
• アクセスできるようになる
• 共通しているのは人を中心に据えていること
• サンプルケース１
• 個人が複数のロールを担うことがある（不動産のオーナーだったり、売主だったり、従業員だったり）
• 一つのGoogleアカウントでサインアップ〜サインインする（Azure AD B2B）
• システム側でロールを切り替えられるような実装をすることで、役割ごとにユーザアカウントを個別に作る必要がなくなる
• サンプルケース２
• 大学のケース
• 入学希望して、受験生となって、学生になって、卒業生になって、大学院に入ってまた学生になって、学校に就職して職員となって。。というライフサイクル単位でアカウントを作るのではなく、一つのアカウントの状態を変えていく
• 共通するのは、一つのアカウントを関係性に応じて変化させていく、という考え方

• Identity Proofing - What Happens Before Authentication by Capital One
• Identity Proofingとは
• 個人に関する情報を集めて検証するプロセス
• アカウントをオープンする時に実行したりする
• 認証とは異なる
• なぜIdentity Proofingが重要なのか
• 認証して認可してシステムやデータへアクセスさせるが、そもそも「誰？」という部分を知らなければならないため
• NIST SP800-63Aにおける定義
• Resolution
• Validation
• Verification
• Identity Assurance Levelとは
• 検証に使うエビデンスと方法の品質
• 企業におけるシナリオ
• 雇用時
• バックグラウンドチェック
• 対面での書類確認
• 初期クレデンシャルの発行
• クレデンシャルのリカバリ時
• パスワードレスのシナリオの場合
• 免許証などのドキュメントをビデオ会議で見せて確認する
• コンシューマの世界におけるIdentity Proofing
• スピードと正確性とコストが大切
• 時間がかかると顧客はドロップしてしまう
• 色々な方法
• モバイルデバイスを使った確認
• SMSへのコード送信
• ドキュメントを使った確認
• 券面のスキャン、バーコードのスキャン
• 券面のスキャンはPhotoShop対策も合わせて必要
• リスクベースアプローチが必要
• Identity ProofingはRiskスコアと同義でもある
• まとめ
• 一般的にユーザが提供したり手動で入力した個人データは不正確である
• システム横断で使えるRiskスコアが必要
• データソースを増やして、検証の精度を高めるためには外部ベンダーとの協業が必要である（Capital Oneとか）

• Frictionless Identity Verification by ADP
• ADP自体はセキュリティの会社ではなく、HCMの会社
• 40Mくらいのアクティブユーザー数がある
• 次のチャレンジはユーザエクスペリエンスの改善
• 現状、ADPのサービスに従業員がセルフ登録する方法は以下の通り
• Federated SSO
• Personal Code
• Company Code
• Codeless Registration（モバイル向け）
• これまでIdentity Assuranceを担保するためにやってきたこと
• Bot Protection（ロボットよけ）
• AIベースのアイデンティティ確認
• 知識ベースの認証
• デバイスベースのリスク管理
• 外部ベンダとの協業（Capital One）
• 登録時のユーザージャーニーを整理し、70％のコンバージョンを実現した

• So You Think You Can Two Factor by Nishant
• 多要素認証を使う時
• PSD2など法令により必須な時
• 認証要素は非常に多岐にわたっている
• これらを単純に提供するのは説明書なしで家具を組み立てさせるようなもの
• どのように利用させる要素を考えるか
• ユーザが使いやすいもの
• コスト
• 対応する脅威モデル
• 効果
• 法令遵守
• 生体認証はセキュリティではなく、利便性のためにある
• 生体情報（いわゆる身体的な特徴情報）はすでに必須ではない
• ユーザの行動、デバイスID（Fingerpirnt）を使ったアノマリ検知も可能（機械学習ベース）
• ユーザへの浸透（使い慣れているものを使う）
• Googleは7年前から２要素認証を提供しているが利用している人は10％程度だった
• Yubikeyに対応したら登録者が増えた、なぜならYubikeyを使っている人が増えたから
• ユーザはリスクを理解しているわけではない
• Googleは２要素認証を強制はしていない。なぜならサービスを使わせたいから
• オムニチャネルの検討
• UX向上の別の例
• コンタクトセンターでの認証をスマホで行う、などチャネルを分離することによるUX向上とセキュリティ向上の両方を実現
• プロセス自体の検討
• 付与
• 第１要素を付与する時に同時に２要素目の登録を行う
• 間が空くと弱いタイミングができてしまう
• バックアップを取得する
• 緊急避難のパスを作っておく
• リカバリプロセスを作っておく（例えばSMSや免許証での検証など）
• 第２要素の破棄の方法を考えておく
• まとめると以下が大事
• ちゃんと使えること
• 複数の方法を用意しておくこと
• ユーザが受け入れられること
• オムニチャネルの検討
• 管理プロセスの検討

• Why Governments are still important even in a Self-Sovereign Context by Adam Cooper
• 近い将来、デジタルアイデンティティが人々のプライマリのIDになったと仮定するとどうなるだろうか
• 政府機関の役割
• 法律を整備する
• アイデンティティドキュメントを交付する
• 住民登録データを記録・保管する
• SSIやDIDのような新しい仕組みはそれらの役割を代替するものではなく、相互運用するものである
• 実際にアイデンティティを使う際にはアイデンティティそのものよりも適格であるかどうかの方がはるかに大切である
• 例えば、支払い能力はあるか、など
• そうなると、政府機関の提供するアイデンティティはトラストの源泉としての役割を持つ
• 個人は自身のアイデンティティを提示する際に、信頼できて検証可能であることを望む
• つまり、ポータブルで信頼に裏打ちされた状態において、自身でアイデンティティの管理を行える状態が望ましい
• 結局トラストフレームワークが鍵となる

• Developing World Identity
• パネルディスカッション
• モデレーター：Jeremy Grant
• パネリスト：Adam Cooper, Vyjayanti Desal, Kaliya Young
• ID4Dの取り組みの紹介（World Bank）
• LIC（Low Income Countries）にフォーカスしている
• ペルー、インド、パキスタン、タイなどで活動
• デジタルIDは全ての基盤となる
• Financial Inclusion
• Healthcare
• Women's Empowerment
• Social Protection
• Education
• 他にもペーパーレス・トランザクション（Paymentなど）を行う上でも必要なものである
• ID4Dの3つのアプローチ
• Thought Leadership & Analytics
• Country & Regional Action
• Global Platform & Convening
• 啓発活動を含め各種ドキュメントの発行なども行なったり、原則をプラクティスへ落とし込む活動をしている
• グローバルで一つの大きなIDシステムを作ろうとしているわけではなく、各国がオープンなIDシステムをもち、相互運用性を持てるような世界を目指していく
• Aadhaarの話（Kaliya）
• 2000年代初頭、IDシステムをどうやって変えていくか考えた
• 国民を登録する台帳は存在、ローカルガバメントが誕生・死亡の登録を管理していた
• Nandan Nilekani氏が閣僚となり、インドのユニークIDのオーソリティを作ることとなった
• 最低限実行可能なID基盤として以下をもつ
• 名前、生年月日、性別、住所
• 生体情報（写真、2つの虹彩情報、10の指紋情報）
• （ボーナス。必要か？）電話番号、メールアドレス、銀行口座情報
• 登録時はセントラルレポジトリへデータが送られ、ユニーク性のチェック後、IDが発行され、カードが送付される（なんのセキュリティ機能もないカード）
• Aadhaarを使った認証の方式
• Aadhaar番号と名前、住所
• Aadhaar番号と生体情報
• Aadhaar番号とワンタイムパスワード
• Aadhaar番号と多要素認証
• （KYC時は）Aadhaar番号と生体情報＋eKYCドキュメントの名前と住所
• 問題点
• 住民のゴールデンレコードができてしまう
• セキュリティ保護されていないカードが存在する
• 地方の支局に行くと生体情報の確認ができないことがある
• ワンタイムパスワードを使おうとしても携帯電話番号を持っていない人がいる
• 良い点
• みんなが持っている
• ユニバーサルである

と、本編はここまでです。

この後、イベントのFounderであるPing IdentityのCEO、Andre主催のパーティに参加してきました。Newseumという報道関係の博物館を貸し切っての大イベントでした。

ちなみにベルリンの壁とかがありました。

しかし何と言っても目玉はID厨だけで構成されているバンド、ZZAuthです。

メンバが以上に豪華です。Eve Malar, Justin Ritcher, Alex Weinert, Pamela Dingle, Sofia-Cristineなどなど・・・

ということでいよいよ次回は最終日です。

サービス終了間際のAzure ACS無しでSharePoint ServerへAzure ADでログインする

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

前回も書きましたが今年の11月でAzure Access Control Service（ACS）のサービス提供が終了します。

Azure ACSを自前サービス用に使っているようなB2B/B2C向けサービスを提供している企業の方はある程度切り替えは終わっているとは思いますが、意外と見落としがちなのがオンプレミスでSharePointを構築して使っている企業の方々です。

現状、SharePointサーバは最新バージョンであるSharePoint Server 2016でさえClaimベース認証を構成しようとするとプロトコルとしてws-federation、トークンはSAML1.1しかサポートしていません。

この制限により、SAML2.0トークンしかサポートしていないAzure ADとSharePoint Serverの間で直接のフェデレーションを構成することが出来ませんでした。

このことを解決するために、これまではAD FSやAzure ACSなど割と柔軟にws-federationの構成が出来る製品やサービスを間に噛ませてシングルサインオンを実現していました

こんな構成です。

が、いよいよAzure ACSのサービス提供が終了、ということでそろそろ対策を行わないと手遅れになってしまいます。
となると、引き続きAD FSを使う、というのも一つの手段ではありますが、今更オンプレミスにサーバを配置して管理するのも面倒なので、出来ることならSharePointとAzure ADを直接接続しておきたいところです。

と、言うことで今回はAzure ADにSAML1.1のトークンを発行させることでSharePoint Serverと直接接続するための方法を解説します。
尚、この手法は特に裏技というわけではなく、オフィシャルに（ひっそりと）公開されている手順です。

Using Azure AD for SharePoint Server Authentication
https://docs.microsoft.com/en-us/Office365/Enterprise/using-azure-ad-for-sharepoint-server-authentication

簡単に言うと、Azure ADのトークン発行ポリシーをカスタマイズしてSAML1.1のトークンを発行させることによって、SharePoint Serverが解釈できるようにしてやろう、という作戦です。

以下の順に構成を行います。

• Azure ADのエンタープライズ・アプリケーションにSharePoint Server接続用のアプリケーションを登録する
• SharePointのEntityID、Reply URLを登録する
• トークン署名用の証明書を生成し、公開鍵をダウンロードする
• ユーザの割り当てを行う
• 作成したAzure AD上のアプリケーション（ServicePrincipal）にリンクされたトークン発行ポリシーを変更する
• SAML1.1トークンを発行するカスタム・ポリシーを作成する
• 元々ServicePrincipalにリンクされているSAML2.0トークン発行のポリシーとのリンクを解除する
• 新規作成したカスタム・ポリシーをServicePrincipalにリンクする
• SharePoint Serverの信頼済みアイデンティティ・トークン発行者としてAzure ADを構成する
• Azure ADからダウンロードした公開鍵を登録する
• クレームマッピング、識別用属性を指定し、アイデンティティ・トークン発行者登録を行う
• SharePoint Serverのユーザ・ポリシーを構成する
• サイトへのAzure AD上のユーザへのアクセス権限を設定する

◆まずはありのままを

はじめる前に、まずは何もしない素の状態のAzure ADのws-federationでSharePoint Serverと接続するとどうなるのか？について確認しておきたいと思います。
要はSAML2.0のトークンをSharePoint Serverが受け取ったらどういう挙動をするか？の確認です。
（上記の手順のトークン発行ポリシーの変更をしないとどうなるか？という話しです）

結果、ID4014エラーが出てSAML2.0はサポートされていない、と言って怒られます。

※エラー内容がわかりやすくなるように、web.configのcustomErrors modeをoffに設定しています。


では早速。

◆Azure ADのエンタープライズ・アプリケーションにSharePoint Serverを登録する

当然ギャラリーには無いアプリケーションなので、「ギャラリー以外のアプリケーション」を選択してアプリケーションを登録していきます。
つまり、この段階ではプロトコルもトークンもSAML2.0のアプリケーションとして登録します。

アプリケーションの作成が終わったら、シングルサインオン設定を行います。
必要な設定はSharePoint ServerのEntityIDとサインオンURLです。

• EntityID
• 任意の文字列（後でSharePoint Server側に登録するRealmの文字列と同一の文字列） ※通常は「urn:sharepoint:{サーバ名}」とか「http://{サーバ名}」を使うことが多いです。
• サインインURL
• https://{SharePointサーバ名}/_trust/default.aspx ※httpsが必要なので、先にSharePointのSSL化は済ませておくこと

こんな感じです。

次に、トークン署名用の証明書をダウンロードしておきます。

また、他にも後でAzure ADのサインインURLと作成したアプリケーションのオブジェクトIDが必要になるのでメモしておきましょう。

SSO URLはシングルサインオンの構成のページに表示されているものを使います。（実際はSAMLではなくws-federationを使うので、URLのパスはwsfedに変更する必要があります）

オブジェクトIDはプロパティのページにあります。

アプリケーションIDと間違えやすいの注意です。オブジェクトIDの方を使います。

また、同じページにユーザの割り当ての設定もあるので、Azure AD上のユーザでSharePointを利用するユーザの限定が必要なければ「割り当てが必要ですか？」は「いいえ」を設定しておきます。

◆SAML1.1トークン発行用のカスタム・ポリシーの作成とリンクを行う

この作業が一番のキモです。
PowerShellを使って構成することも可能ですが、結局はInvoke-RestMethodでGraph APIを叩いているだけなので、Azure AD Graph Explorer（https://graphexplorer.azurewebsites.net/）で直接実行した方が手っ取り早いと思います。（トラブルを避けるために、先のエンタープライズ・アプリケーションの登録に使ったグローバル管理者権限を持った組織アカウントでログインしてください。マイクロソフトアカウントは不可です）

実行するのは、以下のAPIです。

• 現状のポリシーを確認する

• メソッド：GET
• リソース：https://graph.windows.net/myorganization/servicePrincipals/{先ほどメモしたエンタープライズ・アプリケーションのオブジェクトID}/policies

これで、現在アプリケーションにリンクされているトークン発行ポリシー（SAML2.0のトークンを発行するポリシー）のIDが取得できます。同時に複数のトークン発行ポリシーを一つのServicePrincipalにリンクすることは出来ないので、このポリシーとのリンクは削除してしまいます。（ポリシーそのものは他のアプリケーションで使っているので削除しない様に気を付けてください）

• ポリシーとのリンクを削除する
• メソッド：DELETE
• リソース：https://graph.windows.net/myorganization/servicePrincipals/{先ほどメモしたエンタープライズ・アプリケーションのオブジェクトID}/$links/policies/{直前の手順で取得したリンクしているポリシーのオブジェクトID}

ちなみに、Graph Explorerを使うとDELETEなどHTTP 204 no contentsが返ってくるようなクエリはいつまでたっても結果が表示されずにプログレスバーがじりじりと動くだけですが、ちゃんと処理は実行されているので、遠慮なく止めてしまってOKです。

再度、リンクされているポリシーを確認するとnullが返ってくるのでトークン発行ポリシーとのリンクが解除されたことがわかります。

次は、いよいよカスタムポリシーを作成します。

• SAML1.1トークン発行ポリシーを作成する
• メソッド：POST
• リソース：https://graph.windows.net/myorganization/policies/
• ボディ：{"displayName":"SPSAML11","type":"TokenIssuancePolicy","definition":["{\"TokenIssuancePolicy\":{\"TokenResponseSigningPolicy\":\"TokenOnly\",\"SamlTokenVersion\":\"1.1\",\"SigningAlgorithm\":\"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256\",\"Version\":1}}"]}

作成が完了したら、作成したポリシーのオブジェクトIDを確認しておきます。

• 作成したポリシーを確認する
• メソッド：GET
• リソース：https://graph.windows.net/myorganization/policies

ここで先ほど作ったカスタム・ポリシーのオブジェクトIDを取得しておき、エンタープライズ・アプリケーションとリンクします。

• ポリシーのリンクを作成する
• メソッド：POST
• リソース：https://graph.windows.net/myorganization/servicePrincipals/{先ほど作成したエンタープライズ・アプリケーションのオブジェクトID}/$links/policies
• ボディ：{"url":"https://graph.windows.net/myorganization/policies/{作成したカスタム・ポリシーのオブジェクトID}?api-version=1.6"}

このクエリも返事がない（no contents）のでポリシーのリンク状態を確認しておきます。

• ポリシーのリンク状態を確認する
• メソッド：GET
• リソース：https://graph.windows.net/myorganization/servicePrincipals/{先ほど作成したエンタープライズ・アプリケーションのオブジェクトID}/policies

これでAzure AD側の準備は完了です。

◆SharePoint Serverに信頼済みアイデンティティ・トークン発行者を登録する

先ほどAzure AD上に登録したSharePoint ServerのEntityID、Azure ADのサインオンURL、ダウンロードした証明書を用意しておき、SharePoint管理シェル（PowerShell）を管理者権限で起動、以下のコマンドを実行します。

• $realm : SharePoint ServerのEntityIDとしてAzure AD上に設定した文字列
• $wsfedurl : Azure ADのサインオンURL。最後のsaml2をwsfedに変更する
• $filepath : ダウンロードした証明書ファイルのパス

$realm = "urn:sharepoint:xxxx"
$wsfedurl="https://login.microsoftonline.com/{tenantid}/wsfed"
$filepath="C:\users\Administrator\desktop\sharepoint.cer"
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($filepath)
New-SPTrustedRootAuthority -Name "AzureAD" -Certificate $cert
$map = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" -IncomingClaimTypeDisplayName "name" -LocalClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"
$map2 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname" -IncomingClaimTypeDisplayName "GivenName" -SameAsIncoming
$map3 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname" -IncomingClaimTypeDisplayName "SurName" -SameAsIncoming
$ap = New-SPTrustedIdentityTokenIssuer -Name "AzureAD" -Description "SharePoint secured by Azure AD" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2,$map3 -SignInUrl $wsfedurl -IdentifierClaim "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"

これで信頼済みのアイデンティティ・トークン発行者の登録が完了しますので、SharePoint Serverの管理ページのWebアプリケーションの管理で認証プロバイダとして設定を行います。

対象のWebアプリケーションを選択して認証プロバイダの設定を開き、信頼済みアイデンティティ・トークン発行者の設定で先ほど作成したAzure ADを選択します。

これで、SharePoint ServerのSSO設定も完了です。

いよいよ最後です。

◆ユーザーポリシー（ユーザへの権限付与）を構成する

最後に信頼済みアイデンティティ・トークン発行者からわたってくるユーザがサイトへアクセスできるように権限を付与します。
この手順が抜けると認証は出来ても認可がされないのでログインすることが出来ません。

対象のWebアプリケーションを選択してユーザ・ポリシーを開きます。
ユーザの追加より、ピープル・ピッカーを開き、Azure ADのname（今回は識別子をname属性にしているので）を選択した状態で画面上部の検索窓にAzure AD上のユーザ名を入れて検索ボタンをクリックし、出てくるユーザを追加します。

これで全ての設定が完了です。
早速サイトへアクセスするとAzure ADへリダイレクトされ、認証が終わるとコンテンツが表示されるはずです。

SAML Tracerでトレースをしてみると、ちゃんとトークンのバージョンがSAML1.1になっていることがわかります。

<t:RequestSecurityTokenResponse xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">
    <t:Lifetime>
        <wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2018-08-12T13:00:58.881Z</wsu:Created>
        <wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2018-08-12T14:00:58.881Z</wsu:Expires>
    </t:Lifetime>
    <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
        <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
            <wsa:Address>urn:sharepoint:xxxxx</wsa:Address>
        </wsa:EndpointReference>
    </wsp:AppliesTo>
    <t:RequestedSecurityToken>
        <saml:Assertion MajorVersion="1"
                        MinorVersion="1"
                        AssertionID="_d9aa279a-50f5-4f42-a553-ea45faa33ce4"
                        Issuer="https://sts.windows.net/{tenant id}/"
                        IssueInstant="2018-08-12T13:05:58.881Z"
                        xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
                        >

いかがでしょうか？まだACSを使っている人は早めにAzure ADと直接フェデレーションする様に構成を変更しておきましょう。

サービス終了間際！Azure ACSの状況を確認する

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

数年前に一世を風靡したAzure ACS（Access Control Service）ですが、いよいよ11月でサービス提供が終了されます。

ということで過去に作ったACSネームスペースの整理を進めようと思います。

しかし、旧Azure Portalが既にアクセスできず、現在のAzure PortalからはACSのWeb管理コンソールへのリンクがどこにもない、そして作ったネームスペースの名前も忘れている、という状態で途方に暮れているのは私だけではないはずです。

そういう人のためのPowerShellのモジュールがこちらです。

Acs.Namespaces
https://www.powershellgallery.com/packages/Acs.Namespaces/1.0.2


これを使うと、過去に作成したネームスペースの一覧の参照や有効化・無効化・削除などが可能です。

早速使ってみましょう。
手順に従いモジュールのインストールをしたら、まずは「Connect-AcsAccount」でACSに接続します。
ACSのログイン画面がポップアップするのでMicrosoft Accountでログインします。

次に、Microsoft Accountが紐づいているサブスクリプションを「Get-AcsSubscription」取得します。ACSのネームスペースはサブスクリプションに紐づいているので、サブスクリプションIDを指定して検索する必要があるためです。

サブスクリプション一覧が取得できたら、「Get-AcsNamespace」ネームスペースの状態を確認してみます。パラメータには先ほど取得したサブスクリプションのIDを指定します。

こんな感じでネームスペースと管理URLが取得できます。

ちなみに、しばらく放置していたACSネームスペースは無効化されているので、StateがDisabledになっているものは再度有効化しないと管理コンソールへログインできません。
たしかこんな名前のネームスペースがあったはずだけどアクセスできなくなってる・・・という人は無効化されている可能性があるので、確認してみてください。

ネームスペースを有効化するには、「Enable-AcsNamespace」を使います。

これで管理URLへアクセスすると懐かしのACSの管理コンソールが使えます。

昔作ったリソースの移行忘れが無いようにしておきましょう。

特に久しぶりに触るSharePointの実験環境など、私も忘れていたモノがあったのでACSからAzure ADへの切り替えをしておこうと思います。（ちなみにAzure ADでSAML1.1のトークンが発行出来ない問題は密かに解決しているので、既にACSが無くても直接Azure ADでオンプレSharePointのClaim Based Authenticationは使えるようになっています。手順などはまた紹介します）

[Office365＋AD FS管理者向け] Azure ADのエンドポイント追加による可用性の向上

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

Azure AD単体（要はクラウド認証）でOffice365を使っている人には関係ありませんが、AD FSやサードパーティのIdPを使ってOffice365やAzure AD連携されたアプリケーションを使っている人は、近々エンドポイント追加の作業が必要になりそうです。

公式アナウンス）New Azure Active Directory resilience features: action required
https://cloudblogs.microsoft.com/enterprisemobility/2017/10/27/new-azure-active-directory-resilience-features-action-required/

正式なアナウンスは追ってあるようですが、要するに可用性を向上するためにAzure ADのACS（Assertion Consumer Service）のエンドポイントが増えたので、AD FSとかサードパーティのIdPでOffice365やAzure ADを使っている人は対応してね、ということらしいです。
※ちなみに、Azure AD ConnectでAD FSを構成している人は自動的に構成が変更されるみたいです。

こちらが変更までのAD FSの構成です。

手動で追加する場合はPowerShellで一括で登録することもできますし、この画面で追加しても大丈夫です。
一括追加のスクリプトは以下の通りです。

$rp = Get-AdfsRelyingPartyTrust -Identifier urn:federation:MicrosoftOnline
$endpoints = New-Object System.Collections.ArrayList
if ( $rp.AdditionalWSFedEndpoint ) { $rp.AdditionalWSFedEndpoint | %{$endpoints.add($_)} }
$endpoints.add("https://stamp2.login.microsoftonline.com/login.srf")
$endpoints.add("https://ccs.login.microsoftonline.com/ccs/login.srf")
$endpoints.add("https://ccs-sdf.login.microsoftonline.com/ccs/login.srf")
set-adfsrelyingpartytrust -targetname $rp.Name -AdditionalWSFedEndpoint $endpoints

結果、こんな感じになります。

尚、Azure ADと外部IdPを連携する際のsp-metadataを見るとまだ上記のエンドポイントは記載されていないのですが、今後は追加されてくるのかも知れませんね。

参考）Azure ADのsp-metadata
https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml

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から発行されたクレームを無条件にパススルーしようとすると以下のワーニングが表示されます。

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