PHP Advent Calendar 2020 にちなんで
12月といえば、Advent Calendar。
最近、シュールストレミング・・もとい、子どもに、シュトレンのなれそめなどを説明しておこうと、Wikipediaを引くなどしつつ、シュトレンを買いました。。（そもそも、自分が知らないことをWikipediaの情報を引いて説明するというのもシュールですが。）
ドイツでは（ご存じの通り！）シュトレンをクリスマスを待つ４週間の待機節に少しずつスライスして食べる習慣がある。
待機節そう、これがAdvent期間というわけです。
技術情報といえば、最近はもっぱらqiitaで、qiitaでのAdvent Calendar、今日はPHPの方を見てみます。
やっぱり、ここはPHP8ネタに期待が集まります。
あれ？ん？PHP12 ！？
「PHP 8にPHP 4の魂を吹き込んでPHP 12にする方法」
その昔、サービスのリリーススケジュールとPHP5のリリースタイミングが近く、PHP5を前提とするフレームワークにPHP4ベースのアプリケーションを移植するという折に、create_function()やeval()を多用したことがありました。高負荷にさらされてサーバー増設に追われたよき思い出ではあるのですが、今だったらもっと捌けるシステムを書けていたかもしれません。なにも、create_function()を使わなくても解決できたと思うのですが、若気の至りというものでしょうか。
《そういえば、個人的にはPHP6が好きなので、PHP6を並列してPHP12にする方法をトライしてみようか・・・｠
そして、PHP Advent Calendarその２もあります。
ざーっと読みながら、これを書いてる私もそうですが、PHPからしばらく離れていたとか、昔のことを思い出して・・・なんていう、昔語りが増えてきた感がありますね。
Azure AD B2Cを始める(4) - 次のステップへ
Azure AD B2Cの公式ドキュメントに従って、チュートリアルを実行し、だいたいどのようなことができるのかがわかり、そのための手間がほとんどないことが確認できました。
次のステップは、具体的に、どのような用途で使っていくかでサンプルなどを探っていくことになるかと思います。
- 単一ページのアプリ (SPA)
- Web アプリ
- モバイル アプリ (Android、iOS、Xamarin、UWP)
- デスクトップ アプリ (Win、Linux、Mac)
- Web API
- デーモン (バックグラウンド プロセスまたはオートメーション)
以上のようなシナリオが考えられると思いますが、それぞれにサンプルなどが充実しています。
Microsoftのプロダクトですので、Webアプリなど 、ASP.NETは充実しているのですが、PHP、Java、Railsを使いたいんだというケースでは古いサンプルなどから類推的に実装していく必要があるかもしれません。もっとも、プロダクションに入れるときは結局のところ少なからず生じるタスクですので、サンプルレベルでの充実度という意味ではありますが。
実運用と統合チェック
チュートリアルなど、Azure Portalの機能が充実しているので言われるままに設定するのは容易なのですが、いざ、プロダクションに入れるときに、「技術仕様上のあの設定は、どこでやるんだろう？」ってなるとき、ありますよね。コマンドであればリファレンスを引けばいいわけですが、Azure Portalでは、これがあります。
「アプリの登録」ブレードにある、「統合アシスタント」です。
これで、それぞれのシナリオに応じて、網羅的に設定すべき内容のうち、どの設定が不足しているかなどを順次チェックし進捗に応じて作業を進めることができます。
これは便利ですし、こういう便利機能まで配慮する時間ができているということは、Azure AD B2Cへの開発リソースが充実していることが想像できます。
たとえば、非推奨の構成に、「承認コード フローを使用している場合は、暗黙的な許可設定を無効にします。」といった、非推奨の構成がされている場合の注意喚起など、ありがたいです。
これで、それぞれのシナリオ毎に安心して探索を進められそうです。
Azure AD B2Cを始める(3) - ベストプラクティス
チュートリアルは、公式ドキュメント通りに進めれば、現状では問題ないでしょう。
たまに、ドキュメントが古くなったり新機能が追加されて使えない部分もでるかもしれませんが、今日現在ではうまく動作しましたので、今日現在は！メンテされていると言えそうです。
私もそうですが、過去のB2Cを使っていたユーザーにとってはいくつかの変更点、改良点があるので、その辺もおさらいしておくとよいかもしれません。
ベストプラクティス
公式ドキュメントにベストプラクティスについてのまとめがあります。
特に、基礎と計画と設計は重要なことが書かれているので、他のライブラリと比較する、自前の開発と比較するときには肝になるかもしれません。
気になるところをピックアップしますと、
- ５万ユーザーまで無料
- エンドポイントが、b2clogin.com
- Visual Studio Code 用 Azure AD B2C 拡張機能
- テスト関係
といったところでしょうか。
料金はやはり気になりますね。今のところ私の顧客では４万ユーザーがMAXなので料金はかからなそうです。
エンドポイントが以前のMicrosoftアカウントと共通のものから替わり、これは何がいいかというと、過去のバージョンでも、テスト用アカウントで何度もサインイン、サインアウトを繰り返したり、複数の認証を行っているとクッキーが肥大化して接続できなくなるという問題がありました。
まぁ、通常の使用では問題ないはずなのですが、顧客によってはユーザーの追加を一斉に同じＰＣでなどということが行われて、クッキーの削除を依頼する必要がありました。
これが解決されたようなので、何よりです。
また、管理機能としてポリシーの管理がVisual Studio Codeでできるのはありがたいです。SharePointなどでは、Visual Studioの古いバージョンを要求された時期もありましたので、VS Codeで有志の方が拡張機能を出してくださっているというのは助かります。
Azure AD B2Cを始める(2) - Azure Portalでの設定など
私は、仕事でOffice365関係の管理なども請けているので（長く苦労してるので）わかるのですが、そもそも、Azure AD B2Cを始めるのにあたっては、Azureの管理について慣れなければなりません。
Azure PortalとMicrosoftの構成
この最初のAzure Portalが意外とくせものなのです。
慣れてしまえばどうということはないですし、以前のAzure Portalよりもできることは増えているのですが、いかんせん、動作がもっさりしていて、行きたいところにすぐに行けない。
そしてまず、Azureで管理する基本として
の関係を理解する必要があります。そして、Azure AD B2Cを理解するのにあたっては、もう少し踏み込む必要があります。
私の理解とMSの説明の相違点など
Office365を会社などで契約すると、そのドメインまたは付与されたサブドメインなどでテナントが作成され、Azure上の課金単位毎にサブスクリプションが作成されます。
ディレクトリはテナントに存在してID管理の一単位を構成するものと理解していました。
そして、管理者は、テナントの全体管理者になったり、サブスクリプションと結びついたりといった形になります。一人の管理者が複数のディレクトリやテナントを管理することもできます。
さて、Azure AD B2Cを始めるには、新しくテナントを作ってもよいのですが、多くの場合、既存のテナントで行いたいですよね。ところが、通常、一つのテナントには既にAzure AD（B2Cではない）が存在していることが多いです。
なぜなら、Azure AD B2Cを始めるには、Azure Portalのテナントから始めるからです。
つまり、親になるテナントから、新しいB2C専用のテナントを作成し、既存のサブスクリプションとリンクさせるというフローになるわけです。
ところで、Azure Active Directoryというのは、私はいわば、Azureのテナントと一対をなすものというぐらいのイメージで、Azureの認証のコアだと思っていたのですが、Azureのサポート様の説明によるとそうではなく、むしろ「Azure Active Directoryを管理しているのはOffice365なんです」、とのことでした。
つまり、極論、Azure AD ⊂ Office365ということらしいです。
たしかに、Azure Portalで見れば、ポータルの中にAzure Active Directoryは存在しているのですから、なるほどと言わなければなりません。しかし、Azure Active Directoryなしのテナントって可能なのか、可能として何に使うのか・・・気にするところではないのですが。
しかし、同時に理解できることは、一つのテナントにAzure ADとAzure AD B2Cは共存しない、つまり、独立したテナントを作りつつ、サブスクリプションはリンクできるということです。
Azure Portal もしくはコマンドラインなど
Azure PortalのWebUIで多くのことができます。
MS系の方はご存じとは思いますが、WebUIでは迷子になってしまう場合もありますし、業務の引継ぎなどを考慮すると、Azure PowerShellでの作業が向いている場合もあります。
また、自動化するなら、Microsoft Graphで設計しておく方がなにかと便利かもしれません。
私は、再勉強ということで公式ドキュメントを見てWebUIでぼちぼちやっていきます。
Azure AD B2Cを始める(1) - 公式ドキュメント、qiita記事など
最新の技術情報の機微を知りたい場合、以前ですと、Twitterでつながり、旧はてなダイアリーやはてなブックマークをつたって情報をシェアすることが多かったですが、最近はもっぱらqiitaから入るのがよさそうですね。
ライブラリを探るのにあたっては、
- 公式ドキュメント
- qiita検索
- google検索
こんな順で調べています。
公式ドキュメント
概要を見て、クイックスタートを流し読み、チュートリアルに着手という流れでしょうか。
この公式ドキュメントを数時間読んで何ができるかがわかるようでないと、公式ドキュメントとしては寂しいですよね。
私の場合は、初期のAzure AD B2Cで概要はつかんでいるので、最新情報のキャッチアップする方向で検討します。
（当時は、IEとの共存時代で、マイクロソフトが提供しているadal.jsでは同じMSのedgeで不具合があるという困りものでしたが、現行のmsal.jsではどうなんでしょうか・・・）
qiitaで気になる記事を調べる
記事検索から入る方法とタグから見ていく方法とがありますが、私は検索から見ます。タグは付け忘れなどあったりしますので。
なるほど。なるほど。
私が扱っていたころと大きく変わってはいない感じがします。
最新の環境でうまくいかなかったというレポートには本当に助けられますね。
この記事にもあるのですが、Azure Portalは要注意でちょくよくUIが変わって、そのたびに過去にできていたことができなくなったり、ということがあります。
もっとも、そういう改善にともなう副作用を容認できないとよりよい環境にはなっていかないので、必要なコストですが、このコストを軽減できるというのはうれしいです。
Azure AD B2Cのタグを見てみます。
少し情報不足感がありますが、最新記事を広いやすいので、ありがたいですね。
Azure ADのタグを見てみましょうか。
（Azure ADとAzure AD B2Cは似て非なるものですが、共通する要素は多いです）
気になる記事も多くありますが、深読みしていると夜が明けてしまいますので、備忘的に流し読みしておきます。
Auth0か、Azure AD B2Cか。
経験上、私はライブラリやフレームワークの選択に自信を持てません。
私がライブラリ等を選択するのにあたっては、そのライブラリの品質のみならず、どのような人たちがメンテしているかなど、かなり慎重に検討して選択してきているつもりなのですが、残念ながら私が選択したライブラリ等で廃れたものは多くあります。
それでも、選択しなければなりません。
どんなWebアプリケーションでも認証、承認は必要でしょう。
- 既存のWebアプリケーションに含まれている機能を利用する
- 第３者が提供しているサービスを利用する
- 自前で開発する
いろいろと選択はありますが、既存のWebアプリケーションに含まれている認証機能では不足する可能性が高いので、ここでは、第３者が提供するサービスを利用するプラグリン等を開発して、既存のWebアプリケーションと連携することを念頭に検討したいと思っています。
サービスとして提供されている認証サービスとしては、Auth0、Amazon Cognito、Azure AD B2Cが思いうかびます。
私が想定しているアプリケーションのユーザーは、日常業務でOffice365を使用しています。
Azure AD B2Cを用いると、クライアント用に各種SSOを活用しつつ、内部用にはAzure AD上のID(Office365アカウント)を使用することが可能です。
そして、同様のことはAuth0でもできるはずです。
つまり、できることに大差はなく、現状では、使ってみないとどちらがいいのかわからないというのが、私の答えです。
Web 認証、承認用ライブラリ
むかーしむかし、あるところに
ざっとWebアプリの１０年を振り返るとき、根本的に変わった点を探ると、私は第一にブラウザーの変化であると思っています。
ブラウザーというべきか、ブラウズする環境というべきか・・・
I.E.対応に苦しめられる時代は終わった。
これが実に大きいように思います。
（当時はまだガラケーを持つ人も多くいたので、ガラケー対応のために何機種も手元においてテストする・・・そんな時代でもありましたが。）
相変わらずPC用モニタの多くは横長であるけれども、誰もがスマホを持つ時代になった現在、スマホ用としては縦長の画面として設計することになる。
そして、Webアプリ側で頑張る！という流れから、JS、CSS実装の標準化や画面設計に適したライブラリが増えて、画面設計は以前よりも本質的な部分にアプローチできるようになってきたと思います。
（まぁ、現在に生きている人には当たり前の話過ぎますが。）
サーバー、クライアントはそれぞれがやるべきことに専心できる時代に
ライブラリを開発し、公開してくださっている皆様には本当に頭が下がります。
現在のWebアプリの設計は、サーバーはサービス側の責務、責任に専心し、クライアントアプリが顧客向けのツールとして動作する、本当にシンプルな流れになってきたと思います。かつては、クライアント向けの動作をすべてサーバー側が状態を管理しようとするため、サーバーの実装上の負担は多く、また脆弱性の原因にもなりがちでした。畢竟、Webフレームワークが、サーバー上ですべてをまかなえるシステムを目指し、鈍重なものになってしまう恐れがありました。
(当時においても、そういった問題をキレイに解決しうるよきライブラリもあったことを記憶していますが、ここでは触れません)
サーバー、クライアントの分離と連携
サーバーとクライアントの役割を分離するなら、簡単にいえば、
- サーバー＝データの作成、取得、更新、削除を提供するAPI
- クライアント= ブラウザで動作するアプリケーション
この分離ですね。
クライアント上で動作する画面やアプリケーションプログラムをどこから取得するか、は、インストールする形か、オンデマンドにどこかのサーバーから取得するなどありますが、それも、分離して別の関心事としましょうか。
（恐ろしいことに、かつては、これらすべてサーバー側のプログラムが管理していたのです！）
さて、本題ですが、いかに役目を分けたとしても、一つの目的を達するためには「連携」は必要です。その連携を、ローカルな仕様や技術標準に則った規約などで整備するか、とにかく連携できるようにすることが重要です。
OAuthやRESTはそういった設計を容易にしてくれると思っています。
サーバー、クライアントに共通する認証、承認
認証や承認は、サーバー、クライアントに共通する関心事かと思います。
黎明期のWebアプリでは、フォームにユーザーとセッションを結びつけるハッシュを仕込んでおき、ハッシュ毎に処理をする、とか、ミドルウエアが持つセッション情報などを通じて、クライアントの状態をサーバー側で管理するのが常道でしたが、複雑かつ脆弱でした。
パスワード認証の終わり
パスワードを使用した認証が脆弱であることが知られており、W3Cは、パスワード認証を非推奨とし、WebAuthnをWeb標準とすることが公開されています。
W3CとFIDO Alliance - パスワード不要の安全なログインが勧告化に
Fido2?
WebAuthnがWeb標準はもちろんよいのですが、独自にFido2を実装するのが合理的でしょうか。
SSO連携
SSOの技術的には無論１０年前にもありましたが、まだまだ主流とは言えない感がありました。
しかし、現状ではWebアプリ認証の合理的な解決方法としては、たとえば、Windows10はWebAuthnに対応しており、Microsoftは個人用のマイクロソフトアカウントまたは、Office365(Microsoft 365)のアカウントによる認証を使用しています。
また、Googleアカウントでの認証を多用している人なども多いでしょう。
これら、WebAuthnに対応しているアカウント情報と連携してSSOしていく構成が、現状での認証・承認としては、経済的に合理的かつ安全なのではないでしょうか。
SSO連携は、サーバー、クライアントの分離とも相性がよいです。クライアントはクライアント上で認証をへて承認を取得し、サーバー側は適切なトークンを持ったアクセスであるかを独自に検証すればよいので、サーバー上での考慮事項はシンプルです。
このブログの近々の課題としては、まずはMicrosoftのAzure AD B2Cを中心に検討していきたいと思います。
認証サービスで最も有名なものの一つはAuth0かと思いますので、こちらも確認していきたいと思います。
