ラベル Graph の投稿を表示しています。 すべての投稿を表示
ラベル Graph の投稿を表示しています。 すべての投稿を表示

2015年1月16日金曜日

[AADSync/DirSync]同期に使うAzureAD管理者アカウントの管理

twitterで少し話題に上ったので、色々と調べ&試してみました。

きっかけは、複数企業(マルチドメイン)で一つのAzure Active Directory(AzureAD)テナントを共同利用するようなケースにおいて、各企業のオンプレミスActive Directoryから各社のユーザをAADSyncやDirSyncを使って同期する場合にAADSyncやDirSyncに設定するAzureADの管理者アカウントをどのように管理するべきなのか?という議論でした。

同期に利用するAzureAD上のユーザアカウントはテナントの全体管理者の権限が必要なので、同じAzureADテナント上のユーザやグループであれば他企業のものであっても管理することが権限上は可能となってしまいます。

参考)AADSyncに必要なAzureADアカウントの権限等
 http://msdn.microsoft.com/en-us/library/azure/dn757602.aspx
 ・必要な要件
  全体管理者ロールを持ったアカウントを利用すること
 ・推奨事項
  ①パスワード期限を無期限に設定すること(パスワードを16文字以上の強固なものにすること)
  ②AADSync専用のアカウントを作成すること


そこで、各AADSyncに設定する管理アカウントの権限をうまく制限出来ないか?という話になります。

まず、テナント内のユーザ情報の閲覧・更新を行うには、以下の4つの方法が考えられます。
①管理ポータルへアクセスする
②PowerShellのコマンドレット(Get-MsolUser等)を使う
③AADSyncの内部(Connector Space)を参照する
④GraphAPIを使う

AADSyncに設定するユーザで上記①~④を実行できなければよいのですが、結論としてはすべてを満たすのは無理なのですが、それぞれどのような状態になるのかを紹介してみます。

①管理ポータルへのアクセスを制限する
 これは比較的簡単です。
 単純にAzureのサブスクリプションを対象のアカウントに紐づけなければ済む話です。
 管理ポータルにアクセスしても以下の画面が表示され、ディレクトリの管理までたどりつけません。



②PowerShellのコマンドレットの実行を制限する
 まず、テナント中の特定ドメインのユーザのみを管理する、という思想がないのでコマンドレットの内部での権限分離は絶望的です。
 となると、コマンドレット自体を実行できないようにするには?という話になってきます。

 対策案としては、各企業に配る同期用ユーザのMFA(多要素認証)を有効にしてしまう、ということが考えられます。こうすれば勝手に各企業管理者が同期用ユーザを使って何かをしようとしても追加認証(例えばSMS通知)を抑えておけば勝手にログインすることはできなくなります。(当然管理ポータルへもログインできなくなります)

 これで問題ないのではないか?と思い、いざAADSyncの設定を行おうとすると認証エラーが出てしまいます。


 ちなみに設定時はMFAを設定せずに後からMFAを設定すると同期エラー(stopped-extension-dll-exception)が出ます。


 イベントログを見るとやはり認証エラーが出ています。



 次に試すのは多要素認証をONにして、アプリケーションパスワードを使ってAADSyncの設定をしてみます。
 結果、エラー内容は変わりますが、やはりだめです。



Technetのアプリケーションパスワードの説明を見ると、以下の記述があります。(強調は筆者追加)
 http://technet.microsoft.com/ja-jp/library/dn270518.aspx

[多要素認証をサポートしないブラウザー以外のクライアントに必要なアプリ パスワード] 多要素認証がユーザーのアカウントで有効になると、Outlook や Lync などの大半のブラウザー以外のクライアントでアプリ パスワードを使用できますが、そのユーザーが管理アカウントを保持している場合でも、Windows PowerShell などのブラウザー以外のアプリケーションではアプリ パスワードを使用した管理操作は実行できない点に注意してください。Powershell スクリプトを実行するための強力なパスワードでサービス アカウントを作成し、そのアカウントで多要素認証を有効にしないでください。

