1. Office / SharePoint を活用した
クラウド アプリケーション開
発

2. SharePoint を使ったクラウドアプリ
～ 3 つのパターン ～
1. Windows Azure による B to B 連携
o Windows Azure Service Bus / Windows Azure
Connect
2. Office 365 上で動作するアプリケーション
(サンドボックス アプリケーション)
3. Office 365 SharePoint Online への
リモート接続

3. ① Windows Azure による
B to B 連携
• Windows Azure Service Bus
– ポイント間
– オンプレミス – クラウド間の、疑似的な双方向連
携の実現基盤 (Outbound port のみを使用)
– Queue パターン, Pub/Sub パターンなど、豊富なシ
ナリオに対応
– Azure 用の BizTalk Adapter
• Windows Azure Connect
– マシン間
– 内部で、Service Bus の relay を使用

4. ① 典型的な構成例
Windows Azure Service Bus
連携用のアプリ 連携用のアプリ
(サービス など) (サービス など)

5. ① 注意すべき点
• 何某かのアプリケーション (サービスなど) をイン
ストールする必要がある
– 加えて、接続先の管理なども必要
• マルチテナント、認証なども、開発者自身が設計
する必要がある
• “SharePoint UI自体” を外に公開するものではない
– こうしたシナリオでは、Office 365 または、Hoster に
よる SharePoint Hosting が必要
• いわゆる “同期” (Sync) のための基盤ではない
– Offline シナリオへの対応、Consistency Management な
どが必要

6. ② Office 365 で動作する
アプリケーション
• サンドボックス ソリューションによる配置
(Office 365, SharePoint 2010 から使用可能)
• Office 365 SharePoint Online 上で動作
• オンプレミスにおいても、簡易配布ソリュー
ションとして提供可能
• Game Changes &
今後のメインストリーム …
– 提供方式
– アプリケーション開発スタイル (後述)
• Dynamics CRM 2011 List Component, など

7. ② 現状の問題点
• 数多くの制限事項
– 使用可能なソリューションの制限
– ローカル リソース / ネットワーク アクセスの
制限
– 使用可能な API の制限
– リソース クォーター制限
推奨プログラミング スタイルは、HTML / JavaScript

8. ② サンドボックス アーキテク
チャ
Client Web Front End Host Server
(Browser)
IIS Worker Process
(w3wp.exe)
Execution Manager Host Services
(Inside AppPool) (SPUCHostService.exe)
Worker Services
使用可能な API の制限 (SPUCWorkerProcess.exe)
Untrusted Code
外部リソースへのアクセス制限 (User Code)
リソースクォータ (実行時間など)
OM Subset Proxy
Microsoft.SharePoint.dll

9. ② サンドボックス アーキテク
チャ
Client Web Front End Host Server
(Browser)
IIS Worker Process
(w3wp.exe)
代替策 Execution Manager Host Services
(Inside AppPool) (SPUCHostService.exe)
JavaScript
Worker Services
(SPUCWorkerProcess.exe)
Untrusted Code
(User Code)
サンドボックスの外 !
• 通常のクライアントアクセスと同等 OM Subset Proxy
の扱い
• SharePoint 2010 以降で使用可能
• ほとんどの SharePoint 標準操作と対 Microsoft.SharePoint.dll
話可能

10. ② その他のワークアラウンド
(How-To)
• ネットワーク接続
– JSONP の活用
• ただし、使い方に注意 !
– 後述するバッチ連携 シナリオとの併用
• Server OM と比べるとやはり制限有
• ただし、O365 側からのリアルタイム連携 (逆方向) は不
可
• ASP.NET のコード ビハインド
– サンドボックス用 Web パーツにまとめて、
ASP.NET ページに張り付けることができる
• ファイル アップロード など (API 制限)
– OOB 画面の呼び出し

11. ③ O365 SPO へのリモート接続
• いわゆる SharePoint SOAP、SharePoint
Client OM、SharePoint REST などへのリモー
ト接続
• In-Place 形態ではなく、リモート接続方式
• ① と同様の制限
– 何らかの開発アプリケーションが必要
– 同期 (Sync) の基盤はなし (作り込み要)
• ただし、認証が “ひとずじなわ” には行か
ない

12. ③ O365 SPO の認証基盤と
認証の流れ (WS-Trust / WS-Federation)
② リダイレクト
③ 認証要求
(ID / パスワード) Microsoft Federation Gateway
(MFG)
④ セキュリティ情報 (SAML)
+ 認証 Cookie
① 接続
⑤ リダイレクト (SAML送信)
⑥ 認証 Cookie
Office 365
SharePoint Online

13. ③ O365 SPO の認証基盤と
認証の流れ (WS-Trust / WS-Federation)
つまり、こんな感
じ . . .
Microsoft Federation Gateway
(MFG)
Office 365
SharePoint Online

14. ③ O365 SPO の認証基盤と
認証の流れ (WS-Trust / WS-Federation)
ここに、AD FS が入ると、こんな感じ . . .
Microsoft Federation Gateway
(MFG)
Office 365
SharePoint Online
Active Directory Federation Services
(ADFS)

15. ③ Passive Auth
• この方法では、「ブラウザー」が前提
• ブラウザーと同じことをプログラムでおこな
うことは、事実 “不可能” に近い
– Location、Cookie などのヘッダー処理
– フォームの処理
– JavaScript の実行 など
• 利用者にログイン画面をいったん表示する必
要がある
– Windows Phone、Office 製品などは、この方式を
採用
• つまり、バックエンド プログラムでの接続
は不可

16. ③ Active Auth
• Passive Auth の課題を解決した接続方法
• プログラムなどから能動的に SAML
Assertion を取りに行く認証スタイル
• 一般に、WS-Trust を使用
– 実装しているかどうかは STS 依存
– MFG、ADFS 共に、実装
• いくつかの注意点
– SSO の対象とはならない
– ADFS などの配置方法を認識しておく必要あり