2018年12月25日火曜日

TechSummitのおさらい④：Azure ADからSaaSアプリへのプロビジョニングのアレコレ

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

引き続き、TechSummitのおさらいをしていきます。
今回はAzure ADからSaaSアプリへのプロビジョニングの話しです。

Azure ADからプロビジョニングできるアプリケーションの条件は以下の通りです。

  • ギャラリーに掲載されていてプロビジョニングに対応しているもの
  • SCIM2.0に対応しているもの

現状（2018年12月現在）ギャラリーに掲載されているアプリは3,057個で、プロビジョニングに対応しているのは30個ですので、やはりプロビジョニングはハードルが高いですね。
こちらが一覧です。


サービス名
Amazon Web Services (AWS)
Asana
BlueJeans
Bonusly
Box
Cerner Central
Cisco Spark
Concur
Cornerstone OnDemand
DocuSign
Dropbox for Business
G Suite
GitHub
GoToMeeting
Jive
LinedIn Elevate
LinkdIn Sales Navigator
Lucidchart
Netsuite
Pingboard
Salesforce
Salesforce Sandbox
Samanage
ServiceNow
Slack
Tableau Online
ThousandEyes
Workday
Workplace by Facebook
Zendesk

ここに記載がないアプリケーションの場合や自分で開発しているアプリケーションの場合は、SCIM2.0に対応していればある程度対応させることが出来ます。
ちなみに、以前はSCIM2.0に対応している、かつ「Azure ADでSCIMのエンドポイントの保護をしていること＝Azure ADが発行したアクセストークンで認可されること」という縛りがあったのですが、最近カスタムのアクセストークンでもアクセスできるようになりました。（Azure AD上へ固定で設定する必要があり、自動リフレッシュなどもできず微妙ですが）

このシークレットトークンにカスタムのアクセストークンを指定します。指定しなければ従来と同じく、Azure ADで発行されたアクセストークンを使ってAPIへアクセスします。


さて、本題です。
TechSummitでは実際にプロビジョニングをやってみると起きる問題についてG Suiteとの連携を例に解説しました。

もちろんすべてのアプリケーションで発生する問題ではありませんが、ざっくり言うと、

  • 複雑な同期ルールは設定できない（例えば、人事発令後7日以内は所属を新旧で兼務させる、などは無理）
  • プロビジョニング設定をしてテスト接続をして保存するとエラーが出てどうしようもなくなる（これはG Suite限定かもしれませんが）
  • 標準外の属性を定義してマッピングしても同期されない（これもアプリに依存）
のような話があり、カタログスペック的にプロビジョニングに対応してるから使える！と思い込むと痛い目にあいます。

すこし具体的な例とワークアラウンドを含め紹介していきます。

プロビジョニング設定時にエラーが出てどうしようもなくなる件

先にも書いた通り、G Suite限定かもしれませんが、プロビジョニング設定をして保存をした時にエラーが出ることがあります。しかも、このエラーが出てしまうと二度とプロビジョニング設定を行うことが出来なくなります。

どうやら、既知の問題らしく、ワークアラウンドとしてSSO用のＧSuiteとプロビジョニング用のG Suiteを分けて定義すると上手く動くんですが、アプリケーションへのユーザの割り当てなど結構面倒くさいです。


追加属性のマッピングが上手く反映されない

これも良くある質問で、アプリケーションの種類にかなり依存する話っぽいです。
例えば、経験上ServiceNowなんかはある程度カスタム属性をマッピングしても動いてくれましたが、G Suiteは全くダメです。
しかも、実環境でよく使われるOU（orgUnitPath）が上手くプロビジョニング出来ないのは致命的でgithubでも昔からissueが立っているくらいです。


同じく、G Suite側で作ったカスタム属性も全く無視されちゃいます。


では、どうするのか？

使えないから諦められるのか？という話になりますが、Azure AD自体のプロビジョニング機能を使うのは、現状ある程度割り切った環境でないとあきらめた方がベターです。

ということで、
  • Azure AD ConnectをMIM的につかう（カスタムMAを使う）
  • Azure FunctionとGraph API Subscriptionを使って自前プロビジョニングする
の2択が現実的です。
※開発を伴うので、サポートをどうするかを含め熟考の上で使ってください。

Azure AD Connectの魔改造

まぁ、みなさんご存知のとおりAzure AD Connectの実体はMIM（Microsoft Identity Manager）です。しかもAzure AD ConnectにはSynchronization Rules Editorが付属しており、かなり優秀なので、MIMにもこのエディタをバックポートしてくれないかな、と本気で思います。

話しがそれましたが、実体がMIMなのでMIM用に作ったカスタム管理エージェントを組み込むとほぼ何でもできます。


ちなみに、MIMとAzure AD Connectではインストール時のフォルダ構成が異なるので、管理エージェントを後から組み込む場合はAzure AD Connectに合わせてバイナリを移動してあげる必要があります。

後は、先のSynchronization Rules Editorで同期ルールを書けばうまく動くようになります。

Graph APIのSubscriptionを使う

