第4回 Google Appsとのアイデンティティ基盤連携を実現するクラウド・サービスと社内システムとのID連携 最新トレンド(2/2 ページ)

» 2013年01月23日 20時20分 公開
[富士榮 尚寛(Microsoft MVP - Forefront Identity Manager),伊藤忠テクノソリューションズ株式会社]
前のページへ 1|2       

プロビジョニングの設定

 社内AD上のアカウントを効率的にGoogle Apps上のアカウントと連携するには、Googleが提供しているProvisioning API 2.0を利用する必要がある。このAPIを利用するツールとしては、Google社が提供するGoogle Apps Directory SyncやサードパーティーのID管理製品などが存在する。今回はマイクロソフトのID管理製品であるForefront Identity Manager 2010 R2(FIM 2010 R2)および筆者がCodePlex上で公開しているFIM 2010 用のGoogle Apps管理エージェントを組み合わせて利用する例を紹介する。

 AD FS 2.0を利用したシングル・サインオンと合わせると以下のようなシステム構成となる。

FIM 2010 R2 を利用したプロビジョニングとAD FS 2.0を利用したシングル・サインオン FIM 2010 R2 を利用したプロビジョニングとAD FS 2.0を利用したシングル・サインオン

 では、具体的な実装方法について解説していく。

●Google AppsのProvisioning APIの設定を有効化する

 初期状態のGoogle Appsは管理者が Web 管理コンソールから手動でユーザーの管理を行う設定となっている。前述のように効率的なID管理を社内から行うためにはProvisioning APIを利用するようにGoogle Appsを構成する必要がある。

 設定を行うためには、シングル・サインオン設定を行った際と同様にGoogle AppsのWeb管理コンソールへログインし、[ドメインの設定]メニューから[ユーザー設定]を開き、[Provisioning API を有効にする]のチェックボックスにチェックを入れる。

Google Apps上でProvisioning APIを有効化する Google Apps上でProvisioning APIを有効化する
SSOの設定をしたときと同様に、Google AppsのWeb管理コンソールで設定する。
  (1)これを選ぶ。
  (2)これを選ぶ。
  (3)これにチェックを入れてオンにする。

 非常にシンプルだが、本設定を行うことでGoogle AppsのIDを外部から管理するためのAPIが有効化される。次は実際にAPIを実行する社内のID管理システム側の設定を行う。

●社内ID管理システムからProvisioning APIを実行する

 シングル・サインオンを含むGoogle AppsとのID連携において、社内のID管理システム(FIM 2010 R2)の役割はAD FS 2.0が発行するSAMLトークンの中に含める属性をAD DS上に作成すること、Google Apps上にIDを作成することの2つである。

 本稿ではFIM 2010 R2の詳細な実装方法についての解説は割愛させていただき、重要なポイントのみ説明する。実装するのは以下の機能である。

同期方向 同期内容
FIM 2010 R2 ⇒ AD DS ・ユーザーの作成
 メール・アドレス属性へ「ユーザー名@ドメイン名」の設定
FIM 2010 R2 ⇒ Google Apps ・ユーザーの作成
 シングル・サインオン環境ではGoogle Apps上のパスワードを利用しないが、ユーザー作成時に設定が必要なため、ランダムな値を設定
FIM 2010 R2 での実装機能

 次の画面はFIM 2010 R2の同期マネージャである。AD DS用およびGoogle Apps用の管理エージェントが設定されており、ユーザーの管理(作成・更新・削除)が可能だ。

FIM 2010 R2同期マネージャの画面 FIM 2010 R2同期マネージャの画面
社内のAD DSとGoogle Apps間でユーザー・アカウントなどの同期を管理
  (1)設定されたGoogle Apps用の管理エージェント。
  (2)作成されたユーザー・アカウントの数。

 まず、社内のAD DS用の管理エージェントの設定だが、ポイントはAD DSの電子メール属性にGoogle AppsのユーザーID(メール・アドレス)を設定しておくことである。前述のAD FS 2.0における要求規則の構成で解説した通り、本属性を基にGoogle Apps上のアカウントと社内AD DS上のアカウントのひも付け(フェデレーション)を行うことになる。

