2018年12月19日水曜日

TechSummitのおさらい②:Azure ADとSaaSアプリのSSO構成時のトラブルシュートあれこれ

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

前回に引き続きTechSummitのフォローアップです。

今回は2つ目のネタ「SaaSアプリのSSO構成時のトラブルシュートあれこれ」についてです。

簡単に言うと、同じ種類のSaaSアプリを複数インスタンス(例えば本番環境と開発環境とか)を単一のAzure ADとSSOの構成をしようとすると動きがおかしくなる「ことが」ある、というお話しです。

よくあるシーンはこんな感じで、本番・開発の2環境を用意したいけど、Azure ADってテナント毎、ユーザ毎のライセンスなので出来ればAzure ADは単一の環境で済ませたいよね、っていう話です。

TechSummitでは個人的な経験を基に、G Suiteを複数インスタンス用意してSSOを構成しようとしたとき、たまに発生する問題を紹介しました。
※ちなみにSalesforceでも起きることがあるようですが、すべてのアプリで発生するわけではありません。また、G Suiteでも毎回起きるわけではありません。

何が起きる(た)のか

先ほど書いたように、毎回起きるわけでもなく、発生条件も良くわからない状態なので、ここに書いたことが必ず起きるわけでもなく、他に発生する問題がある可能性もありますが、とりあえず私が体験したことを書いていきます。

  • NameIDの値のマッピングが上手くいかない(UPNを使ってくれない)
  • SP EntityIDが一致していない、と言われる


NameIDのマッピング不良と対策

まずは前者です。
初期状態のAzure ADはG SuiteのSSO構成時、NameID属性としてuserPrincipalName属性をマッピングします。また、G SuiteのNameID Formatの指定はunspecifiedです。

通常、この構成だとAzure ADはuserPrincipalNameの値をそのままG Suiteへ渡すのですが、なぜか仮名が生成されてNameIDとして渡されてしまうことがあります。通常はNameID FormatがTransientやPersistent以外は仮名が生成されることは無いはずなのですが、何かがおかしいです。


これを解消しようとすると、Azure AD側のでNameID Formatを明示的に指定してあげる(つまり、G Suiteからの指定を無視する)必要があります。
G Suiteはメールアドレス形式でNameIDの値が飛んでくるのを期待しているので、NameID Formatをemailaddress(電子メールアドレス)にしてあげます。


これでうまくいきます。


SP EntityIDの不一致

次に、SSOを試みた時に出てくる「AADSTS65005: Misconfigured application」エラーへの対策です。このエラーはAzure AD側でアプリケーション構成がおかしいので見直せ!というエラーです。


最近はAzure ADのSSO構成も人にやさしくなっており、エラーの詳しい原因が管理ポータルからある程度確認できるようになっています。(Salesforceが昔から実装していた機能ですね)
これまでSAMLのやり取りをトレース&解析しないとダメだったのですが、この機能が出来てかなり楽になりました。

この機能を使って先のエラーの原因を探ると、なぜかSP EntityID(要するにアプリケーションを一意に識別する情報)がマッチしていない、と言われます。どう見ても一致してるんですが・・・
もちろんアプリケーションが一つしか構成されていない状態ではこのようなことは言われないのですが、G Suiteを複数インスタンス構成するとタマにこのエラーが出ます。
※ちなみに昔はもっとひどかった(構成するとユーザの割り当てが混ざったりしていた)ので、マシにはなったんですが・・・


実はこのエラーが出ると、Azure AD側ではどうしようもなく、強引に複数のG Suiteインスタンス間でEntityIDが絶対に重複しない様に構成を工夫するしかなくなります。
今回やったのは、片方のG Suiteについて、Google側でEntityIDにドメイン固有情報を含めるのを辞める、という苦肉の策です。
これで複数のG Suiteインスタンス間で必ず異なるEntityIDが使われるようになるので、問題が解決します。(本来はこんなことをしなくても必ず異なるEntityIDは使われるんですが)