別の方法はGraph APIのSubscriptionを使う方法です。
SubscriptionとはAzure AD/Office365上のオブジェクトに特定のイベントが発生した時に外部のAPIへWebhookを飛ばす機能です。
通常はOffice365のメールボックスにメールが配信されたら外部APIを叩く、などといった使い方をするのですが、Azure AD上のユーザに更新がかかったら変更内容を通知する、という使い方をすることでプロビジョニングに応用できます。
ちなみにプロビジョニング処理自体はAzure Function等を使って完全に自前で実装することになります。

Subscriptionを作成する際もGraph APIを使います。
対象のリソース（users）と検知対象のアクション（updated）、Webhook通知先URLを指定してSubscriptionを作成します。

尚、現状だと検知対象のアクションとしてcreatedやdeletedを指定するとエラーが出るのでupdatedしか使えません。作成と削除はAzure ADのプロビジョニング機能を使い、更新はSubscription経由で実施する、という構成にしないといけません。

ちなみに作成したSubscriptionオブジェクトの有効期限は最大3日間なので、期限が切れる前に更新をしないと自動的に削除されてしまいます。


Subscriptionが有効な状態でユーザオブジェクトに更新がかかると指定したURLに対してWebhookが飛んできます。
この内容をパースして適切な処理を行いましょう。G Suiteの場合はAdmin SDKを使ってG Suite上のユーザの属性を更新する、などの処理ですね。



今回はこのくらいです。
プロビジョニングは結構鬼門なので、使う場合は十分に事前調査～準備をしてから使い始めるようにしてください。
時刻: 0 件のコメント:

2018年12月21日金曜日

TechSummitのおさらい③：Azure AD + Auth0 で条件付きアクセスを構成する

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

そろそろディープになってきました。公式イベントで話すにはかなり気が引けるネタ度Maxです。

今回はAuth0（おーすぜろ）とAzure ADを組み合わせることで複雑なことをやろう！という話です。

もちろんAzure ADにはPremium P1/P2という複雑なことをやりたい人向けのプレミアなライセンスがありますので、お金に余裕のある方、一気通貫でサポートを頼みたい方は迷わずそちらを選んでください。

Auth0とは？

Auth0もMicrosoftやOkta、PingIdentity、OneLoginなどと同様にIDaaS（Identity as a Service）を提供しているサービスプロバイダです。jwt.io辺りで有名ですね。
ちなみにFounderは元マイクロソフトのEugenio Paceです。「A Guide to Claims-Based Identity and Access Control」をVittorio Bertocciと一緒に書いた人ですね。まだ彼がMSにいる時代にやり取りをしてサイン本をもらったりしたもんです（遠い目）。最近は共著のVittorioもAuth0へ移ったのが個人的なビッグニュースでした。

少し特徴的なのは「開発者向け」である、という売り出し方をしているところですね。開発者向けたる所以は、ひたすらかゆいところに手が届くから、というのが最大の理由だと思います。

このAuth0、実は別のサービスとしてWebtaskというFaaS（Function as a Service）を提供しており、ID関連の機能の各所にこのWebtaskをどんどん差し込んでいくことが出来るんです。このことにより、例えばid_tokenの中身を見て処理を実行したり、ID登録直後に別の処理を走らせたり、など開発者がやりたい放題出来てしまいます。


Azure AD + Auth0？

さて、Azure ADとAuth0を組み合わせると何が出来るのか？という話に移りたいと思います。
Auth0はAuth0自体にIDを保持して自身がIdPとして振舞う以外に、外部のIdP（Connectionと呼んでいます）とID連携する機能を持っています。また、当然のごとく外部のSPとID連携することもできます。
このことを使い、IDの保持とベーシックな認証機能はAzure ADで、複雑な処理（今回は条件付きアクセスと多要素認証）はAuth0で担当、というようなことを実現することが出来ます。
使えるプロトコルも多様なので、アプリ（今回はG Suite）とAuth0の間はSAML、Auth0とAzure ADの間はOpenID Connect、という構成を組んでみました。


Azure ADのアプリ（RP）としてAuth0を登録

早速構成していくわけですが、まずはAuth0の外部IdPとしてAzure ADを構成するためには、Azure ADのRelying Party（RP）としてAuth0を登録してあげる必要があります。具体的には、ReplyUrl（応答URL）にAuth0のエンドポイント（Callback）を登録し、Auth0側に設定するためのClient IDとClient SecretをAzure ADから払い出します。

Azure ADのアプリ登録メニューより登録を行います。
　Azure ADに登録するAuth0のCallback URLは以下の通りです。
　　https://{テナント名}.auth0.com/login/callback


Auth0の外部IdPとしてAuth0を登録

次は、逆側の設定なので、Auth0にAzure ADの情報を登録していきます。
ちなみにAuth0はビルトインのConnectorとしてAzure ADが用意されているので、こちらを使ってもいいですし、OAuthを使ってカスタム接続するためのExtensionもあるのでこちらを使って接続しても問題はありません。

こちらがビルトインのAzure ADとの接続Connector

こちらがOAuthを使うExtension


