2020年5月20日水曜日

Build速報!FacebookでAzure ADへログインする

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

Buildですね。リモート開催になって日本からでも参加しやすくなって睡眠時間が削られる日々をお過ごしだと思います。

今回も色々とAzure ADに関する新機能の発表がありました。

詳しくはAlexのBlogを参照してもらえれば良いのですが、今回はAzure AD B2Bの直接フェデレーションへのFacebookログインの登場(Public Preview)の話です。

AlexのBlog)
https://techcommunity.microsoft.com/t5/azure-active-directory-identity/build-2020-fostering-a-secure-and-trustworthy-app-ecosystem-for/ba-p/1257360

Azure AD B2Bの直接フェデレーションについてはこれまでも取り上げてきましたが、Googleに対応してから約2年、ここに来てFacebookに対応しました。

Googleとの連携の件
https://idmlab.eidentity.jp/2018/08/azure-ad-b2bgoogleid.html

カスタムドメイン vs 直接フェデレーションの件
https://idmlab.eidentity.jp/2020/05/azure-adbyoid.html



もはやB2Bとは?というしかない状態なのですが、早速触ってみましょう。

外部アイデンティティプロバイダの設定

これまでも紹介したことのある画面です。Azure ADのポータルを開き、External Identitiesメニューから「すべてのIDプロバイダー」を開くと「Google」に加えて新たに「Facebook」が選べるようになっています。


ここでFacebookを追加して、AppIdとAppSecretを追加すれば基本は終わりなのですが、設定前に外部ユーザによるサインアップを許可しておく必要があります。
「外部コラボレーションの設定」メニューを見ると、新しく「ユーザーフローによるゲストセルフサービスサインアップを有効にする」という設定が追加されているので有効にしておきましょう。

後はFacebook Developerコンソールで作成したアプリケーションのAppIdとAppSecretを設定すれば終わりです。

Facebook側の設定方法はAzure AD B2Cのドキュメントに記載がありますので、1点を除いてこちらをそのまま使って大丈夫です。
https://docs.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-facebook

その1点とは、そうですredirect_uriです。
直接フェデレーションの場合にFacebookに設定するredirect_uriはどうなるのか?というと、
https://login.microsoftonline.com/te/{テナントID}/oauth2/authresp
となります。

ここまで設定を進めると、ユーザーフローからAzure ADにアクセスするためのアプリケーション「aad-extensions-app」が自動的に登録されます。


ちなみに、このアプリケーションを削除すると面倒なことになるので、消さないようにしてください。
万一消してしまったらAzure AD B2Cでのb2c-extension-appと同じように回復をしてください。
参考)B2Cでの回復手順
https://docs.microsoft.com/ja-jp/azure/active-directory-b2c/extensions-app


ユーザーフローの登録

外部IDプロバイダの設定が終わったら、次はユーザーフローの登録です。
基本この辺りもAzure AD B2Cと同じです。


ユーザーフローの名称(ポリシー名となります)、利用するIDプロバイダ、連携する属性を設定していきます。
尚、属性は標準で用意されているもの以外に「カスタムのユーザー属性」メニューから自分で好きな属性を追加することもできます。

これでIDプロバイダとユーザーフローの登録はおしまいです。

アプリケーションの登録

次に、先ほど作成したユーザーフローを使ってサインアップやサインインを行う対象となるアプリケーションを登録します。
ポイントは、APIのアクセス許可で「User.Read」スコープに対して管理者による同意をしておくこと、です。現状のユーザーフローでのユーザ作成やログイン時にユーザ自身による同意が上手く取れない?のでこの設定は入れておく必要がありそうです。

ユーザーフローとアプリケーションの紐づけ

アプリケーションを作成したら、先に作成しておいたユーザーフローを使う様に構成をします。
先ほどのExternal Identitiesメニューに戻り、先ほど作成したユーザーフローを開きます。アプリケーションに関する設定項目がありますので、ここで作成したアプリケーションを指定します。

これで一通りの設定は終了です。

動作確認

では早速動かしてみます。

このアプリケーションにアクセスする為には、以下のパラメータをつけてAuthorizationエンドポイント(https://login.microsoftonline.com/{テナントID}/oauth2/authorize)へアクセスする必要があります。(通常のOpenID Connectのアプリケーションと同じです)

  • client_id={登録したアプリのClient Id}
  • response_type=id_token
  • scope=openid
  • nonce={生成したnonceの値。テストなら何でもOK}
  • redirect_uri={登録したアプリのredirect_url}

今回、アプリケーションとしてはhttps://jwt.msを使ったのでこんなURLになります。
https://login.microsoftonline.com/{テナントID}/oauth2/authorize?client_id={クライアントID}&response_type=id_token&scope=openid&nonce=hoge&redirect_uri=https:%2F%2Fjwt.ms

実行してみると、いつものサインイン画面になるので、まずはアカウントを作成します。

アカウントの作成画面に「Facebookアカウントでサインイン」というメニューが出来ています。
ここでFacebookアカウントでサインインすると、Azure ADへのアカウント登録を行う際に追加で登録するアカウントを入力する画面が出てきます。

続行するとアカウントがAzure AD上に登録されます。
アカウントタイプはゲスト、ソースはFacebookになっているのがわかります。


ちなみに登録後、サインインする場合はサインインオプションをクリックするとFacebookログインのメニューが出ていますので、そちらを使ってサインインします。


いかがでしょうか?
基本はAzure AD B2Cの機能の一部を通常のAzure ADの直接フェデレーション向けに開放しただけなので、Azure AD B2Cに慣れている方は直感的に理解できると思います。

しかし、冒頭にも書きましたが、こうなってくると「B2Bとは?」という疑問がやはり出てきますが大人しくしておきましょう。

おまけ

たまたまテストに使ったAzure ADにG-SuiteとのSSO設定があったので、SAMLの属性マッピングの調整をちょこっとして、GmailにAzure ADの直接フェデレーションを使ってFacebookアカウントでログインする、というくだらないものを作ってみたので動画を貼っておきます。

0 件のコメント:

コメントを投稿