クライアントがオンプレミスとクラウドの両方の自動検出エンドポイントと通信するハイブリッド環境ではアプリ パスワードは機能しない - オンプレミスでの認証にはドメイン パスワードが必要で、クラウドでの認証にはアプリ パスワードが必要なので、クライアントがオンプレミスとクラウドの両方の自動検出エンドポイントと通信するハイブリッド環境では、アプリ パスワードが機能しないことに注意してください。


 中々対応は難しそうです。
 ただ、このあたりを見ると
 「現在、Windows PowerShell 用 Azure Active Directory はアプリ パスワードに対応していません。」
 とあるので、将来的にはサポートするのかも知れません。


③AADSyncの内部(Connector Space)を参照を制限する
 Synchronization Service Manager(miisclient.exe)の利用を制限することは無理ですので、Connector SpaceやMetaverseの中身を見ればAzureADからのImportやSynchronizationジョブで同期されたユーザ一覧が参照できてしまいます。
 ここで自社のユーザ以外を見れなくしようとするとあらかじめルールエディタでフィルタを設定する必要がありますが、当然あとから設定を変えることも可能なので、完全に制限をかけるのは無理です。



④GraphAPIを使わせない
 これは割と簡単です。
 GraphAPIを使うにはAzureAD上にクライアントアプリケーションを登録する必要がありますが、登録作業は管理ポータルから実施するため、①の方法で管理ポータルへアクセスできないようにしておけばOKです。



◆まとめ
現状、同一AzureADテナント内に複数ドメインをホストし、ドメイン毎に管理アカウントの権限を完全に分離するのは不可能。
⇒MFAを有効にしたり、アプリケーションパスワードを使うとAADSyncでの同期に支障が出るので対策とはならない。

とりあえず、セキュリティの境界を分けたければテナントを分けましょう、ということですね。


2015年1月9日金曜日

[AAD]Graph API 1.5のGAとスキーマ拡張+GUIツール公開

12月末にリリースされたGraph API ver. 1.5を使うことによりAzure Active Directory上のオブジェクトのスキーマの拡張がGraph API経由で出来るようになりました。
合わせて、Graph APIライブラリのver. 2.xがリリースされ、自分でREST APIを実行するクライアントを実装しなくても簡単にGraph APIが実行できるようになっています。

関連ポスト
- Active Directory Team のblog
  Improved Azure AD Graph API and Client libraries for .Net, Android, iOS and much more!

- Windows Azure Active Directory Graph Team のblog
  Announcing Azure AD Graph API Client Library 2.0

  Announcing the new version of Graph API: api-version=1.5


と言っても、結局は自分でライブラリを使ったアプリケーションを作って、、となるとハードルも高いので、新しいAPIを試しがてらGUIツールを作ってみました。
(Baby Metalの武道館ライブのBluRayを見ながら2時間くらいで実装したのでかなり適当ですのであしからず。試す時は試験用のディレクトリを使ってください。何が起きても責任は負えません)


こんな感じでGUIで拡張プロパティが登録できます。
(ちなみにRemoveも実装しているのですが、現状うまく動きません。消したいときはREST Clientなどで直接消してください)

ダウンロード、詳しい説明はこちらよりどうぞ(英語ですみません)
 - Codeplex : Azure Active Directory Extended Schema Manager
     https://aadschema.codeplex.com/


詳細手順はCodeplexにも書きましたが、Azure Active Directory上にアプリケーションを一つ定義してあげる必要があります。そのアプリケーションにディレクトリの読み書きの権限を与えて、アプリケーションを通してスキーマを触っています。

必要なのは、以下です。
・アプリケーションの登録(Webアプリケーション/WebAPIとして登録)

・ClientId/Keyの取得

・Azure Active DirectoryへのRead/Write権限の付与


そのうち、Azureの管理ポータルからも触れるようになる気もしていますが、それまでに手軽に試してみたい方はどうぞ。

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 管理やシングルサインオン環境構築をどこまで省力化できるか、を検証してみたいと思います。


前提となる環境、利用する機能は以下です。

  • 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 上にもユーザが作成されています。

注1)現在の仕様では WAAD から Google Apps 上に新規作成されたユーザは「停止済み」状態になっているので、個別に有効化する必要があります)
注2)現状、グループ単位でのアプリケーション割り当ては 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年9月5日木曜日

JWx 仕様の日本語翻訳版が公開されました

