こんにちは、富士榮です。
毎年恒例のAdvent Calendarの季節になってきましたね。（はやい・・・）
ということでDigital Identity技術勉強会（#iddance）のAdvent Calendarも作られていますので、この機会にぜひ皆さん参加しましょう。
https://qiita.com/advent-calendar/2024/iddance
2024年11月4日月曜日
今年もDigital Identity技術勉強会のAdvent Calendarの季節がやってきた
ということでDigital Identity技術勉強会（#iddance）のAdvent Calendarも作られていますので、この機会にぜひ皆さん参加しましょう。
2013年12月10日火曜日
[WAAD/IDMaaS]SaaSアプリケーションのID管理をクラウドで行う「ハイブリッド ID 管理」
# 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 管理やシングルサインオン環境構築をどこまで省力化できるか、を検証してみたいと思います。
前提となる環境、利用する機能は以下です。
では早速始めます。
◆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 管理シナリオも検討してみる価値はあるかも知れません。
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 管理シナリオも検討してみる価値はあるかも知れません。
2013年12月7日土曜日
[WAAD]アップデートラッシュ
最近、Windows Azure Active Directory（WAAD） 周りの機能がどんどんアップデートされています。
例えば、
・アプリケーションアクセス機能の正式リリース
・Graph API のバージョンアップ
・WAAD Premium のプレビュー版のリリース
など、楽しい？機能がたくさん登場してきています。
ちょうど今月は昨年に引き続き Windows Azure Advent Calendar に参加する予定なので、徐々にネタ探しをしているのですが、今回はウォーミングアップということで軽く小ネタを。
先にあげたアップデートのうち、アプリケーションアクセス機能については、以前のポストでも紹介しましたが、2つほど小ネタを紹介します。
一つ目は、アプリケーションパネルへのアクセス URL です。
前回のポストでは以下のような長い URL を紹介していました。
https://account.activedirectory.windowsazure.com/applications
しかし、結構長いのでエンドユーザに展開するのが面倒、という方には以下の短い URL を使ってもアクセスできるのでこちらがおススメです。
https://myapps.microsoft.com
次に、利用者がアプリケーションパネルを使っている最中に管理者が新しいアプリケーションを割り当てたらどうなるのか？という話です。
ログアウト～再ログインするまでアプリケーションが使えないのか、単純にページをリロードすれば使えるようになるのか？？？
答えは単純にリロードすれば OK です。
この状態で、、、
管理者がアプリケーションにユーザを割り当てると、、、
ページをリロードすると新しいアプリケーションが表示されます。
それだけです。
ほんとに小ネタでした。
例えば、
・アプリケーションアクセス機能の正式リリース
・Graph API のバージョンアップ
・WAAD Premium のプレビュー版のリリース
など、楽しい？機能がたくさん登場してきています。
ちょうど今月は昨年に引き続き Windows Azure Advent Calendar に参加する予定なので、徐々にネタ探しをしているのですが、今回はウォーミングアップということで軽く小ネタを。
先にあげたアップデートのうち、アプリケーションアクセス機能については、以前のポストでも紹介しましたが、2つほど小ネタを紹介します。
一つ目は、アプリケーションパネルへのアクセス URL です。
前回のポストでは以下のような長い URL を紹介していました。
https://account.activedirectory.windowsazure.com/applications
しかし、結構長いのでエンドユーザに展開するのが面倒、という方には以下の短い URL を使ってもアクセスできるのでこちらがおススメです。
https://myapps.microsoft.com
次に、利用者がアプリケーションパネルを使っている最中に管理者が新しいアプリケーションを割り当てたらどうなるのか？という話です。
ログアウト～再ログインするまでアプリケーションが使えないのか、単純にページをリロードすれば使えるようになるのか？？？
答えは単純にリロードすれば OK です。
この状態で、、、
管理者がアプリケーションにユーザを割り当てると、、、
ページをリロードすると新しいアプリケーションが表示されます。
それだけです。
ほんとに小ネタでした。
2012年12月4日火曜日
[Office 365 & WAAD] Graph API を利用したアイデンティティ管理
Office 365 Advent Calendar および Windows Azure Advent Calendar 用のポストです。
まず、最初に何故 2 つの Advent Calendar へのクロスポストなのか？というあたりを解説するために、Office 365 と Windows Azure Active Directory の関係を解説して置くと、単純に Office 365 の アイデンティティ基盤が Windows Azure Active Directory だからです。
[図：Office 365 と Windows Azure Active Directory の関係]
Office 365 のユーザやグループの管理を行ったり、シングルサインオンを行う際は実際は Office 365 そのものではなく、Windows Azure Active Directory に対して操作をしている、ということです。
[表：Office 365 から見た Windows Azure Active Directory]
| 機能 | Office 365 から見た WAAD |
|---|---|
| シングルサインオン | 信頼するアイデンティティ・プロバイダ ⇒ここで認証されたユーザは信頼できる |
| ユーザ/グループ管理 | アイデンティティ・ストア ⇒このデータベースに保持されるユーザ情報（属性など）を利用する |
さて、本日のお題です。
■Office 365 のユーザ管理の限界
これまで、Windows Azure Active Directory 上のアカウントを管理（追加・変更・削除・ライセンス割り当て等）を行おうと思うと、マイクロソフト公式のディレクトリ同期モジュールを使うか、個別に PowerShell で管理を行うしか方法はありませんでした。
参考：@IT / Office 365 とのアイデンティティ連携を実現する
http://www.atmarkit.co.jp/ait/articles/1211/14/news069.html
ディレクトリ同期ツールを使って Office 365 へのユーザ同期を行う
http://idmlab.eidentity.jp/2011/04/office365.html
しかし、このディレクトリ同期ツール、現状ではそれなりに制限事項があります。
例を挙げると、以下のような事項が挙げられます。
・社内の Active Directory がマルチフォレスト構成だった場合、同期用のドメインを別途構築し、必要なアカウント情報を同期用ドメインに集める必要がある
・不要な（Office 365 を利用しない）ユーザでも同期してしまう（除外ルールの融通が利かない）
・ライセンス割り当ては個別に実施する必要がある
・50,000 オブジェクトまでの同期しかサポートされない
・メンバ数が 15,000 を超えるグループは同期出来ない
・認証プロキシサーバ以下の環境では使えない
※認証不要な Proxy 環境化では netsh コマンドで https プロキシ設定をすれば OK
・（当然ですが）Windows Server でしか動かない
結果として、ディレクトリ同期を行った後、Office 365 の管理コンソールで不要なユーザを消したり、PowerShell でライセンス割り当てをしたり、、、とそれなりに管理者には負荷がかかるのが現実だと思います。
そこで登場したのが Windows Azure Active Directory Graph API です。
現在はまだプレビューですが、Graph API は RESTful な API なのでプラットフォームに依存せずに利用することができますし、各アイデンティティ管理製品のカスタムアダプタとして容易に実装することが可能となります。
先日、本 blog でもこの API を利用して Windows Azure Active Directory 上のユーザ情報を取得する方法を紹介しましたが、今回は
・ユーザの作成
・ユーザの更新
・ライセンスの割り当て
・ユーザの削除
を紹介したいと思います。
参考：[WAAD] REST Client で Graph API を直接実行する
http://idmlab.eidentity.jp/2012/09/waad-rest-client-graph-api.html
■Graph API を利用するための準備
Graph API を利用して Windows Azure Active Directory 上のアカウントを管理するためには、
・サービスプリンシパルの作成
・テナント ID の取得
・作成したサービスプリンシパルへ適切な権限の付与
という 2 つの作業が必要です。
まず、サービスプリンシパルを作成します。
MSOnline / MSOnlineExtended の 2 つのモジュールを読み込んだ状態の PowerShell （Microsoft Online Services Module for Windows PowerShell）から
＞ Connect-MsolService
で MSOnline へ接続します。
その状態で、
＞ New-MsolServicePrincipal -DisplayName "<任意の名前>" -ServicePrincipalNames @("<任意の名前>") -Type Symmetric -Usage Verify - StartDate
と実行します。
すると、以下のような結果が取得できます。
The following symmetric key was created as one was not supplied
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
DisplayName : <指定した名前>
ServicePrincipalNames : {<指定した名前>,
ObjectId : BBBBBBBBBBBBBBBBBBBBBBBB
AppPrincipalId : CCCCCCCCCCCCCCCCCCCCCCCCC
TrustedForDelegation : False
AccountEnabled : True
Addresses : {}
KeyType : Symmetric
KeyId : DDDDDDDDDDDDDDDDDDDDDDDD
StartDate : 2012/12/03 8:00:00
EndDate : 2015/12/03 8:00:00
Usage : Verify
この中で必要なのが、実行結果内の
・AppPrincipalId
・SymmetricKey
・ObjectId
の 3 つです。
次に、作成した Office 365 テナントの ID を取得します。
これも同じく PowerShell で
＞ (Get-MsolCompanyInformation).objectId
を実行して Guid を取得します。
さらに作成したサービスプリンシパルへの適切な権限を付与します。
Windows Azure Active Directory を操作するための権限は複数存在しますが、ユーザを管理するために必要な権限は User Account Administrator というロールが持っていますので、作成したサービスプリンシパルをこのロールメンバに追加します。
同じく PowerShell で
＞ Add-MsolRoleMember -RoleMemberType ServicePrincipal -RoleName "User Account Administrator" -RoleMemberObjectId <サービスプリンシパルの ObjectID>
と実行します。
ここまでそろえばあとは Graph API を実行するだけなのですが、実行するために必要なアクセストークンを取得する必要があります。
ここも RESTful API を使って取得することも可能ですが、今回は面倒なので Windows Azure Authentication Library (AAL) を使ってアクセストークンを取得するプログラムを書いてみます。
参考：Windows Azure Authentication Library
http://msdn.microsoft.com/en-us/library/windowsazure/jj573266.aspx
※ちなみに AAL を使わずにアクセストークンを取得する方法は先に挙げたポストを参照してください。
[WAAD] REST Client で Graph API を直接実行する
http://idmlab.eidentity.jp/2012/09/waad-rest-client-graph-api.html
今回は簡単なプログラムを書きました。
using System;
using Microsoft.WindowsAzure.ActiveDirectory.Authentication;
namespace GetAccessToken
{
class Program
{
static void Main(string[] args)
{
string TenantDomainName = "＜取得したテナントドメイン名＞.onmicrosoft.com";
string TenantId = "＜取得したテナントID＞";
string AppPrincipalId = "＜取得した AppPrincipalId";
string SymmetricKey = "＜取得した SymmetricKey＞";
AuthenticationContext context = new AuthenticationContext(
"https://accounts.accesscontrol.windows.net/" + TenantDomainName);
SymmetricKeyCredential credential = new SymmetricKeyCredential(
AppPrincipalId + "@" + TenantId,
Convert.FromBase64String(SymmetricKey));
AssertionCredential assertion = context.AcquireToken(
"00000002-0000-0000-c000-000000000000/directory.windows.net@" + TenantId, credential);
System.Console.WriteLine("auth:" + assertion.CreateAuthorizationHeader());
}
}
}
このプログラムをコンパイルして実行すると Windows Azure Active Directory から Graph API 実行に必要なアクセストークンを取得し、コンソールに表示してくれますので、メモしておきます。
いよいよ Graph API の実行です。今回も先のポストと同様に Chrome Extension の Advanced Rest Client を使いました。
■Graph API でユーザを作成する
まずはユーザの作成です。
実行するクエリをまとめると以下の表になります。
| 設定 | 値 | |
|---|---|---|
| エンドポイント | https://graph.windows.net/advent2012.onmicrosoft.com/Users | |
| メソッド | POST | |
| ヘッダ | Authorization | 取得したアクセストークン |
| x-ms-dirapi-data-contract-version | 0.8 | |
| Content-Type | application/atom+xml | |
| ボディ | <entry xmlns="http://www.w3.org/2005/Atom" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"> <content type="application/xml"> <m:properties> <d:ObjectType>User</d:ObjectType> <d:AccountEnabled m:type="Edm.Boolean">true</d:AccountEnabled> <d:DisplayName>織田信長</d:DisplayName> <d:GivenName>信長</d:GivenName> <d:Surname>織田</d:Surname> <d:UserPrincipalName>nobunagao@＜テナントドメイン名＞.onmicrosoft.com</d:UserPrincipalName> <d:MailNickname>nobunagao</d:MailNickname> <d:Password>P@ssw0rd</d:Password> </m:properties> </content> </entry> | |
うまくいくと HTTP 201 created が返され、作成されたユーザエントリの情報が XML （Accept ヘッダを application/json にしておけば JSON ）で返ってきます。
■Graph API でユーザを更新する
次に作成したユーザの属性を更新してみます。
作成時に UsageLocale を指定しなかったので、次のライセンス割り当てで問題が起きるため、UsageLocale 属性を更新してみます。（ライセンス割り当てにはユーザの所在地の指定が必要）
今回は PATCH メソッドを利用します。
| 設定 | 値 | |
|---|---|---|
| エンドポイント | https://graph.windows.net/advent2012.onmicrosoft.com/Users(‘＜対象ユーザ名＞@＜テナントドメイン＞.onmicrosoft.com’) | |
| メソッド | PATCH | |
| ヘッダ | Authorization | 取得したアクセストークン |
| x-ms-dirapi-data-contract-version | 0.8 | |
| Content-Type | application/atom+xml | |
| ボディ | <entry xmlns="http://www.w3.org/2005/Atom" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"> <content type="application/xml"> <m:properties> <d:UsageLocation>JP </d:UsageLocation> </m:properties> </content> </entry> | |
うまくいくと HTTP 204 no-content が返されます。
■Graph API でライセンスを割り当てる
作成したユーザにはまだライセンスを割り当てていないので、ライセンスの割り当てを行います。
今回は Office 365 のプラン E3 を使ったので、該当する SkuId である「6fd2c87f-b296-42f0-b197-1e91e994b900」を割り当てます。
| 設定 | 値 | |
|---|---|---|
| エンドポイント | https://directory.windows.net/＜取得したテナントドメイン＞.onmicrosoft.com/Users('＜割り当てるユーザID＞@＜取得したテナントドメイン＞.onmicrosoft.com')/AssignLicense | |
| メソッド | POST | |
| ヘッダ | Authorization | 取得したアクセストークン |
| x-ms-dirapi-data-contract-version | 0.8 | |
| Content-Type | application/json;odata=verbose;charset=utf-8 | |
| ボディ | {"AddLicenses": [ { "__metadata": {"type":"Microsoft.WindowsAzure.ActiveDirectory.AssignedLicense"}, "DisabledPlans": {"__metadata": {"type":"Collection(Edm.Guid)"}, "results":[]}, "SkuId":"6fd2c87f-b296-42f0-b197-1e91e994b900" } ], "RemoveLicenses":null } | |
うまくいくと HTTP 200 ok が返され、アサインされたライセンスを含むユーザエントリ情報が XML もしくは JSON で返ってきます。
よく見ると RMSOnline なんていう文字列も見えるので、Office 365 の管理ポータルから見える以外のライセンスの準備も進んでいることがよくわかります。
■Graph API でユーザを削除する
最後に作成したユーザを削除してみます。
以下のクエリを実行します。
| 設定 | 値 | |
|---|---|---|
| エンドポイント | https://graph.windows.net/advent2012.onmicrosoft.com/Users(‘＜作成したユーザID＞@＜テナントドメイン＞.onmicrosoft.com’) | |
| メソッド | DELETE | |
| ヘッダ | Authorization | 取得したアクセストークン |
| x-ms-dirapi-data-contract-version | 0.8 | |
| Content-Type | application/x-www-form-urlencoded? | |
こちらもうまくいくと HTTP 204 no-content が返ってきます。
いかがでしたでしょうか？
まだまだプレビューですので、色々と検証してみる必要はありそうですが、上記のように公式のディレクトリ同期ツールを使わなくても Graph API を実行することによりアイデンティティ管理を柔軟に行うことが可能になることがわかりました。
私も Forefront Identity Manager 2010 用の Windows Azure Active Directory 用のカスタム管理エージェントを作ってみようとしているところなので、また完成したら公開したいと思います。
以上で私のポストはおしまいですが、明日は各 Advent Calendar は以下の予定になっているそうなので、引き続き参考にしてみてください。
・Office 365 ： Office 365 MVP 中村 和彦さん / http://simplesso.jp/
・Windows Azure ： Kentaro AOKIさん / http://kentablog.cluscore.com/
登録:
投稿 (Atom)
投稿
