引き続き、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上のユーザの属性を更新する、などの処理ですね。
今回はこのくらいです。
プロビジョニングは結構鬼門なので、使う場合は十分に事前調査～準備をしてから使い始めるようにしてください。
投稿