私は後者のExtensionを使っています。（というかビルトインでAzure ADが存在しているのを知らなかった・・・）
Azure ADの認可エンドポイント、トークンエンドポイントと先ほどアプリ登録した際に取得したClient IDとClient Secretを登録します。

ちなみに、例のWebtaskを使ってGraph APIでAzure AD上のユーザ情報を取得することが出来ます。SAML Assertionに属性を入れてアプリに渡す必要があるので、必要な属性を取得する様にスクリプトを作ります。
function(accessToken, ctx, cb) {

  request.get('https://graph.microsoft.com/v1.0/me', {
      headers: {
        'Authorization': 'Bearer ' + accessToken,
      },
      json: true
    },

    function(e, r, u) {
      if (e) return cb(e);
      if (r.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode));
      var profile = {
        user_id: u.userPrincipalName,
        name: u.displayName,
        email: u.mail
      };
      cb(null, profile);
    });
}


直観的にわかりやすいスクリプトだと思うので、あまり解説する必要もないとは思いますが、トークンエンドポイントから取得したアクセストークンがコンテキストとコールバック先のオブジェクトと一緒に渡ってくるので、Graph APIにアクセスして必要な情報を取得、Profileとして設定して返却してあげる、という流れです。

G SuiteとAuth0をID連携

ここはこれまで何度となく解説してきたG Suiteのシングルサインオン設定の世界なので、G Suite側は目をつぶっていても構成できてしまう世界だと思いますので、Auth0側の設定を中心に。

ちなみにAuth0にはApplicationギャラリー的なプリセット・アプリのリストは存在しません。めちゃくちゃシンプルにNative App、SPA、Regular Web App、Machine to Machine Appの4種類しかありません。

G Suiteなど通常のアプリを使う場合はRegular Web Appを選びましょう。

また、Regular Web Appを選んだとしてもデフォルトではアプリと言っても単純なOAuthのクライアント登録しか出来ないので、AddOnという形でSAML等のプロトコルを設定してあげる必要があります。
SAMLの設定もかなりプログラマブルなので、Assertion内の各種パラメータをガリガリと書いていきます。本当に痒い所に手が届きます。ほぼ出来ないことは何もないので、Assertionの書き方の方言でうまくアプリと繋がらない、というトラブルとは無縁だと思います。その代わりSAML Assertionの中身の仕様について熟知している必要はありますが。


この構成のページからIdP MetadataやAssertion署名用の証明書のダウンロードなども可能なので、エンドポイントや証明書をG Suite側に設定してあげれば完了です。

これで一通り単純なシングルサインオンについて出来るようになっています。


条件付きアクセスを構成する

ここまでだとAuth0がG SuiteとAzure ADの間に挟まっている必要性が全くないので、最初に書いた通り、条件付きアクセスを構成してみます。
本来Azure ADではPremium P1のライセンスが必要な機能です。

Auth0での条件付きアクセスを構成するには、Rulesメニューよりルールを構成します。
このルールもJavascriptでガリガリと書いていくことが出来るので、ものすごく柔軟です。アクセス元の状態はContextから取得できるので、ソースIPやUser Agentなど様々な情報を見て多要素認証の適用の有無など各種条件を設定することが可能です。
function (user, context, callback) {
  const ipaddr = require('ipaddr.js');
  // 社内ネットワーク
  const corp_network = "x.x.x.x/16";
  // 対象のアプリケーションのclient_id
  const CLIENTS_WITH_MFA = ['G SuiteのClient Id'];

  // 接続元のソースIP
  const current_ip = ipaddr.parse(context.request.ip);
  if ((!current_ip.match(ipaddr.parseCIDR(corp_network)) && (CLIENTS_WITH_MFA.indexOf(context.clientID) !== -1))) {
      context.multifactor = {
        provider: 'google-authenticator',
        allowRememberBrowser: false
      };
  }

  callback(null, user, context);
}


ここまで構成すると社内アドレス以外からG Suiteを使おうとすると多要素認証（今回はGoogle Authenticator）を要求される様になります。



こんな感じでAzure AD+Auth0で見た目はぼぼAzure AD Premiumの条件付きアクセス、ということが実現できてしまいました(笑)。

まだまだネタは続きます。では次回！
時刻: 0 件のコメント:

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は使われるんですが）



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

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


時刻: 0 件のコメント:

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


時刻: 0 件のコメント:

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月はあちこちに出没しますので、会場でお会いしましょう！
時刻: 0 件のコメント:

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

この３～５番目のあたりですね。

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


・・・

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


ちなみに、同じくRECOMMENDEDになっている２番の認可コードの有効期限は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もそのうち再利用禁止になると思いますので。

時刻: 0 件のコメント:

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 だけを使わせたい、というようなケースですね）

１．ユーザとデバイスを登録する

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

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

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

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

２．ログインする

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

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

Authenticator で認証します。

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


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

時刻: 0 件のコメント:

2018年9月25日火曜日

Azure AD関連Update@Ignite 2018

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

Igniteのシーズンですね。

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

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

１．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/

２．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

時刻: 0 件のコメント:

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連携を構成すれば動くはずです。（やってませんが。。また紹介します）
時刻: 0 件のコメント: