ADFSトレーニングテキスト全文公開チャレンジ(12) – SaaSアプリの登録

皆さんこんにちは。国井です。
ADFSトレーニングテキスト全文公開チャレンジの12回目となる今回はAzure ADとクラウドサービスをID連携させてシングルサインオンする方法についてです。
今回は中途半端なところからスタートするので、簡単におさらいをしておくと、
ADFSとOffice 365以外のクラウドでID連携する場合、ADFSとクラウドを直接接続する方法と、ADFSからAzure ADを経由してクラウドに接続する方法があります。
ここでは、Azure ADを経由してクラウドに接続する際に必要なID連携設定について見ていきます。(Office 365連携によって既にADFSとAzure ADの間は連携されているので省略します)

■ ■ ■

スライド82

Azure AD ディレクトリ(https://portal.azure.com/)内の [エンタープライズ アプリケーション] から SaaS アプリを追加します。
SaaS アプリの追加は、[エンタープライズ アプリケーション] ブレードから [新しいアプリケーション]をクリックし、追加するクラウド サービスをクリックして、追加します。
アプリケーションの種類によって、ID 連携方法は異なり、ここで例として挙げている Salesforce ではパスワード連携、SAML プロトコルによる ID 連携、ADFS による連携の 3種類を選択できますが、Facebook や Twitter などの SAML プロトコルの対応が無いアプリの場合はパスワード連携だけが選択できるようになっています。


スライド83

Azure AD に SaaS アプリを追加すると、Salesforce アプリのブレードが表示され、左ペインから Salesforce に接続するための様々な設定項目が選択できます。このうち、[シングルサインオン] メニューでは SAML プロトコルによる ID 連携の設定を行うことができます。
[シングルサインオン] メニューでは、最初に [モード] 欄から [SAML ベースのサインオン] を選択します。すると、SAML プロトコルで連携するための設定項目が表示されます。続く [サインオン URL] 欄ではAzure AD から SaaS アプリにアクセスするときの最初の URL で、一般的にサインインページを指定します。Salesforce では、Salesforce の [私のドメイン] 設定で定義した URL を指定します。
続いて [SAML 署名証明書] 欄では Salesforce に登録するトークン署名証明書の公開鍵を作成し、ダウンロードしておきます。ID 連携ではフェデレーション メタデータの交換が必要であることを前の章で解説しましたが、SaaS アプリによってはフェデレーション メタデータを交換せず、トークン署名証明書の公開鍵だけを Azure AD から SaaS アプリに受け渡すことで STS 信頼を完了させるケースがあります。Salesforce はこのケースに当たるため、Azure AD の設定画面からトークン署名証明書をダウンロードし、ダウンロードした証明書を Salesforce の管理画面にインポートします。
最後に [Salesforce の構成] では、Salesforce 側に提供するパラメーターが表示されるため、このパラメーターを控えておきます。

フェデレーションメタデータへのアクセス方法あれこれ
Office 365 (Azure AD) の ID 連携では STS 信頼を設定するためにフェデレーション メタデータとなる XML ファイルを ADFS サーバーと Azure AD の間で交換しましたが、Salesforce ではフェデレーション メタデータ内の証明書情報だけが確認できればよいため、フェデレーション メタデータを交換せず、証明書ファイルだけを Salesforce に受け渡ししています。
このようにアプリケーションによって、ID 連携時に STS 信頼を設定する方法は異なります。証明書ファイルを登録するだけの STS 信頼の設定方法は SharePoint Server でも採用されている方法です。ただし、SharePoint Server の場合は URN と呼ばれる文字列を互いに設定し、同じ文字列を持つ STS どうしが信頼されるように同時に設定しています。
そのほかにも、Google Apps との連携ではフェデレーション メタデータを交換しますが、XML ファイルそのものを手動で交換するのではなく、XML ファイルが保存されている URL を好感します。この方法は、証明書が入れ替わることによって、フェデレーションメタデータを再交換するという手間を省くことができて便利な交換方法です。
いずれの方法も Azure AD だけで一方的に決められる STS 信頼の設定方法ではなく、あくまでも相手の SaaS アプリがどのような方法をサポートしているかによって決まります。


スライド84

Azure AD 側で ID 連携の設定を行ったら、Salesforce 側でも同様の設定を行います。設定は、Salesforce の管理画面内にある [SAML シングルサインオン設定] から行います。

■発行者
Azure AD の発行者の URL を登録します。

■ID プロバイダの証明書
Azure AD でエクスポートしたトークン署名証明書を登録します。

■SAML ID の場所
トークン内で受け渡しするクレームを指定します。Azure AD では NameIdentifier クレームが受け渡しされるよう、プリセットされています。

■SAML プロバイダの起動要求バインド
HTTP リダイレクトを選択すると、パッシブ プロファイルによる ID 連携プロセスが実施されます。Azure AD ではパッシブ プロファイルを使用するようにプリセットされています。

■ID プロバイダのログイン URL / ログアウト URL
Azure AD とのやり取りを行うためのエンドポイントを登録します。


スライド85

Salesforce をはじめ、多くの SaaS アプリでは、プロビジョニングによって他のディレクトリストアからの同期を受け付けるようなインターフェイスがありません。そのため、Azure AD では SaaS アプリに対して API コールを行い、SaaS アプリに対して、Azure AD に保存されているユーザーアカウントを作成するように命令することで、実質的なプロビジョニングを実現します。
そのため、Azure AD のプロビジョニング設定では、API コールを行うために必要な設定をあらかじめ定義しておきます。Salesforce の場合には API コールを行うために [ユーザー セキュリティ トークン] と呼ばれるキーが必要となるため、ユーザー セキュリティ トークンを事前に Salesforce から取得し、トークンを Azure AD に登録しています。
また、プロビジョニングによって登録されたユーザーに対しては、SaaS アプリ側でライセンスを割り当てます。ただし Salesforce の場合、後述する Azure AD のアクセス許可設定に連動して、自動的にライセンス割り当てが行われるため、Salesforce 側で手動でライセンス割り当てを行う必要はありません。


スライド86

Azure AD で ID 連携の設定とプロビジョニングの設定が完了したら、最後にアクセス許可の割り当てを行います。アクセス許可の割り当ては、Azure AD のユーザーまたはグループの単位で行うことができます(グループに対するアクセス許可割り当ては Azure AD Premium ライセンスを保有する場合のみ)。
アクセス許可の割り当ては、Microsoft Azure管理ポータルから Azure AD ディレクトリ内の [アプリケーション] から [アカウントの割り当て] を利用して設定します。Salesforce に代表されるように、SaaS アプリによってはアクセス許可の割り当てと同時にライセンス割り当ても行えるものもあります。


スライド87

Azure AD に登録したアプリは、Microsoft Azureで提供されるユーザー用のポータルサイトである、「アクセスパネル」Webサイト (https://myapps.microsoft.com/) よりショートカットをクリックしてアクセスできます。
アクセスパネルでは、アクセス許可が割り当てられたアプリの一覧が表示され、一覧から該当するアプリをクリックすることで、シングルサインオンプロセスが開始され、追加の資格情報を入力することなく、アプリへのアクセスが実現されます。また、Office 365ユーザーの場合には、画面左上のランチャーボタンにアプリを登録しておくことで、Office 365 のメニューからシングルサインオンプロセスを開始することも可能です。
その他、組織内のポータルサイトにショートカットを埋め込んで利用したい場合には、Microsoft Azure管理ポータル画面に用意されているショートカット URL を利用することで、アクセスパネルやOffice 365ランチャーを使わずにシングルサインオンプロセスを開始できます。

編集後記

今回はSAMLプロトコルを利用した Azure AD と Salesforce の連携について解説しました。SAMLプロトコルによるID連携の話をするときって、Salesforceを引き合いに出すことが多いのですが、これは標準的な設定でクセがないことが理由だったりします。私はSalesforce使わないよ、という方でもSalesforceを例に実装方法を学べば、他のSaaSアプリにも応用できると思います。

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください