ラベル 条件付きアクセス の投稿を表示しています。 すべての投稿を表示
ラベル 条件付きアクセス の投稿を表示しています。 すべての投稿を表示

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の条件付きアクセス、ということが実現できてしまいました(笑)。

まだまだネタは続きます。では次回!

2018年1月22日月曜日

[Azure AD]条件付きアクセスのポリシー適用状態を確認する「What If機能」

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

Azure Active Directory(Azure AD)の条件付きアクセス機能を使うとアクセス元のネットワークやデバイス、クライアントアプリケーションの種類により、アプリケーションへのアクセスを制御(ブロックしたり多要素認証を要求したり)することが出来ます。

実際の案件で条件付きアクセスがどうやって使われているのか?については昨年のde:codeで紹介させていただきましたので、見てみてください。



ただ、この条件付きアクセスですがテストをするのが結構面倒なんです。当たり前ですが、すべてのアクセス元のネットワーク、デバイス、クライアントの種類を網羅的に準備することは中々現実的ではないので。

ということで先日新しくリリースされた条件付きアクセスのポリシーの適用状況をシミュレーションしてくれるテスト機能「What If」を使ってみます。


使い方は非常に簡単で、Azure ADの条件付きアクセスの設定画面からポリシー一覧を確認すると「What If」というボタンがあります。


これをクリックするとユーザ、対象のアプリケーションなどシミュレーションしたい条件を設定することが出来ます。

まず、ユーザを選びます。

次に対象アプリケーションを選びます。(すべてのアプリ、でもOKです)

後はアクセス元のネットワークアドレスとデバイスの種類、クライアントアプリケーションの種類を選択して、「What If」をクリックします。


すると適用されるポリシー一覧が表示されます。
この場合は多要素認証を適用するポリシーが出てきましたので、この条件だと多要素認証を要求されることがわかります。

逆に適用されないポリシー一覧も確認できます。その際に適用されない理由も含めて確認が出来るので、非常に便利です。



条件付きアクセス・ポリシーのネットワークアドレスの変更など構成変更をする際、事前にテストが出来るのでとっても便利です。

2017年11月6日月曜日

11/30までにAzure AD管理者がやっておくべきこと:条件付きアクセスの設定移行

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

いよいよ今月末(11月30日)でAzureクラシックポータル(旧ポータル)が廃止されます。

公式アナウンス)Marching into the future of the Azure AD admin experience: retiring the Azure AD classic portal
https://cloudblogs.microsoft.com/enterprisemobility/2017/09/18/marching-into-the-future-of-the-azure-ad-admin-experience-retiring-the-azure-classic-portal/

Azure ADの管理機能も「ほぼ」新ポータルへ移行されたのですが、旧ポータルでアプリケーション単位で設定をしてきた条件付きアクセスの設定が新ポータルの条件付きアクセスでは触れず、メンテナンスは新・旧でバラバラに行う必要がありました。

この状態で旧ポータルを廃止されるとかなり困ったことになるのですが、先日ようやくマイグレーションパス(というか緩和措置?)が発表されました。

公式アナウンス)This one is important: Time to migrate your v1.0 Conditional Access policies to v2.0!
https://cloudblogs.microsoft.com/enterprisemobility/2017/10/23/this-one-is-important-time-to-migrate-your-v1-0-conditional-access-policies-to-v2-0/

簡単に言うと、旧ポータルの条件付きアクセス(v1.0)を新ポータルの条件付きアクセス(v2.0)でも見えるようになる(だけ)の機能の発表です。

11月30日の廃止の1か月前のアナウンスというタイトな感じなので、早くやっておかないとハマりそうな感じ満載です。(しかもPreview機能という・・・このまま永遠にPreviewなんだと思いますが)

ということで、早速試してみます。

◆旧ポータルの状態の確認

まずは旧ポータルで現状を確認しましょう。アプリケーションの構成から条件付きアクセスの確認をすることが出来ます。そういえばネットワークの場所ベースとデバイスベースが独立したメニューになっていたんですね。この画面も見納めかと思うと画面ショットを撮りまくっておきたい気分になります。



◆新ポータルから旧ポリシーを確認する

既に皆さんの新ポータルから旧ポリシーが確認出来るようになっていますので、見てみましょう。Active Directoryを開き、条件付きアクセスを見ると、Classic Policies(Preview)というメニューが追加されています。


