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

発

SharePoint を使ったクラウドアプリ～ 3 つのパターン ～

1. Windows Azure による B to B 連携o Windows Azure Service Bus / Windows Azure

Connect

2. Office 365 上で動作するアプリケーション( サンドボックス アプリケーション )

3. Office 365 SharePoint Online へのリモート接続

① Windows Azure によるB to B 連携

• Windows Azure Service Bus– ポイント間– オンプレミス – クラウド間の、疑似的な双方向連携の

実現基盤 (Outbound port のみを使用 )– Queue パターン , Pub/Sub パターンなど、豊富なシナ

リオに対応– Azure 用の BizTalk Adapter

• Windows Azure Connect– マシン間– 内部で、 Service Bus の relay を使用

① 典型的な構成例

Windows Azure Service Bus

連携用のアプリ( サービス など )

連携用のアプリ( サービス など )

① 注意すべき点• 何某かのアプリケーション ( サービスなど ) をイン

ストールする必要がある– 加えて、接続先の管理なども必要

• マルチテナント、認証なども、開発者自身が設計する必要がある

• “SharePoint UI 自体” を外に公開するものではない– こうしたシナリオでは、 Office 365 または、 Hoster に

よる SharePoint Hosting が必要• いわゆる “同期” (Sync) のための基盤ではない

– Offline シナリオへの対応、 Consistency Management などが必要

② Office 365 で動作するアプリケーション

• サンドボックス ソリューションによる配置(Office 365, SharePoint 2010 から使用可能 )

• Office 365 SharePoint Online 上で動作• オンプレミスにおいても、簡易配布ソリュー

ションとして提供可能• Game Changes &

今後のメインストリーム …– 提供方式– アプリケーション開発スタイル ( 後述 )

• Dynamics CRM 2011 List Component, など

② 現状の問題点• 数多くの制限事項– 使用可能なソリューションの制限– ローカル リソース / ネットワーク アクセス

の制限– 使用可能な API の制限– リソース クォーター制限

推奨プログラミング スタイルは、 HTML / JavaScript

② サンドボックス アーキテクチャ

Web Front End Host Server

IIS Worker Process(w3wp.exe)

Execution Manager(Inside AppPool)

Host Services(SPUCHostService.exe)

Worker Services(SPUCWorkerProcess.exe)

Untrusted Code(User Code)

OM Subset Proxy

Microsoft.SharePoint.dll

Client(Browser)

使用可能な API の制限

外部リソースへのアクセス制限リソースクォータ ( 実行時間など )

② サンドボックス アーキテクチャ

Web Front End Host Server

IIS Worker Process(w3wp.exe)

Execution Manager(Inside AppPool)

Host Services(SPUCHostService.exe)

Worker Services(SPUCWorkerProcess.exe)

Untrusted Code(User Code)

OM Subset Proxy

Microsoft.SharePoint.dll

Client(Browser)

JavaScript

サンドボックスの外 !• 通常のクライアントアクセスと同等

の扱い• SharePoint 2010 以降で使用可能• ほとんどの SharePoint 標準操作

と対話可能

代替策

② その他のワークアラウンド(How-To)

• ネットワーク接続– JSONP の活用

• ただし、使い方に注意 !

– 後述するバッチ連携 シナリオとの併用• Server OM と比べるとやはり制限有• ただし、 O365 側からのリアルタイム連携 ( 逆方向 ) は不可

• ASP.NET のコード ビハインド– サンドボックス用 Web パーツにまとめて、 ASP.NET

ページに張り付けることができる• ファイル アップロード など (API 制限 )– OOB 画面の呼び出し

③ O365 SPO へのリモート接続• いわゆる SharePoint SOAP 、 SharePoint

Client OM 、 SharePoint REST などへのリモート接続

• In-Place 形態ではなく、リモート接続方式• ① と同様の制限– 何らかの開発アプリケーションが必要– 同期 (Sync) の基盤はなし ( 作り込み要 )

• ただし、認証が “ひとずじなわ” には行かない

③ O365 SPO の認証基盤と認証の流れ (WS-Trust / WS-Federation)

Microsoft Federation Gateway(MFG)

Office 365SharePoint Online

③ 認証要求(ID / パスワード )

④ セキュリティ情報 (SAML) + 認証 Cookie

① 接続

② リダイレクト

⑤ リダイレクト (SAML 送信 )

⑥ 認証 Cookie

③ O365 SPO の認証基盤と認証の流れ (WS-Trust / WS-Federation)

Microsoft Federation Gateway(MFG)

Office 365SharePoint Online

つまり、こんな感じ . . .

③ O365 SPO の認証基盤と認証の流れ (WS-Trust / WS-Federation)

Microsoft Federation Gateway(MFG)

Office 365SharePoint Online

ここに、 AD FS が入ると、こんな感じ . . .

Active Directory Federation Services(ADFS)

③ Passive Auth

• この方法では、「ブラウザー」が前提• ブラウザーと同じことをプログラムでおこなうこ

とは、事実 “不可能” に近い– Location 、 Cookie などのヘッダー処理– フォームの処理– JavaScript の実行　　など

• 利用者にログイン画面をいったん表示する必要がある– Windows Phone 、 Office 製品などは、この方式を採用

• つまり、バックエンド プログラムでの接続は不可

③ Active Auth

• Passive Auth の課題を解決した接続方法• プログラムなどから能動的に SAML

Assertion を取りに行く認証スタイル• 一般に、 WS-Trust を使用– 実装しているかどうかは STS 依存– MFG 、 ADFS 共に、実装

• いくつかの注意点– SSO の対象とはならない– ADFS などの配置方法を認識しておく必要あり