まぁ、今回紹介したものは発生することもある、というレベルなので仕組みを理解した上で適度に使ってもらえれば、というレベルの話でした。

引き続きフォローアップをしていきますので、お楽しみに。


2018年12月17日月曜日

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つ目以降についても順次紹介していきたいと思いますので、しばしお待ちください。


2018年11月1日木曜日

Tech Summitでは久しぶりにエンタープライズID(主にAzure ADの裏技)の話をします

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

11月~12月はイベントが立て込んでおり、準備が中々進まない今日この頃です。

こんな予定です。

  • 11/2(金)CTCフォーラム2018@品川
    • LINE@+Azure AD B2Cで新卒採用業務を改善した話し。登録率6倍、ログイン率が2倍、とそれなりの結果が出たので、事例を中心にお話しします。
    • 申込リンク(もう満席ですが・・・)
  • 11/5(月)~7(水)Tech Summit 2018@プリンスタワー東京
    • 細かくはこのポストの中で解説しますが、最近Azure AD B2Cづいていたので素のAzure ADの話を久しぶりにします。といっても正攻法は面白くないので、導入を決めた後に現場で起こるアレコレと裏技的な対応方法について解説します。
    • 出番は7日(水)の昼(ランチセッション!)です。
    • 申込リンク
  • 11/19(月)大学ICT推進協議会(AXIES) 年次大会@北海道大学
    • 大学へのAzure AD B2C + LINE@、Facebook導入の事例の発表です。この時期の北海道は寒そうだなぁ・・・
    • 出番は19日(月)です。
    • 申込リンク
  • 11/20(火)~22(木)Consumer Identity World APAC 2018@シンガポール
    • 海外遠征です。だいぶ慣れてきた?とは思いますが英語が下手なのは相変わらずなので、もう少し練習します。前日まで北海道にいるので、AXIESの出番が終わったら、そのままシンガポールへ移動です・・・
    • 内容はAzure AD B2C+SNSを使ったBYOID(Bring Your Own Identity)の話で、European Identity & Cloud ConferenceやIdentiverseで話した内容+最新のアップデートの予定です。ID on Blockchainを使ったパスワード撤廃みたいな話しやデモもやれるといいな、と思っています。
    • 出番は21日(水)です。
    • 申込リンク
  • 12/3(月)ID&IT for Education@一橋
    • ID&ITの教育機関向けバージョンです。私は慶應SFCの斉藤先生とBlockchain & BYOIDということで、ID on Blockchainの話をします。
    • 申込リンク


というわけで、直近のTech Summitの内容を少し深めに。
タイトルは
「アンドキュメンテッドAzure AD
 ~現場で遭遇する予期せぬ事態と対応~」
ということで、カタログ・スペックではわからないAzure ADの深い話をレベル200(初心者向け)に話すというよくわからないことになっています。(本当はレベル400/上級者向けのつもりだったんですが、色々と手違い?で蓋を開けたらレベル200になってました)



ちなみに、Azure AD Connectに無理をさせたり、Azure AD単体で出来ないことを他者製品と組み合わせたり、と裏技を中心に話す予定なので、録画、スライド公開はNGにする予定です。現場に来られた方だけにこっそりと、という感じです。
(というよりもMSのオフィシャルイベントで堂々と話せる内容じゃないだけです。おいおい本ブログで個別に紹介していくことは出来るネタもあるので、その辺は適当に)


と、言うことで11月~12月はあちこちに出没しますので、会場でお会いしましょう!

2018年10月23日火曜日

[Azure AD]認可コード再利用禁止ポリシーの現状

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

