Dynamics CRM モバイルアプリケーション開発 その 3


みなさん、こんにちは。

前回に引き続き、モバイルアプリケーション開発の紹介をします。
シリーズものですので、是非初回からご覧ください。

今回は独自開発したアプリケーションをストアに公開した場合に、
複数環境使用で障害となっていた問題と対応策を紹介します。

まず大前提として Active Directory Authentication Library
(ADAL) で必要な各種情報をおさらいします。

ADAL に必要な情報

Authority

ADAL を利用して認証を実行するのは、認証先 Azure Active
Direcotry (AD) や Active Directory Federation Service (AD FS)
の接続先を指定する必要があり、それが Authority です。

RedirectUri

接続してきたクライアントが、Azure AD や AD FS に登録
されたクライアントである証明となる値です。

ResourceName

OAuth 2.0 ではユーザーが選択的にアプリケーションに対して
権限を付与することが可能ですが、そのためにはまず利用する
サービスを指定する必要があります。ResourceName はその
サービス名です。

ClientId

RedirectUri を利用して Azure AD や AD FS にアプリケーション
を登録した際、アプリケーションとサービスを紐づけるための
情報として ClientId が利用されます。

Authority の問題

ストアにアプリケーションを公開して、任意組織に対して利用
させる場合、Microsoft Dynamics CRM のアドレスはユーザーに
入力を促せますが、その組織が所属する Azure AD や AD FS の
アドレスをユーザーが知らない可能性は非常に高いです。

また Microsoft Dynamics CRM Online は 1 つの Azure AD につき
(1 つの Office 365 テナントにつき) 複数の CRM 組織の作成を
サポートすることから、組織名から Azure AD のテナント名を
予測することもできなくなりました。

そこで Microsoft Dynamics CRM Online 2014 年春および設置型
Microsoft Dynamics CRM 2013 用サービスパック 1 から、組織の
アドレスを利用して、Authority の値を取得できるサービスを
提供してこの問題を解消しています。詳細は以下のサイトを
ご覧ください。(後日ブログでも紹介します)

http://msdn.microsoft.com/en-us/library/dn531009.aspx#bkmk_oauth_discovery

Azure コンセントフレームワーク (プレビュー)

2 つ目の問題は、OAuth 2.0 を利用するためには、そのテナントの
管理者が Azure AD や AD FS にアプリケーションを登録する必要
があったという点です。これは特にオンライン環境で問題となり
ます。なぜならユーザーにアプリケーションを利用させたい場合に
管理者向けの登録手順書を毎回作る必要があるほか、その度に
ClientId も変わるという課題があるからです。

Azure コンセントフレームワークはこの問題を解消する技術です。

アプリケーション開発者は自分のテナントにアプリケーションを
登録しておきます。その後ユーザーが異なる組織に接続を試みた
場合、以下のように「同意(コンセント)」画面が表示されます。

image

ユーザーが OK をクリックすることで、管理者の作業なしに
登録の作業が裏で完了する仕組みです。

まとめ

今回は本筋から少しそれて、任意の環境でアプリケーションを
利用する際の課題と対応を紹介しました。このシリーズでも
最後の方にまた登場する技術となりますので、参考まで。

- 中村 憲一郎

Comments (0)

Skip to main content