AD DS上に作成したユーザー・アカウントの電子メール属性 AD DS上に作成したユーザー・アカウントの電子メール属性
この設定により、Google Appsと社内AD DSとのアカウントのひも付けが行われる。
  (1)Google AppsのユーザーID(メール・アドレス)を指定する。

 次にGoogle Appsへのユーザー・アカウントの作成だが、FIM 2010 R2の管理エージェント内では、Google Provisioning APIの仕様に基づき、下記のようなフローで処理が実行されている。

Google Provisioning APIを利用したユーザー・アカウント作成処理フロー Google Provisioning APIを利用したユーザー・アカウント作成処理フロー

 簡単に説明すると、Provisioning APIへのアクセス認可をOAuthの認可サーバより取得し、作成するユーザー情報をXML形式でProvisioning APIへPOSTする、という流れである。各フローの詳細は以下の通りだ。

順番 処理方向 メソッド パラメータ
1 FIM2010R2
⇒認可サーバ
GET ・client_id=<Google API Consoleで取得したClient ID>
・response_type=code
・redirect_uri=urn:ietf:wg:oauth:2.0:oob
・scope= https://apps-apis.google.com/a/feeds/user/
2 認可サーバ
⇒FIM2010R2
(Response)
HTTP 302
code=<認可コード>
3 FIM2010R2
⇒認可サーバ
POST ・code=<認可コード>
・client_id=<Google API Consoleで取得したClient ID>
・client_secret=<Google API Consoleで取得したClient Secret>
・redirect_uri=urn:ietf:wg:oauth:2.0:oob
・grant_type=authorization_code
4 認可サーバ
⇒FIM2010R2
(Response)
HTTP 200
"access_token" : "<アクセストークン>
JSON形式
5 FIM2010R2
⇒Provisioning API
POST Authorization ヘッダ: <アクセストークン>
ボディ(XML形式):
<?xml version="1.0" encoding="UTF-8"?>
<atom:entry
xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:apps="http://schemas.google.com/apps/2006">
<atom:category
scheme="http://schemas.google.com/g/2005#kind"
term="http://schemas.google.com/apps/2006#user"/>
<apps:login
userName="<ユーザー名>"
password="<パスワード>"
hashFunctionName="SHA-1" suspended="false"/>
<apps:name familyName="<姓>"
givenName="<名>"/>
</atom:entry>
Google Provisioning APIによるユーザー・アカウント作成処理フローの詳細
Google API Console: https://code.google.com/apis/console/ から利用できる。
各エンドポイントURL:
 認可サーバ: https://accounts.google.com/o/oauth2/auth
 Provisioning API: https://apps-apis.google.com/a/feeds/<ドメイン名>/user/2.0
現在公開しているGoogle Apps管理エージェントでは、Provisioning APIへのアクセス認可にOAuthではなく旧方式であるClientLoginを利用している。これはGoogleによって今後使用されなくなるので、早い段階でOAuth形式へ変更する予定である。

 ここまでの設定で社内AD DSとGoogle Apps上にひも付け可能な状態のユーザー・アカウントが作成できたので、実際にシングル・サインオンの動作を確認できる。

シングル・サインオン動作の確認

 では、実際に社内のAD DSで認証を受けてGoogle Appsへログインするシングル・サインオン動作を確認する。

 今回、動作確認用には以下の2パターンの接続環境を用意した。

ネットワーク デバイス クライアント 利用サービス
社内から接続 PC Webブラウザ Gmail
社外から接続 スマートフォン(Android OS 4.0) ネイティブ・アプリケーション Googleカレンダー
動作確認パターン
スマートフォン用のネイティブ・アプリケーションは自作のものを利用した。