以前より OpenID Authentication や OAuth 2.0 などの仕様の日本語化を行ってきた OpenID Foundation Japan の翻訳・教育ワーキング・グループにより JWx の翻訳版が公開されました。



本当は昨日(9/4)の OpenID Technight での発表の現場へ駆けつけたかったんですが、残念ながら大雨で足止めをされてしまい、間に合わず。。。


今回公開されたのは、以下の3点です。




Windows Azure Active Directory の API や Google Apps の API、Salesforce.com の API を Forefront Identity Manager(FIM)をはじめとする IdM 製品から実行するようなケースではこれまで各接続先に対する設定に管理者の ID とパスワードを埋め込んだりする必要がありましたが、JWT を使った OAuth 2.0 の認可を行う形へ各社の API が対応してきているので、今後はそのようなリスクのある運用はしなくても良くなると思われます。今のうちに JWx に慣れ親しんでおく良い機会になると思いますので、ぜひ参考にしてください。
(私は JWT の部分で協力させていただいています)


参考)これまでに翻訳された仕様一覧はこちらから。
 http://openid-foundation-japan.github.io/



2013年7月14日日曜日

[FIM2010]Google Apps MA 1.1.1 をリリースしました

かなり久しぶりの更新になりましたが、先ほど codeplex にモジュールをアップロードしました。

 Google Apps MA
 - https://fim2010gapps.codeplex.com/



といってもバグフィックスです。
しかも直したのは半年以上前という、、単にアップロードをサボってただけです。

修正ポイントは、
「インポート処理時にページングがうまく実装出来ていなかったので実装した」
の1点のみです。

FIM は CS へインポートする際に MA に設定したページサイズ分のエントリを読み込み終わると一旦 GetImportEntries メソッドを抜け、再度エントリが無くなるまで同メソッドを繰り返し呼ぶ、という動きをするのですが、この際に最後のエントリを読み込み終わったことを FIM 側へ自分で伝えてあげる必要があります。
そのためのプロパティが importReturnInfo.MoreToImport というプロパティで、最後のエントリを読み込み終わったらこの値を true にしてあげれば FIM はすべての Import が完了したという判断をして処理を終わります。

小規模のシステムとの接続であれば MA の設定で大きめの数値をページサイズとして設定してあげれば一回の GetImportEntries 処理で完了するので問題ないのですが、MA に設定できる最大サイズを超えるようなエントリーをインポートする必要がある場合は上記のようなページング処理を実装してあげる必要があります。

ちなみに次の実装予定は
1. Google Provisioning API が 5月に新しい API (Google Directory API)へ変わったのでそこへの対応
2. 合わせて API 認可を現状 ClientLogon(管理者 ID とパスワードを MA に設定する方式)にしているのを OAuth 2.0 に対応させる
の2点を予定していますが、1. の API 変更が結構な大手術になりそうなのでぼちぼちやっていく形になりそうです。
まぁ、これを実装しちゃえば Windows Azure Active Directory の Graph API も SCIM もほぼ同じコードで流用できちゃうので早く実装したいとは思っているのですが、、

ではでは。。

2013年4月23日火曜日

[WAAD]アプリケーション統合でGraph APIを簡単に実行

先日のWindows Azure Active Directory(WAAD)の正式リリースでWAADと統合するアプリケーションを簡単に登録することが出来るようになりました。

実際にやっているのは、GoogleのAPIコンソールと同じく、OAuthのクライアントを登録することだけで、

  • アプリケーション情報の登録(各種エンドポイント)
  • クライアントIDとキー(Secret)の取得
  • アプリケーションへ付与するWAADへのアクセス権限を設定

などが行えます。

ここでアプリケーションへ与えることが出来る権限ですが、

  • シングルサインオン
  • シングルサインオン、ディレクトリデータの読み取り
  • シングルサインオン、ディレクトリデータの読み取りと書き込み


の3種類が用意されています。

シングルサインオンはSAMLプロトコルを使ってWAADとの認証連携をする機能、ディレクトリデータの読み取り、書き込みについてはGraph APIを使ってディレクトリデータを操作するための機能を指します。

と、いうことで今回は以前紹介したGraph APIを使って行うWAADのディレクトリデータの操作をアプリケーション統合の機能を使って、より簡単に実行する方法を紹介します。
(といっても簡単になるのはAccess Tokenの取得だけですが)

