ベータプログラムが公開されてからしばらく時間が経ちましたが、順番待ちでなかなか使えるようにならないので悶々と情報をあさる日々が続きますが、そんな中でも少しずつ情報が出始めているようです。(MVP for Office365っていうのも出てきたようですし)
その中で興味深いblogエントリがあったので紹介します。(Avanadeのオランダの方が書いているもののようです)
360 on 365
#Office365 and #ADFS2.0, how does it work?
http://360on365.com/2010/12/31/office365-and-adfs2-0-how-does-it-work/
最近ちょこちょこ情報として出始めている中で騒がれている制限事項(前提事項)がやはり一番に紹介されています。
・オンプレミスのActive DirectoryのUPN属性がインターネットから解決出来る必要がある
→下手に.localドメインで社内ADを構築しているとかなり大幅な変更になるかも知れません。他のアプリケーションへの影響もあるでしょうし。。FIM2010などの自動化ツールは必須かも知れません。
・Office365からのドメインの正当性確認を受ける必要がある
→LiveIDとのFederationの時にもはまりましたが、Office365というかMFG(Microsoft Federation Gateway)が認めてくれる必要があります。証明書の発行元はシビアです。。
ベストプラクティスとしては、以下の手順が推奨されています。
・初めにDirecrtory Synchronizationをセットアップし、オンプレミスユーザをクラウドに同期する
・次にフェデレーション信頼を確立する
フェデレーション信頼の確立を行ううえでは、Microsoft Online Services Identity Federation Management Toolが用意されていて、PowerShellのコマンドレットを使ってオンプレミスとOffice365のフェデレーションを設定することができる様です。以下、コマンドレットの例。
Set-MSOLContextCredential
Add-MSOLFederatedDomain
Convert-MSOLDomainToConverFederated
Get-MSOLFederationPropert
LiveIDの時に使ったFederationユーティリティと同じようなお手軽設定ツールですね。
基本的にLiveIDと同じくMicrosoft Federation Gatewayを使う構成になるため、ユーザのアクセスフローは以下の通りです。
1.Office365ポータルへアクセス
2.IDを入力(xxx@xxx.xxx)形式
3.Microsoft Federation Gatewayドメイン名よりレルムを判断してIdP(オンプレミスのAD FS2.0)へリダイレクト
4.AD FS2.0で認証
5.発行されたセキュリティ・トークンをMicrosoft Federation Gatewayへポスト
6.Microsoft Federation GatewayがOffice365用に変換したセキュリティ・トークンをポスト
7.ユーザがログイン
何しろ早く触ってみたいです。
登録:
コメントの投稿 (Atom)
0 件のコメント:
コメントを投稿