メニューを開くと、

  • [アプリケーション名] MFA and location policy(場所ベースの場合)
  • [アプリケーション名] Device policy(デバイスベースの場合)

という形でポリシーが見えるようになっています。

ポリシーを選択するとどのようなポリシーだったのか、内容の確認ができます。


では、早速移行してみます。

◆信頼済みIPリストの移行

まず、旧ポリシーでは信頼済みIPとして多要素認証の管理画面で指定したネットワークリスト(上限50個)しか指定できませんでした。
もちろん新ポータルでも多要素認証で指定したネットワークリストも使えますが、数の上限があるのと、一覧で書くしかないので使い勝手があまりよくありませんので、せっかくなのでこの機会にNamed Locationsを使いましょう。こちらを使えば、ネットワークに名前を付けることが出来るので、例えば事務所のロケーション毎にネットワークアドレス群に名前を付けて管理することが可能です。

もちろん、この画面からConfigure MFA trusted IPsをクリックすれば多要素認証のネットワークリストを確認・設定することが可能ですので、こちらから設定を移行しましょう。

新規Named Locationを追加するとネットワークに付ける名前、指定方法(IPレンジか、国や地域)、信頼済みIPとして扱うかどうか、実際のネットワークリストの指定を行うことが出来ます。ここへ多要素認証の信頼済みIPリストを移行しておきましょう。


◆ポリシーの移行(作り直し)

条件となるネットワークの移行が終わったら、旧ポリシーを参考に新ポリシーを作成します。
設定すべき項目は以下の通りです。

  • ポリシー名 : 任意の名前
  • 対象のユーザ・グループ : ポリシーの適用対象、除外対象ユーザ・グループの指定
  • 対象のアプリケーション : ポリシーの適用対象、除外対象アプリケーションの指定
  • 適用条件 : ポリシーの適用条件(ネットワーク、デバイス状態)
  • アクセスコントロール : 条件にマッチした場合のアクションの指定(多要素認証の要求やアクセスのブロック)
  • セッション : 現状はまだPreviewですが、一部のアプリケーション(SharePoint Online)における制限やCloud App Securityと連携したコントロールが出来ます。

まずは、適用対象のユーザとグループです。
よく使うポリシーとしてInclude(適用対象)に全員を入れておいて、Exclude(除外対象)に一部のグループを入れておいて一時的に多要素認証のデバイス(スマホなど)を忘れた人を救済する、というポリシーです。


次にアプリケーションです。
旧ポータルではアプリケーション単位にポリシーを作成する必要がありましたが、新ポータルでは全体に適用する共通ポリシーや一部の選択したアプリケーションへ適用するポリシーを作成することも可能になりましたので、この機会にポリシーの見直しをしても良いかも知れません。

次に適用条件です。
今回は移行元がネットワークの場所ベースの条件付きアクセスだったので、Locations設定でInclude(適用対象)をすべて、Exclude(除外対象)を信頼済みネットワークとして指定します。(ここでAll trusted locationsとすると多要素認証の信頼済みIPリストと、信頼済みとするにチェックを入れたNamed locationの両方のorをとったものが対象となります)

後はアクセスコントロールです。
条件にマッチした場合に多要素認証を要求する場合は、Grant accessにしてRequire multi-factor authenticationを指定しておけば大丈夫です。

最後に、ポリシーをEnableにして保存すれば適用が開始されます。


◆旧ポリシーを無効化し、動作確認を行う

ここで重要な注意点です。
新ポータルからは旧ポータルで作成したポリシーを無効にすることしかできません。失敗しても再度有効化しようとすると旧ポータルへアクセスして有効化しないといけません。
つまり、12月1日以降に新ポータルで無効化した旧ポリシーは二度と有効化することが出来ない、ということなのでリカバリーが出来る状態での動作確認は11月30日までしか出来ない、ということです。

しっかり計画を立てておきましょう。

新ポータルから旧ポリシーを無効化するには、先ほどのメニューより旧ポータルを選び、Disableをクリックするだけです。


後は動作確認として、適用条件に合致した・合致しない状態でアプリケーションへアクセスし、望んだ状態になるかどうか確認してください。


ということで、管理者の皆さんは急いでテスト~移行しておきましょう。