今月(2018年10月)のはじめに突如アナウンスされた「Azure ADのOAuth2.0におけるAuthorization Codeの再利用禁止」について現状を確認してみます。
というか、まさか認可コードが再利用できるとは思っていなかったので、アナウンスされるまで気が付きませんでした・・・。
アナウンス
https://blogs.technet.microsoft.com/jpazureid/2018/10/04/authorization-code-reuse/ 
リリースノート
https://docs.microsoft.com/ja-jp/azure/active-directory/fundamentals/whats-new#change-notice-authorization-codes-will-no-longer-be-available-for-reuse

◆アナウンスされた内容

詳しくは上記リンクを見て頂ければと思いますが、ざっくり言うと以下の事項がアナウンスされました。

  • 従来はAzure ADのOAuth2.0/Code Flowで認可エンドポイントから発行される認可コード(Authorization Code。MSの日本語訳だと「承認コード」)の再利用が出来てしまう状態だった
  • RFC 6749に準拠するため、認可コードの再利用を禁止することにした
  • 新たなポリシーはv1/v2の両方のエンドポイントに対して適用される
  • 新たなポリシーの適用は2018年10月10日から開始される
  • ポリシー適用後は認可コードを再利用しようとすると「invalid_grant」エラーが出るので、アクセストークンを取得し直す場合はリフレッシュトークンを利用するように既存のコードを修正すること


◆RFC 6749における認可コードの取り扱い

RFC 6749をみると、認可コードの取り扱いは以下の様に記載されています。

  1. 認可コードは認可サーバーによって許可される. 漏洩のリスクを軽減するため, 認可コードは発行されてから短期間で無効にしなければならない (MUST)
  2. 認可コードの有効期限は最大でも10分を推奨する (RECOMMENDED)
  3. クライアントは2回以上認可コードを使用してはならない (MUST NOT)
  4. もし認可コードが2回以上使用された場合は, 認可サーバーはリクエストを拒否しなければならず (MUST)
  5. この認可コードを基に発行されたこれまでのすべてのトークンを無効化すべきである (SHOULD)
  6. 認可コードはクライアント識別子とリダイレクトURIに紐づく.

出典)OpenIDファウンデーション・ジャパン翻訳WG
https://openid-foundation-japan.github.io/rfc6749.ja.html#code-authz-resp

この3~5番目のあたりですね。

なお、RFCにおけるMUST NOT(してはならない)の定義は「この語句、もしくは「することはない( SHALL NOT )」は、その規定が当該仕様の絶対的な禁止事項であることを意味します。」となっています。(強調は筆者による)
出典)IPA翻訳:RFC において要請の程度を示すために用いるキーワード
https://www.ipa.go.jp/security/rfc/RFC2119JA.html


・・・

「絶対的な禁止事項」って明確に書いてあるのに無視したんですね。
マイクロソフトのアナウンスを見ると、以下の注釈が付いていますので、よく理解せずに実装をしてしまったアプリへの配慮があったということなんだとは思いますが。
「アプリの破損を最小限に抑えるための試みにおいて、このパターンに依存していて、サインインが 1 日 10 回より多いアプリには、例外が与えられてきました。」


ちなみに、同じくRECOMMENDEDになっている2番の認可コードの有効期限はAzure ADでは15分です。

こちらもRFC的な意味合いを見ると「この語句もしくは「推奨される( RECOMMENDED )」という形容表現は、 特定の状況下では、特定の項目を無視する正当な理由が存在するかもしれませんが、 異なる選択をする前に、当該項目の示唆するところを十分に理解し、 慎重に重要性を判断しなければならない、ということを意味します。」(同じく強調は筆者による)とあるので、ちゃんと正当な理由の存在をもって慎重に重要性を判断したんだと信じたいところです。

