#
Windows Azure Advent Calendar 向けポストです。
Windows Azure Active Directory（WAAD）のアプリケーション統合の機能を使うと Google Apps や Salesforce.com などの各種 SaaS アプリケーションへのシングルサインオンやプロビジョニングを WAAD 経由で実施することができます。いわゆる、IdMaaS（Identity Management as a Service）というやつです。
WAAD のアプリケーション・パネル（
https://myapps.microsoft.com）
今回はこの機能をうまく使って、企業などの組織が行ってきた各種サービスへの個別の ID 管理やシングルサインオン環境構築をどこまで省力化できるか、を検証してみたいと思います。
前提となる環境、利用する機能は以下です。
- WAAD のアプリケーション統合機能
- 先日発表された WAAD Premium の機能である、アプリケーションへのグループの割り当て機能（現在プレビュー）
- 社内の ID 情報ソースと WAAD のアカウントおよびグループ同期（ディレクトリ同期ツールや Forefront Identity Manager/FIM の WAAD コネクタなど）もしくは WAAD Graph API によるアカウント・グループ管理（今回は Graph API を利用）
では早速始めます。
◆IdM をオンプレミスで構築する（おさらい）
例えば、Google Apps や Salesforce.com などのクラウド・サービスの ID を社内から管理したいと考えた場合、FIM をはじめとする ID 管理製品の各種サービスとのコネクタを構築（もしくは購入）して、それぞれのサービスと接続して ID 情報を同期する必要がありました。
参考）FIM2010 用の GoogleApps コネクタ
https://fim2010gapps.codeplex.com/
◆IdMaaS の登場
各種 SaaS サービスと個別に接続する、というアプローチは非常に柔軟ですが、一方で各サービスのインターフェイスや API の変更へ追従していくのが非常に大変、、という側面を持ちます。
そこで、各種 SaaS サービスとの接続自体をクラウド・サービスとして提供しよう、という考え方である、Identity Management as a Service（IdMaaS）という考え方が登場し、Microsoft の Windows Azure をはじめ、PingIdentity の PingOne や Salesforce の Salesdorce Identity や Intel/McAfee の Intel Cloud SSO など各種サービス業者がサービスを展開し始めています。
参考）これまで紹介してきたエントリ
Windows Azure Active Directory（
http://www.windowsazure.com）
[WAAD] IDaaS としての機能が充実してきた
http://idmlab.eidentity.jp/2013/07/waad-idaas.html
PingOne（
https://www.pingone.com/）
[IDaaS]PingIdentity Cloud Desktop で便利ライフ
http://idmlab.eidentity.jp/2013/10/idaaspingidentity-cloud-desktop.html
Intel Cloud SSO（
http://www.intelcloudsso.com）
[IDaaS] Intel Cloud SSO を試してみた
http://idmlab.eidentity.jp/2012/05/idaas-intel-cloud-sso.html
◆IdMaaS で ID 管理を楽にする
WAAD をはじめ、各種 IdMaaS サービスには各種 SaaS サービスへのプロビジョニング機能があるため、こんなことが成立します。
これであれば、社内の ID 管理システムは IdMaaS とさえ接続しておけば、あとは IdMaaS 側でインターフェイスの保証などをしてくれるので、社内の ID 管理システムを個別に各システムと接続する必要も、各サービスのインターフェイスや API の更改に神経をとがらせる必要もありません。
◆IdMaaS の運用をどこまで自動化できるのか
ここまでで勘の良い方ならお分かりだと思いますが、IdMaaS への ID 同期とその先の各種サービスへのプロビジョニングをどこまで細かく制御できるのか？という課題が出てきます。
一般的な ID 管理システムではここでいう IdMaaS への接続と同期はコントロールできても、その先のコントロールについては IdMaaS 側にお任せ、ということになるはずです。
となるとオンプレミスの ID 管理システムや運用システムから IdMaaS の管理をどこまで自動化できるかがポイントになってきます。
◆WAAD の場合。Graph API の活用？
WAAD の場合は個人 ID などのディレクトリ上のオブジェクトの操作をプログラムから行うための API として Graph API を提供しています。
参考）[Office 365 & WAAD] Graph API を利用したアイデンティティ管理
http://idmlab.eidentity.jp/2012/12/office-365-waad-graph-api.html
※ちょうど一年前の Advent Calendar 向けの記事
例えば、特定のユーザに Google Apps など WAAD と統合されたアプリケーションを使わせたい、と考えた場合はこの Graph API で、対象ユーザへアプリケーション割り当てを行うことができれば、オンプレミスの ID 管理ツールから WAAD およびその先にあるサービスへのプロビジョニングまでをコントロールすることが出来そうです。
先月新バージョンがリリースされた Graph API の機能の概要を metadata エンドポイントを探索することで確認してみます。
2013/11/08 版 API）
http://blogs.msdn.com/b/aadgraphteam/archive/2013/11/14/announcing-the-new-version-of-the-graph-api-api-version-2013-11-08.aspx
要するに WAAD と統合したアプリケーションに Graph API からアクセスできれば良いので、アプリケーションに関するどんな操作が可能かを調べてみます。
アクセストークンを WAAD の OAuth2.0 の Token エンドポイントから取得して Authorization ヘッダにセットした状態で、Graph API の metadata にアクセスしてみます。
metadata の確認は以下の URL へ GET します。
https://graph.windows.net/<テナントドメイン名>/#metadata?api-version=2013-11-08
すると、以下の答えが返ってきます。
{
"name" : <テナントドメイン名>",
"services" : [
"https://graph.windows.net/<テナントドメイン名>/users",
"https://graph.windows.net/<テナントドメイン名>/applications",
"https://graph.windows.net/<テナントドメイン名>/contacts",
"https://graph.windows.net/<テナントドメイン名>/groups",
"https://graph.windows.net/<テナントドメイン名>/roles",
"https://graph.windows.net/<テナントドメイン名>/servicePrincipals",
"https://graph.windows.net/<テナントドメイン名>/tenantDetails",
"https://graph.windows.net/<テナントドメイン名>/devices",
"https://graph.windows.net/<テナントドメイン名>/subscribedSkus",
"https://graph.windows.net/<テナントドメイン名>/permissions",
"https://graph.windows.net/<テナントドメイン名>/directoryObjects"
]
}
Windows Server 2012 R2 から実装された Device Registration Service（DRS）に関するエンドポイントも存在しています。いよいよ WAAD 側でも DRS が実装されるようです。
今回はアプリケーション統合関係なので /appication というエンドポイントを見てみます。
まずは一覧を GET してみます。
https://graph.windows.net/<テナントドメイン名>/applications?api-version=2013-11-08
を GET すると、WAAD に統合したアプリケーションに関する情報が JSON 形式で出てきます。
が、ここで表示・管理できるのは、組織で開発中のアプリケーション、つまり Google Apps や Salesforce.com などの SaaS アプリケーション以外の自作アプリケーションや API に関してのみの様です。
これでは、特定のユーザを WAAD を経由して Google Apps を使わせる、ということが出来ません。
◆WAAD Premium のグループ管理機能の登場
Graph API で個別のユーザに直接 SaaS アプリケーションを割り当てることは難しそうです。
そこで登場するのが、現在プレビュー公開されている WAAD Premium の機能である、SaaS アプリケーションの割り当てを個人単位ではなく、グループ単位で実施する機能です。
これであれば、グループへのメンバ登録は Graph API で実行できるので、あらかじめ特定のグループを SaaS アプリケーションへ割り当てておけば、結果的にユーザに対してアプリケーションを割り当てることが出来そうです。
まずは、グループを作成し、アプリケーションへグループを割り当てます。
すると、グループメンバになっているユーザにアプリケーションが自動的に割り当てられます。（継承としてアサインされる）
どうやらうまくいきました。
Google Apps 上にもユーザが作成されています。
注１）現在の仕様では WAAD から Google Apps 上に新規作成されたユーザは「停止済み」状態になっているので、個別に有効化する必要があります）
注２）現状、グループ単位でのアプリケーション割り当ては Salesforce では使えません。
◆再度自動化にチャレンジ
ここまで管理画面から実行した操作を Graph API で自動化できればオンプレミスの ID 管理システムから WAAD を経由して SaaS アプリケーションを使える状態にする、というところまで持っていけそうです。
ここは実は非常に簡単で、対象のグループの URI に対してメンバとして参加させたいユーザの URI をリンクする、という操作で実現できます。
エンドポイント：https://graph.windows.net/<テナントドメイン名>/groups/<グループのオブジェクトID>/$links/members?api-version=2013-11-08
メソッド：POST
ボディ：
{
"url":"https://graph.windows.net/<テナントドメイン名>/users/<ユーザのオブジェクトID>"
}
これで、先ほど手動で実施したユーザのグループへの追加（結果としてアプリケーションへの割り当て）が自動化できました。
グループへの追加の条件をオンプレミスの ID 管理ツールで調整してやれば、割り当て後のユーザの状態など少々課題は残りますが、かなり柔軟にアプリケーションへのアクセス制御が実現できそうです。
いかがでしょうか？
IdMaaS というと全面的にアイデンティティ情報をクラウドに預けてクラウド上でのみ ID 管理をする、というイメージがあるかもしれませんが、このようにうまくオンプレミスと連携することで、効率の良い環境構築が出来る可能性がある、と言うことが出来ますので、今後 SaaS アプリケーションを企業内から活用する、というシーンを想定する場合はこのようなハイブリッド ID 管理シナリオも検討してみる価値はあるかも知れません。
