ピクセラでは各アプリケーションのユーザー認証処理に、Microsoft Azure ActiveDirectory (以下AAD) のうち AAD B2C を導入しています。また、一部のサービスにて Amazon Alexa Skills Kit を提供し、Echo dot を使った声による操作が出来るようになっています。
Conte™ホームサービス Amazon Alexaでの使い方 | 株式会社ピクセラ
今回、このAmazon-Microsoftのクラウド連携部分での不具合により、長期に渡り接続できなくなってしまった反省をこめて、
- 問題顛末
- AlexaSkillsとAADB2Cの連携手法
を書いていこうかと思います。今回は前編・問題顛末です。
Alexa スキルの仕様
Amazon Alexa スキルの設定方法はAmazonのドキュメントに委ねるとして、外部OpenIDConnectサービスへのリンク設定の際、AlexaSkill側のredirect URLは３種類の可能性があるようです。
- https://layla.amazon.com/api/skill/link/…
- https://alexa.amazon.co.jp/api/skill/link/…
- https://pitangui.amazon.com/api/skill/link/…
参考:Alexaユーザーとシステムユーザーの関連付け#URL値をリダイレクトする
日本に限っては、今のところ https://alexa.amazon.co.jp/api/… で始まるURLしか利用されていないようですが、Amazonからは「１つしか使わないとは言い切れない」という回答をもらっているため、３種のredirect先（元？）を容認できるOAuthサーバー設定が必要です。
不具合の顛末
AAD / AAD B2C（2017年当時）
弊社にてAAD B2Cでユーザー管理を推進していく事となり、他プロジェクトでは問題なく進めていましたが、ことAlexa スキルとの接続で、
「リダイレクト URI はすべて、同じドメインに属している必要」
がある、というAAD B2C仕様が立ちはだかります。
※主ドメインが同じであれば、サブドメインがパスが違っていても問題ない
AAD側でもOAuth2.0の認証機構があって、こちらのApplication設定ではユーザー管理との接続が可能で、かつリダイレクトURIは複数指定が可能でした。これなら出来る！と、当然Microsoftサポートに色々お伺いをたてつつ、連携設定が完成し、音声コマンド連動サービスが開始しました。
数週間前
別プロジェクトでもAlexaスキルを使っていこう、となり、その時点でもほぼ当時と同じ設定で連携が出来ました。タラレバですが、この「ほぼ当時と同じ」≠完全一致ではなかった事で気づけたのかもしれません。
その数日後
この別プロジェクトの作業を続けようとしたとき、Alexaとの連動ができなくなっていました。昨年に設定したスキルも同様です。Ops体制がいまいちだったこともあって、ここから問題修正完了までに時間がかかってしまいます。
MSには問い合わせを入れていましたが、そもそもAADのApplication設定からAAD B2Cにアクセス出来ていたのが（おそらくMSのセキュリティ強化かバグfixにより）いつの間にか完全にできなくなっていました。
問題
不具合発覚当時は数日あれば十分、と考えていましたが、複数の問題が絡まってしまっていて、解決までに膨大な時間がかかってしまいました。
- OpenIDConnect周辺の理解不足
- 昨年の作業履歴が取っ散らかったままで、今回の状況整理に時間がかかった
- AADアプリからAADB2Cにアクセス出来ていた
- 昨年当時は指摘がなかった
- MSからの指摘なかったとはいえ、動作ベースでgoしてしまった
- Azure側のAuthorizationCode取得／Token取得のパラメータ指定仕様がかなり変わった
- パラメータ指定先が変わる
- scopeにいくつか追加する必要がある
- ヘッダではなくbody側に client_secret を入れる
- Azureポータルサイトから取得できる内容・情報はAzureの一部であり、公式ドキュメントサイトにのみ書かれている内容もある
例えば、Azureポータル中のAAD B2Cブレードで取得できるエンドポイントURLでは、Chromeからのアクセスが高確率で失敗します（400 Bad Requestだったり、414 Request URI too long など）。これのエイリアスのようなURLがあって、こちらでは問題発生しにくいようですが、Azureポータル上には記載がなく、公式ドキュメント（の設定例等）にしか書かれていません。
ざっくりまとめてしまうと、（Microsoftによる）クラウドサービス仕様の不具合改善が、隙を突いたような運用になっていた弊社設定を「正しく」否定した、というのが凡その見解です。
クラウド不具合修正内容は事細かにアナウンスされないため、発見が遅れたこともありますが、今回については仕様や情報を詳細に理解できていれば防ぐことが出来た部分も多々あります。結局は、Opsチームを正しく編成したのち、最新状況を監視し続けるべし、という事ですね。