15分になっている理由として、アナウンスの中の別の文章を見ると、「従来は 15 分間 (10 分間の有効期限に加えて時刻ずれを考慮して 5 分の猶予が与えられている) 有効です」とあります。時刻ずれを考慮したんですね。
ちょっと待て。。。発行から15分という話なら時刻ずれ関係なくないか?認可コードの中にタイムスタンプが埋め込まれている?唯一、Azure AD B2Cが発行する認可コードがJWTっぽいのでデコードしてみましたが、ペイロードがなくタイムスタンプ情報が入っているようには見えないんですが・・・。それとも認可エンドポイントとトークンエンドポイントが別のサーバで動いていて時刻同期がされていない、ということ?うーむ。

◆取り敢えず動作の確認

アナウンスでは10月10日から動作が変わる、ということだったので10月4日の段階で動作を確認してみました。
対象は、v1/v2/B2Cの3パターンです。

v1/v2はChrome ExtensionのAdvanced REST Clientで認可コードをトークンエンドポイントへ何度投げ込んでもIDトークン、アクセストークン、リフレッシュトークンが返ってきます。

15分経過すると有効期限切れのエラーが出ます。10分か15分かは置いておいてこちらは正しい挙動ですね。


尚、Azure AD B2Cの場合はAdvanced REST Clientだと上手く動かないことがあるので(Client Secretに記号が含まれることが多いから?)、Postmanを使って動作確認をします。

ツールは違えど、v1/v2と同じ動きです。


◆10月10日を超えたらどうなったのか?

ということで本題です。
10月10日を超えたので、どのような動きになったのか確認してみましょう。

結論から言いますと、アナウンス通りに認可コードの再利用が禁止されたのはv2エンドポイントだけでした。v1とAzure AD B2Cでは相変わらず認可コードが再利用できてしまいました。何か事情があったんでしょうか。。。

以下、v2エンドポイントで認可コードを再利用した際に出るエラーです。

「OAuth2 Authorization code was already redeemed」ってあるので、ちゃんと再利用だと判断されているようです。



いずれにしても認可コードの再利用を前提としたコードがあれば早めに書き直しましょう。v1/B2Cもそのうち再利用禁止になると思いますので。

2018年10月4日木曜日

Windows 10 October 2018 UpdateのEdgeでWebAuthnを試す

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

昨日は #idcon vol. 25 「fidcon 勝手に Meetup」が品川のマイクロソフトで開催されていたので、参加してきました。なんともタイミングの良い?ことに、ちょうど Edge が正式に WebAuthn に対応した、Windows 10 October 2018 Update がリリースされたタイミングと重なりました。

ローンチのアナウンス
https://blogs.windows.com/windowsexperience/2018/10/02/how-to-get-the-windows-10-october-2018-update/


ちょうど日本マイクロソフトの物江さんが Edge の WebAuthn のセッションでデモをされたりもしており、なんというタイミング?!ということで、何か持っているんだと思います。

私はセッション中に Windows Update が降ってきてついつい再起動してしまったので、イベント終了後も開きっぱなしの Macbook Air を持ったまま品川の街を歩くハメになりましたが・・・


ということで、Edge のWebAuthn を試してみましょう。
手元にあったのは、FIDO2 に対応した Yubikey Security Key(青い奴)とマウスコンピュータの指紋認証用の USB ドングルなので、この辺りを使ってみます。

右:Yubico セキュリティキー
左:マウスコンピュータ FP01

テスト用のサイトとして、https://webauthn.org/ を使います。
内容としては、

  1. ユーザとデバイスを登録する
  2. ログインする

というシンプルなモノですが、Debug Windows でプロトコルの詳細なメッセージが確認できるので非常に便利です。
ちょうど最後のセッションで @shiroica さんがお話ししてくださった各パラメータの紹介が非常に役に立ちます。


ちなみにこのテストサイトではあまり細かいパラメータが触れるわけではなく、authenticatorSelection の指定は出来ず、attestation も direct 固定となっています。
この辺りを試すには https://webauthn.io/ を使った方が良いかも知れません。
ちなみに Google の @agektmr さんの話では、Google としてはエンタープライズのシナリオを除き attestation は none がお奨めとのことです。(会社が指定した Authenticator だけを使わせたい、というようなケースですね)