●社内PCのWebブラウザからアクセス

 社内でADドメインに参加しているPCであればAD FS 2.0サーバへの統合 Windows 認証が有効なため、PC へログオンしたユーザーでそのままGmailへアクセスできる。なお、Office 365の場合と同様に、あらかじめクライアントPC のInternet Explorerのセキュリティ設定でAD FS 2.0サーバをローカル・イントラネット・ゾーンへ加えておく必要がある。

 PCへログオンしたらWebブラウザを起動し、Gmail(https://mail.google.com/a/<ドメイン名>)へアクセスすると、瞬間的にAD FS 2.0サーバへリダイレクトされた後、自動的にGmailの画面が表示されるはずだ。

Gmail へのシングル・サインオン Gmail へのシングル・サインオン
ADドメインに参加しているPCにログオンした後にGmail(https://mail.google.com/a/<ドメイン名>)へアクセスすると、AD FS 2.0サーバへリダイレクトされた後、すぐにGmailの画面が表示されるはずだ。

 なお、社外からアクセスした場合はDMZに配置したAD FS 2.0プロキシへリダイレクトされるので、社内AD DSのIDとパスワードを使ってフォーム認証を実施した後、Gmail へアクセスすることとなる。

●社外スマートフォンのネイティブ・アプリケーションからアクセス

 社外でスマートフォンのネイティブ・アプリケーションからGoogle Apps上のデータへアクセスを行う場合、前述したGoogle Appsユーザー・アカウント作成時のProvisioning APIへのアクセスの場合と同様にOAuthでアクセス認可を受ける必要がある。その際のユーザー認証はDMZに配置したAD FS 2.0プロキシで実施する。

ネイティブ・アプリケーションからGoogleカレンダーAPIへのアクセス・フロー ネイティブ・アプリケーションからGoogleカレンダーAPIへのアクセス・フロー

 本稿では、上記フローを簡単に実装したAndroid OS用アプリケーションを用意して、動作確認をした。

 まずアプリケーションを起動してGoogleカレンダーのデータを取得しようすると、Googleアカウントのログイン画面へリダイレクトされる。ログインIDとしてシングル・サインオンが設定されているドメインのメール・アドレスを入力して[ログイン]ボタンをクリックすると、AD FS 2.0プロキシのフォーム認証画面へ遷移する。この際Google Accountのログイン画面へのパスワードの入力は不要である。

Android OS用アプリケーションによるGoogleカレンダーのデータ取得の例(a) Android OS用アプリケーションによるGoogleカレンダーのデータ取得の例(a)
  (1)このアプリケーションの初期画面。
  (2)Googleアカウントのログイン画面が表示されたら、SSOを設定したメール・アドレスを指定して[ログイン]ボタンをクリックする。パスワード指定は不要。
  (3)AD FS 2.0のフォーム認証画面が表示されたら、社内ADのアカウントとパスワードを指定して[サインイン]ボタンをクリックする。

 その後、AD FS 2.0プロキシで認証されるとAPIへのアクセスの同意画面が表示されるので、対象APIおよび許可内容を確認してから同意をする。するとGoogleカレンダーから実際のデータが取得され、画面上に表示される。

Android OS用アプリケーションによるGoogleカレンダーのデータ取得の例(b) Android OS用アプリケーションによるGoogleカレンダーのデータ取得の例(b)
APIへのアクセスに同意すると、実際にデータが取得できる。
  (1)このアプリケーションがアクセス許可を求めている内容。
  (2)(1)の確認後、これをクリックするとアクセスが許可される。
  (3)(2)によって取得できたGoogleカレンダーのデータ。

 以上が、社内および社外の各種デバイスから社内AD/AD FS 2.0を使ってGoogle Appsへシングル・サインオン、およびGoogleの提供するAPIへのOAuthを使ったセキュアなアクセスを行った場合の動作である。


 次回はsalesforce.comとのID連携を解説する。Office 365やGoogle Appsの場合と同様のWebシングル・サインオンの設定を行うとともに、利用時にユーザー・アカウントを動的に作成するジャスト・イン・タイム・プロビジョニングについての設定および動作の確認について説明する予定だ。

■更新履歴

【2013/01/23】図「Google Appsと社内Active Directoryの連携環境」「FIM 2010 R2 を利用したプロビジョニングとAD FS 2.0を利用したシングル・サインオン」「Google Provisioning APIを利用したユーザー・アカウント作成処理フロー」「ネイティブ・アプリケーションからGoogleカレンダーAPIへのアクセス・フロー」を作り直し、図中の一部用語を日本語表記に変更しました。




「クラウド・サービスと社内システムとのID連携 最新トレンド」のインデックス

クラウド・サービスと社内システムとのID連携 最新トレンド

前のページへ 1|2       

Copyright© Digital Advantage Corp. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。