以前の記事では、Graph APIを利用するためのAccess Tokenを取得するのに、AAL(Windows Azure Authentication Library)を使ったコードを書いていましたが、この部分をアプリケーション統合機能で大幅に簡略化します。

手順はシンプルで、以下のステップだけです。
1.ディレクトリデータの読み取り権限のあるアプリケーションを作成する
  ⇒ClientID / Client Secretを取得する
2.WAADのOAuthのトークンエンドポイントへClient Credentials Grantフローでアクセスする
  ⇒Access Tokenを取得する
3.取得したAccess Tokenを使ってディレクトリデータを読み取る

※尚、OAuth2.0の各種フローと注意点についてはこの辺りを参照してください。
 RFCとなった「OAuth 2.0」――その要点は?

では、さっそくやってみます。


■ディレクトリデータの読み取り権限のあるアプリケーションを作成する

Windows Azureの管理ポータル(https://manage.windowsazure.com/)へログインし、Active Directoryの管理からディレクトリ⇒統合されたアプリケーションを選択します。


アプリの作成からアプリケーションを新規作成します。

[組織で開発中のアプリケーションを追加]を選択します。

アプリケーションに任意の名前を付けて、アクセス権を設定します。とりあえずユーザ情報の読み取りをしたいので、「シングルサインオン、ディレクトリデータの読み取り」を選択します。

URLやアプリIDなどは今回は特に使わないので適当に入れておきます。


取り敢えずアプリケーションが追加されるので、左上の[構成]メニューを開きます。


クライアントIDが生成されているのがわかります。クライアント Secretを生成したいので[キー]のところで時間の指定をします。


1年もしくは2年が選択できるので取り敢えず1年を選択します。保存するとキーが表示されます。


これで必要な情報(Client ID / Client Secret)がそろいました。


■WAADのOAuthのトークンエンドポイントへClient Credentials Grantフローでアクセスする

次は、取得したClient ID / Client Secret)を使ってAccess Tokenを取得します。

手順は簡単で、WAADのOAuthのトークンエンドポイントである
  https://login.windows.net/<テナントドメイン名>/oauth2/token?api-version=1.0
に、

 - grant_type : client_credentials
 - resource : https://graph.windows.net
 - client_id : <先ほど取得した Client ID>
 - client_secret : <先ほど取得した Client Secret>
をPOSTするだけです。
※POSTするデータはURL Encodeしておく必要があります。

いつものAdvanced REST Clientを使ってアクセスしてみます。


すると、JSON形式でAccess Tokenが返ってきます。


これでAccess Tokenを取得できました。
コードを書かずに取得できるというのはとっても素晴らしいことです。



■取得したAccess Tokenを使ってディレクトリデータを読み取る

ここからはこれまでも何回か紹介した方法ですが、取得したAccess TokenをAuthorizationヘッダにセットしてディレクトリからユーザ一覧を取得します。


ユーザ情報が取得できました。




どうでしょうか?
Access Tokenの取得が格段に楽になっているのがわかると思います。
Office365のディレクトリ同期状況の確認などGraph APIの使い道は色々とありますので、一つ簡単なアプリケーションを作っておくと良いかも知れません。

2013年4月11日木曜日

[WAAD]Windows Azure Active Directory が正式リリース


ようやく正式リリースされました。

Windows Azure チームの blog
 - Windows Azure Active Directory: Ready for Production with over 265 Billion Authentications & 2.9 Million Organizations Served!


細かいポイントはすでに色んな人が書いているので省略しますが、
・マイクロソフトアカウントで作成したWindows Azureテナントから利用が出来るようになった
・アプリケーション統合が管理ポータルから出来るようになった
というあたりが新規機能です。

ブチザッキ
 - Windows Azure AD/Backup Serviceほかいろいろ

Cloud Identity(Vittorio Bertocciのblog。MSDNから引っ越しました)
 - Windows Azure Active Directory Reaches General Availability
 - Walkthrough #1: Adding Sign-On to Your Web Application Using Windows Azure AD
 - Walkthrough #3: Developing Multi-Tenant Web Applications with Windows Azure AD