1.ユーザとデバイスを登録する

Register タブで Usernameを指定して Register ボタンを押すだけです。

画面の下の部分の Advanced を開くと実際のメッセージを確認することが出来ます。

PubKeyCredParams で -7 と -257 があることから U2F と Windows Hello に対応していることがわかったり、 attestation は direct となっているあたりがわかります。

登録が正常に完了すると OK とステータスが返ってきていることもわかります。

2.ログインする

同じく Login タブを開いてユーザ名を指定、Login ボタンをクリックすると今度はログインのプロセスが実行されます。

尚、Resident-key が使える FIDO2 対応の Authenticator で同じユーザ名で複数回 Registration を行うとログイン時に一覧が出てきます。
(本来は先にユーザ名を指定しているのでキーの特定をした上でログインプロセスが走るのでアカウント選択は出ませんが、同じ名前で登録すると毎回鍵ペアが生成されてしまうみたいです。RPの作りの問題?)

Authenticator で認証します。

ちゃんと webauth.get が成功しています。


もう少し詳しく勉強しないと細かいところはよくわからないので、続きは今晩開催される WebAuthn もくもく会で!
 https://fido2-workshop.connpass.com/event/100944/

2018年9月25日火曜日

Azure AD関連Update@Ignite 2018

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

Igniteのシーズンですね。

昨晩のKeynoteに引き続き今晩もAzure AD、EMS関連のUpdateが色々とあるようなので、楽しみです。

取り急ぎ詳細は今晩以降ですが、個人的に重要なアップデートは以下2点ですかね。

1.Passwordless login to Azure AD
 Microsoft Accountで実装されているAuthenticatorアプリを使ったパスワードレスのログインです。※画像はAlex Simonsのtwitterより。

 早速Techcrunchなども記事にしてます。
 https://techcrunch.com/2018/09/24/microsoft-wants-to-help-you-do-away-with-more-passwords/

2.IntuneでWin32アプリの配布が可能に
 結局GPOとの併用が辞められないIntuneですが、一つの大きな理由にWin32アプリの配布の課題もあったと思うので、この辺りも気になるところですね。



何しろ、セッション検索でキーワード指定をすると膨大な量が出てくるので、追いかけきれません・・・
・Active Directory : 113セッション
・Identity : 182セッション

とりあえず、Windows Server 2019のGAも決まったことですし、この辺りは必見かと。
BRK2254 - Azure Active Directory: New features and roadmap
BRK3030 - What's new in Active Directory Federation Services (AD FS) in Windows Server 2019
THR2312 - Trusted Identity Platform: Passwordless Auth using Azure AD

2018年8月30日木曜日

[Azure AD B2B]GoogleとのID連携によりユーザの招待が簡単になりました

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

Azure AD B2Bを使うと外部のユーザを招待し、組織のアプリケーションへのアクセスを付与することが出来ます。
この招待は
・Azure ADテナントを持っている組織の人
・Azure ADテナントを持っていない組織の人や個人
に対して送信することが出来、これまでAzure ADテナントを持っていない人は招待メールを受け取ったら、招待元のディレクトリにサインアップする際にログイン・パスワードを設定する必要がありました。

つまり、滅多にアクセスしない外部組織のアプリケーション専用にアカウントを作らなければならない、ということが発生するのでゲストユーザからすると非常に面倒くさい話ですし、パスワード忘れなども発生しやすいので管理上の問題も発生しやすい状況でした。

今回、Azure AD B2Bの新しく公開(現状パブリック・プレビュー)されたのが、Googleアカウントを持っている個人(G Suiteではなく、gmail.comのユーザ)を対象に、Google側の認証でAzure AD B2Bのテナントへログインできるようにする機能です。

 公式Blog)
 Azure AD B2B Collaboration support for Google IDs is now in public preview
 https://cloudblogs.microsoft.com/enterprisemobility/2018/08/28/azure-ad-b2b-collaboration-support-for-google-ids-is-now-in-public-preview/

やっていることは非常に単純でAzure ADに外部Identity ProviderとしてGoogleを設定、ゲストアカウントのドメインがgmail.comならGoogleにリダイレクトする、という仕組みです。

では、やってみましょう。
詳細は公式ドキュメントを参照してください。

◆GoogleにOAuthのクライアント登録を行う

結局のところ、Azure AD B2BがGoogleに対するOAuthクライアントとなるので、クライアント登録をしてあげる必要があります。

GoogleのDeveloper Consoleより作業を行います。
 https://console.developers.google.com/

必要な作業は、
・プロジェクトの作成
・OAuth同意画面
・OAuthクライアントの登録
の3点です。

ポイントは、OAuthクライアント登録時のリダイレクトURIの設定くらいだと思いますので、詳細は省きますが以下の通り設定を行います。
リダイレクトURIとしてセットする値
 https://login.microsoftonline.com
 https://login.microsoftonline.com/te/{Azure ADのテナントID}/oauth2/authresp



こんな感じで登録されますので、Client IdとClient Secretをメモしておきます。


◆Azure ADに外部Identity Providerを設定する

次は、Azure AD側の設定です。

ポータルからAzure ADを開くと、「Organizational relationships」という見慣れないメニューが出てきているので、こちらを開いていきます。


続いてIdentity ProvidersからGoogleを追加します。

すると、GoogleのClient IDとClient Secretを求められるので、入力して保存します。

これでおしまいです。

◆Googleアカウントを招待する

これは従来のAzure AD B2Bの操作と全く同じです。
Gmailのメールアドレスで招待するだけですね。

これで招待メールが飛んでくるのでディレクトリへアクセスします。

従来はココでゲストユーザにパスワードを登録する様に求められましたが、今回の機能を使っているとパスワードは不要なのでそのままユーザが作成されます。


上手くいくとアクセス・パネルが表示されます。


アプリケーションも使え、属性が取得できています。


ちなみに、自組織にAzure ADテナントが無いゲストユーザがアクセス・パネルにアクセスする時は、https://myapps.microsoft.com が使えません。どのテナントにユーザがいるのかが判別できない&組織アカウントなのかマイクロソフト・アカウントなのかの判別が出来ないためです。(マルチテナントアプリケーションも同様です)

そこで、招待元のテナントを決めうちでアクセスする必要があるので、以下のように招待元ディレクトリのテナントIDをパラメータにつけてアクセスしてください。
https://account.activedirectory.windowsazure.com/r?tenantid={招待元のテナントID}

取り敢えず個人のGmailアカウントはこれで便利になりました。
ちなみにG Suiteの場合はこの機能ではなく、G SuiteをSAML IdPとして構成、ドメイン単位でのID連携を構成すれば動くはずです。(やってませんが。。また紹介します)

2018年8月27日月曜日

[LINE Login/LIFF]メールアドレス登録無しでLINEログインできるWebアプリを作るには

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

LINEログインを使うと、WebサイトへLINE IDを使って簡単にログインすることが出来ます。

また、LINEログインにはオートログインという機能があり、特定の環境においては端末にLINEアプリがインストールされていれば、ブラウザでLINE IDとパスワードを打ち込むことなく、Universal Linkやインテントを使ってLINEアプリへの遷移、自動的にログインをすることが出来ます。

しかし、このオートログイン、少々適用条件が厳しめです。

https://developers.line.me/ja/faq/ より
iOSの場合
LINE 5.2.0以降:LINEのアプリ内ブラウザでLINEログインv2の自動ログインが可能
LINE 7.5.0以降:SafariブラウザでLINEログインv2の自動ログインが可能
LINE 7.12.0以降:LINEログインv2.1の自動ログインが可能