他にも Graph API で若干変更があったので、ここではその点を見ておきます。

最大のポイントは
・リクエストのパラメータに api-version を指定する必要がある様になった
・それに伴い、data contract version の指定が不要になった
という点です。

もちろん、今のところこれまでと同じエンドポイントも使えるのですが、その場合はこれまで通り data contract version を指定する必要があります。(しかも 0.5 / 0.8 のみ指定が可能)


ユーザ情報の取得を行う場合を例に新しいリクエスト方法を見てみます。

・エンドポイント:https://graph.windows.net/テナント名.onmicrosoft.com/users?api-version=2013-04-05
・メソッド:GET
・ヘッダ
 - Authorization/取得したJWT
 - Accept:application/json;odata=verbose;charset=utf-8
  ※簡易取得なら odata=verbose は不要

これまでは以下でした。
・エンドポイント:https://graph.windows.net/テナント名.onmicrosoft.com/users
・メソッド:GET
・ヘッダ
 - Authorization/取得したJWT
 - x-ms-dirapi-data-contract-version:0.5 or 0.8
  ※直近までは 0.9 も指定可能だったが、今は 0.5 / 0.8 しか受け付けない
 - Accept:application/json;odata=verbose;charset=utf-8
  ※簡易取得なら odata=verbose は不要

ちなみに古い形のリクエストで data contract version を付けないと HTTP 400 Bad Request が返ってきて、0.5 / 0.8 / 0.9 / 1.0 のどれかを指定するように言われるのですが、実際 0.9 や 1.0 を指定しても同じく Bad Request となってしまいます。


逆に新しい形のリクエスト(パラメータに api-version=2013-04-05 をつける)だと、data contract version をヘッダにつける必要はなくなり、Response ヘッダを見ると version 1.0 が使われていることがわかります。



後、実は大きな変更点なのですが、エンドポイントのリソース名(usersやgroups)が小文字しか受け付けなくなりました。
以前はリファレンスにも Users とか Groups と書いてありましたが、今は users や groups のようにすべて小文字にしないと 404 Not Found が返ってきます。



今後も以前の宣言通り OpenID Connect 対応など、IDMaaS としての機能が色々とリリースされるようなので、目が離せません。

2013年2月28日木曜日

#idcon mini に参加してきた

Identity Conference Mini に参加しました。
 - http://atnd.org/events/36953


今日は、@hdknr さんによる OneID と Self-Issued OP の話と私が SCIM 関係の話をさせてもらいました。

@hdknr さんの OneID、Self Issued OP の話では、 OneID のサービスの話が聴けました。
ざっくりいうと、OP で認証するときに ID / Password の代わりに、スマートフォンを使って認証する、という仕組みのようです。
流れとしては、
1.ブラウザで RP へアクセス
2.OneID によりブラウザ上に QR コードが表示される
3.携帯電話で QR コードを読み、OP へ=認証
4.ブラウザへトークンが渡され、RP へアクセス可能
というような感じでした。

PC と 携帯の間で KeyPair を共有しており、認証済みの携帯で QR コードを使って OneID へアクセスすることで認証とみなす、という形です。

メリットとしては
・パスワードがいらない
・OP へ渡る属性は暗号化されており、OP の運営者でも内容を参照できない
という2点がメインです。


次に、私が SCIM の話をしました。
若干無理やりではありますが、Windows Azure Active Directory がプロビジョニング API として Graph API を採用しているのは何故か?今後サービスプロバイダは SCIM を使うのが良いのか?Graph を使うのが良いのか?という話をしました。結果的に答えはないのですが、私の個人的な考えとしては、SCIM が目指したのはあくまでスキーマやプロトコルの標準化によるコスト削減や複雑性の低減で、Graph の目指すオブジェクト(ノード)とオブジェクト間の関係性(Edge)の表現とは別お世界であり、今後は現行の SCIM の様に同一レポジトリ内のオブジェクト間の関係(memberとmemberofなど)だけではなく、Federation などによる外部レポジトリ上のオブジェクトとの関係性についても表現することが大切になるのではないか?という話をさせていただきました。

以下が、資料です。
スライドにも書きましたが、答えがない世界なので色々と議論が継続的にできれば、と思います。