Androidの場合
LINE 6.3.0以降:外部ブラウザででLINEログインv2の自動ログインが可能
LINE 6.4.0以降:LINEのアプリ内ブラウザでLINEログインv2の自動ログインが可能
LINE 7.14.0以降:LINEログインv2.1の自動ログインが可能


こうなってくると、私のようにiOSでChromeを使っている人は結局IDとパスワードの入力から逃れられず、ソーシャルログインのメリットが目減りしてしまいます。
(もちろん、セッションが永続するので2度目以降は大丈夫なんですが)

Safariの場合:LINEアプリが立ち上がり自動ログインされる


Chromeの場合:初回はログイン画面が表示され、2回目以降は確認だけ行われる



結局のところ、外部ブラウザからの遷移を考えるからこうなるので、LINEアプリ内のブラウザでWebアプリを開いてもらえばこのような問題は起きない話しです。ただし、これまではユーザにアプリ内ブラウザの利用を強制する方法がなく、リッチメニュー(トークルームの下に表示できるカスタムメニュー)を個別に作って対応したりしていた訳です。

こういう時に便利なのが、LIFF(LINE Front-end Framework)です。

 LIFF概要
 https://developers.line.me/ja/docs/liff/overview/

仕組み的には、LINEのカスタムURLスキームを使ってLINEアプリ内のブラウザを立ち上げる、という単純な仕組みです。これまではLINEアプリ内でカメラを立ち上げたり、特定のボットのタイムラインを開くことは出来たのですが、アプリ内ブラウザを立ち上げることが出来なかったので、LIFFの登場によりLINEアプリを外部からコントロールする幅が大きく広がった、と言えるでしょう。

 LINEで利用できるURLスキームの一覧
 https://developers.line.me/ja/docs/messaging-api/using-line-url-scheme/


LIFFを立ち上げるには
 line://app/{liff_app_id}
を指定します。

LIFFアプリを作成する際、特定のURLを開くような形でLINEプラットフォームへ登録するため、カスタムURLスキームで外部からLIFFアプリが呼び出されると、LINEアプリ内であらかじめ登録したWebページが開かれる、という仕組みです。

この仕組みを応用すれば、LINEログインをさせたいアプリを開いたときはLIFFを経由して強制的にアプリ内ブラウザを起動する、ということが出来るので、呼び出し元ブラウザを意識することなくオートログインをさせることが出来るようになります。

では、早速やってみましょう。


◆LIFFアプリを登録する


LIFFはボット(Messaging API)の一部の機能として提供されていますので、LIFFを登録するためのエンドポイントへのPOSTを行う際は、Messaging APIのチャネルのアクセストークンを使います。

具体的には、こんな感じのクエリを投げます。
エンドポイントhttps://api.line.me/liff/v1/apps
メソッドPOST
リクエストヘッダauthorizationBearer {Messaging APIのチャネルアクセストークン}
content-typeapplication/json
ボディ{
"view":{
"type":"full",
"url":"起動したいWebアプリのURL(要https)"
}
}


上手くいくと、LIFFアプリIDがボディで返ってきます。
{
 "liffId": "xxxxxx"
}

このボディにセットするURLにLINEログインをさせたいWebアプリのURLを指定すればLINEアプリ内のブラウザでアプリを起動することが出来るので、オートログインができるようになります。


◆LIFF経由でWebアプリを呼び出す


後は呼び出すだけですので、User-Agentを見るなりなんなりしてモバイル系ならカスタムURLスキームで呼び出せば問題ありません。

LIFFアプリを外部ブラウザから呼び出します。


LINEアプリ内でWebアプリが起動され、自動ログオンされます。


ちょっとトリッキーではありますが、現段階で様々な環境のユーザをアプリ内ブラウザへ誘導するにはこの方法しかなさそうなので、覚えておくとよいかと思います。

2018年8月15日水曜日

サービス終了間際の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と直接フェデレーションする様に構成を変更しておきましょう。