Office365とIdentity管理
MVP for Forefront Identity Manager
Naohiro Fujie / @phr_eidentity / http://idmlab.eidentity.jp
1

自己紹介
2
 Blog
 IdM実験室（Identityに関することを徒然と）：http://idmlab.eidentity.p
 Social
 Facebook Page : eIdentity（Identityに関するFeed）：https://www.facebook.com/eidentity
 記事
 Windowsで構築する、クラウド・サービスと社内システムのSSO環境
（http://www.atmarkit.co.jp/fwin2k/operation/adsf2sso01/adsf2sso01_01.html）
 クラウド・サービス連携の基本と最新トレンド
（http://www.atmarkit.co.jp/fwin2k/operation/idftrend01/idftrend01_01.html）
 開発者にとってのWindows Azure Active Directoryの役割と今後の展開
（http://www.buildinsider.net/enterprise/interviewvittorio/01）
 その他
 日本ネットワークセキュリティ協会（JNSA）アイデンティティ管理WG（書籍：「クラウド環境におけるアイデ
ンティティ管理ガイドライン」etc）
 OpenID Foundation Japan 教育・翻訳WG（OAuth/OpenID Connect仕様翻訳）、エンタープライズ・アイ
デンティティWG

Agenda
 アイデンティティ管理の基礎Ⅰ
 アイデンティティとはなにか？関連キーワードと実装は？
 アイデンティティ管理の基礎Ⅱ
 ID連携（フェデレーション）が必要な理由は？APIアクセスの場合は？
 Office365におけるアイデンティティ管理
 Azure AD概要
 ID連携プロトコル（SAMLの例）
 アカウント管理（FIM Sync）
 アカウント管理（Graph API）
3

アイデンティティ
管理の基礎Ⅰ
4

アイデンティティとは
“ID”から連想するよくある間違い
識別子（Identifier）
番号
ログインID
“ID”=“アイデンティティ”
実体（Entity）に関連する属性の集合/ISO/IEC 24760
5

アイデンティティの構成要素
要素 解説 例
属性 後天的に取得された主体に関わる情
報（後から変化する）
名前、電話番号、社員番号、
メールアドレス、認証状態、
位置情報
好み 主体の嗜好に関わる情報 甘いものが好き
形質 主体の先天的な特有の性質
（後から変化しにくい）
生年月日、性別？
関係性 他の主体との関係に関わる情報（一
部属性と重複）
XX大学卒業、YY部所属
6
これらをコンピューターシステム上に反映したもの
（コンピューターシステム上での実体を表すもの）
⇒ デジタル・アイデンティティ

アイデンティティの構成要素：3A
7
構成要素 意味
認証（Authentication） ユーザの正当性を検証すること
（ユーザがデジタル・アイデンティティを利用する
権利があることを検証する）
認可（Authorization） 認証されたユーザに権限を与えること
（デジタル・アイデンティティに何を許可するかを
決定する）
属性（Attribute） ユーザを構成する情報
（何でデジタル・アイデンティティを構成するかを
決定する）
※注）大前提として、デジタル・アイデンティティの正当性の保証を行うことが大切である
（実体に紐づく属性の精度・鮮度の保証、存在の確認など）

実装と管理
 実装手段
 認証：パスワード、証明書、OTP、リスクベース
 認可：リソース（フォルダ等）へのアクセス権付与
 属性：ユーザ DB の整備（AD、DBMSなど）
 分散システムにおける管理手段
 アカウント管理（プロビジョニング）
 オーソリティ（人事DB等）にある属性情報を他システムへ反映する
 ID連携（フェデレーション）
 認証状態などを含むアイデンティティ情報をシステム間で受け渡す
 受け取ったシステム側に保持しているアイデンティティ情報と渡された情報を紐付けることで
シングルサインオンなどを実現する
8

実装例：アカウント管理
（プロビジョニング）
9
ユーザ
利用
対象システム
ID管理システム人事DB
入社、異動、退社
などのイベントに
合わせて人事情報
を取込み
利用ポリシーに合
わせて各システム
へ ID を配布
各システム間のアイ
デンティティ情報の
整合性を担保

事前信頼指定
実装例：ID連携（フェデレーション）
10
認証サーバ
Identity Provider
/ IdP
アプリケーション
（Relying Party /
RP）
①アクセス
②認証状態チェック
③リダイレクト
④認証指示
⑤認証
⑥トークン発行
ユーザ
信頼できるサーバから
発行されたトークンの
中のID情報を自前のID
情報と紐付ける
⇒SSOの実現

アイデンティティ
管理の基礎Ⅱ
11

ID連携（フェデレーション）をする理由
 認証システムの分散を防ぐ
 クレデンシャル（パスワード等）を保持する箇所を極小化する
 強度の高い認証システムで一括してアイデンティティ情報を保持・保
護する
 利便性を高める
 Cookieドメインを跨いだシングルサインオンの実現
12

単純なシングルサインオン
13
認証サーバアプリケーション アプリケーション
パスワードの分散
システム毎に認証
アプリケーション
パスワードの一元管理
認証Cookieの共有に
よるSSO
分散管理状態（SSO不可） 認証サーバの外だし、パスワードの一元管理、
ドメイン内で認証Cookieを共有してSSO
ドメイン境界

ドメイン境界
ID連携（フェデレーション）
14
認証サーバ アプリケーション
パスワードの一元管理
認証Cookieの共有に
よるSSO
認証サーバの外だし、パスワードの一元管理、
ドメイン内で認証Cookieを共有してSSO
認証サーバ アプリケーション
パスワードの一元管理
認証サーバの外だし、パスワードの一元管理、
ドメインを跨いだSSO
アプリケーション
ID連携
サーバ
ID連携サーバを経由す
ることによるドメイン
間で認証Cookie変換
ドメイン境界
このあたりのやり取り方法を規定したものが
ws-federation/SAML/OpenID Connect

APIアクセス時の認証・認可
15
認証サーバ アプリケーション
バックエンド
サービス
ユーザの代わりにアプ
リがサービスを利用
パスワードをアプリに
渡したくはない
必要以上にアプリがサー
ビスを使ってほしくない
認証サーバ アプリケーション認可サーバ
バックエンド
サービス
アクセストークンを
使ってサービス利用
認可サーバで必要な権限に応じ
たアクセストークンを発行、ア
プリへ渡す
このあたりのやり取り方法を規定したもの
がOAuth

Office365の
アイデンティティ
⇒Azure AD概要
16

Office365におけるアイデンティティ管理
の構成パターン
クラウドID クラウドID
＋ディレクトリ同期
フェデレーションID
＋ディレクトリ同期
概要 クラウド（Azure AD）上で
すべて管理
認証はクラウド、オンプレ
AD上のアカウントを同期
オンプレで認証、アカウン
ト管理を実施
認証 Azure AD
- ID/PWD
- 多要素（MFA for O365 /
AAD Premium）
同左
＋オンプレとのパスワード
同期（Same Sign On）
※DirSyncの場合のみ
何でもOK（ID連携する先の
認証サーバの機能に依存）
例）AD FSの他要素認証
ID連携 なし なし AD FS
外部IdP（ws-fed / SAML）
アカウント管理 Azure AD
（管理ポータル or
PowerShell）
DirSync / FIM
その他パッケージ
Graph API
DirSync / FIM
その他パッケージ
Graph API
17

Azure Active Directory構成概要
18

Azure ADの機能
 Identity Provider
 ディレクトリサービスとして : Users/Groups (sync with WSAD)
 プロトコル・サポート : SAML, ws-federation, OpenID Connect
 外部IdPのサポート : SAML, ws-federation
 その他機能 : Multi-Factor AuthN, Self-Service Password Reset
 Authorization Server
 Register WebApps/API as protected resource
19

Identity Provider
Application
SAML-SP
Application
ws-fed RP
Application
OpenID
Connect RP
Microsoft
Account
Azure AD
Account
https://login.windows.com
3rd Party
SAML IdP
SAML
EndPoint
ws-fed
EndPoint
Ext IdPs
RPs
Home
Realm
Discov
er
OAuth2.0
AuthZ/Token
EndPoint
20

Identity Provider
Application
SAML-SP
Application
ws-fed RP
Application
OpenID
Connect RP
Microsoft
Account
Azure AD
Account
https://login.windows.com
3rd Party
SAML IdP
SAML
EndPoint
ws-fed
EndPoint
Ext IdPs
RPs
Home
Realm
Discov
er
OAuth2.0
AuthZ/Token
EndPoint
ws-
fed
ws-
fed
ws-
fed
SAML
ws
res
SAML
SP
21

Sequence
22

23

24

Authorization Server
OAuth2.0
AuthZ/Token
EndPoint
OAuth2.0
Client
WebAPI
Registry
Register as a protected resource
(use manifest file)
ClientID Resource Grant
be6ddad6-…. http://hoge read,write
aa5dd18u-… http://bar read
cc45aa89-… Azure AD SSO,read,write
25

WebAPIの登録とパーミッショ
ンの登録
"appPermissions": [
{
"claimValue": "user_impersonation",
"description": "Allow the application full access to the Todo List service on behalf of the signed-in user",
"directAccessGrantTypes": [],
"displayName": "Have full access to the Todo List service",
"impersonationAccessGrantTypes": [{"impersonated": "User","impersonator": "Application"}],
"isDisabled": false,
"origin": "Application",
"permissionId": "b69ee3c9-c40d-4f2a-ac80-961cd1534e40",
"resourceScopeType": "Personal",
"userConsentDescription": "Allow the application full access to the todo service on your behalf",
"userConsentDisplayName": "Have full access to the todo service"
}],
26

ID連携プロトコル
SAML2.0の例
27
AD FSを使ってAzure ADとID連携をする場合は
ws-federationを使いますが、流れは似ている
ので、3rdパーティIdPを使う場合にサポートさ
れているSAML2.0の例を解説します。

ID連携の流れ
28
サービスへアクセス
認証要求を ID プロバイダ へリダイレクト
認証
Service
ユーザ認証
トークン発行
ACS
トークンを POST
トークンの
生成と署名
トークン署名
の検証
サービスへリダイレクト
サービスを利用
※ACS : Assertion Consumer Service
ユーザ IDプロバイダ Azure AD
外部IdPに対するSPと
して動く
Office365に対しては
IdPとして動く
⇒ID連携のChain

SAML
アーキテクチャ
 SAML オーソリティの構造と AD FS
29
認証
ｵｰｿﾘﾃｨ
認証
ｱｻｰｼｮﾝ
属性
ｵｰｿﾘﾃｨ
属性
ｱｻｰｼｮﾝ
ﾎﾟﾘｼｰ決
定ﾎﾟｲﾝﾄ
認可決定
ｱｻｰｼｮﾝ
ﾎﾟﾘｼｰ実
施ﾎﾟｲﾝﾄ
SAMLリ
クエス
ト
アクセス要求を
受けたサーバ
ｸﾚﾃﾞﾝｼｬﾙ
情報
アプリケーション要求
AD FS 2.0 の世界では
認証ｵｰｿﾘﾃｨはAD DSのみ
属性ｵｰｿﾘﾃｨはAD DS/SQL/ｶｽﾀﾑ
ﾎﾟﾘｼｰ決定ﾎﾟｲﾝﾄはAD DS/SQL/ｶｽﾀﾑ

SAML 2.0 の構成要素
構成要素 解説
トークン（アサー
ション）
IdP が発行するトークンでありアイデンティティ情報が
記載されたもの
プロトコル アサーションを要求・返答するための方法
バインディング プロトコルを通信に乗せる方法（HTTP / SOAP /PAOS
など）
プロファイル プロトコルとバインディングとアサーションを組み合わ
せた方法
メタデータ プロトコルやサービスエンドポイントが記載されたもの
30

SAML トークン構造（※SAML2.0。1.1でも似たようなもの）
 発行者（Issuer）
 誰が、いつ発行したトークンなのか
 識別子（Subject）
 何（誰）に関するトークンなのか
 受信者（AudienceRestriction）
 誰宛に発行されたトークンなのか
 アサーション（クレーム）
 認証アサーション（AuthNStatement）
 認証された時間、手段
 属性アサーション（AttributeStatement）
 属性情報（属性と値）
 認可決定アサーション（AuthzDecisionStatement）
 特定リソースへのアクセス許可されているか
 デジタル署名
31
トークン
属性アサーション
認可決定アサーション
デジタル署名
認証アサーション

SAML トークン構造
 発行者（Issuer）
32
<saml:Issuer>
https://myadfs.example.local/adfs/services/trust
</saml:Issuer>
フェデレーションにおける事前信頼
⇒アプリケーション（RP）はこの発行者情報（エンドポイントアドレス）およびトークンに付与されるデジタ
ル署名の情報を登録する
⇒AD FS 2.0 の「フェデレーションサービスの識別子」の URI
※SAML トークンは BASE64 でエンコードされ、やり取りされるので、XML 形式に復号するには SAML 2.0
Debugger などを利用する。
- SAML 2.0 Debugger https://rnd.feide.no/simplesaml/module.php/saml2debug/debug.php

SAML トークン構造
 識別子（Subject）
33
<saml:Subject>
<saml:NameID>
hoge@mygapps.com
</saml:NameID>
</saml:Subject>
フェデレーションにおけるアイデンティティの紐付け
⇒アプリケーション（RP）はこの識別子の属性名および属性値が自身の保持するアイデンティティと一致す
ることで紐付を行う。
例）Office365 の場合、NameIdentifier 属性に入っている値（通常はGUIDをBASE64エンコードしたもの）
が Azure AD 上のアカウントの ImmutableId と一致すればそのユーザに関する情報とみなす。

SAML トークン構造
 受信者（AudienceRestriction）
34
<saml:AudienceRestriction>
<saml:Audience>google.com/a/mydomain</saml:Audience>
</saml:AudienceRestriction>
フェデレーションにおける事前信頼
⇒アプリケーション（RP）はこの発行者情報（エンドポイントアドレス）およびトークンに付与されるデジ
タル署名の情報を登録する
⇒AD FS 2.0 の「証明書利用者信頼の識別子」の URI

SAML トークン構造
 認証ｱｻｰｼｮﾝ（AuthNStatement）
35
<saml:AuthnStatement AuthnInstant="2012-09-22T00:00:00.000Z">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:federation:authentication:windows
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
※統合 Windows 認証の場合

SAML トークン構造
 属性ｱｻｰｼｮﾝ（AttributeStatement）
36
<saml:AttributeStatement>
<saml:Attribute Name="organization_id">
<saml:AttributeValue xsi:type="xs:anyType">ABCDEFG
</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
※organization_id 属性の値が ABCDEFG となる例

SAML トークン構造
 認可決定ｱｻｰｼｮﾝ（AuthzDecisionStatement）
37
<saml:AuthzDecisionStatement
Resource="http://www.example.com/secret.html"
Decision="Permit">
<saml:Action
Namespace="urn:oasis:names:tc:SAML:1.0:action:ghpp">
GET
</saml:Action>
</saml:AuthzDecisionStatement>
※http://www.example.com/secret.html に対して GET を許可する例

SAML トークン構造
 デジタル署名
38
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
……（デジタル署名に関する情報）……
</ds:Signature>
フェデレーションにおける事前信頼
⇒アプリケーション（RP）はこのデジタル署名に関する情報を事前に登録する
⇒AD FS 2.0 のトークン署名証明書

アカウント管理
⇒FIM Sync
39
ディレクトリ同期ツール（DirSync）はFIMの限
定版なので構造はFIM Syncと同じです。

ディレクトリ同期とFIM
 ディレクトリ同期（DirSync）＝FIMからSynchronization Serviceを切り出して
AD、AADとの接続設定をプリセットしたもの
 既存のmiisclientを実は使える
 新バージョン（AAD Sync。現在ベータ版）では色々と改良されている
 AD上のアカウントのフィルタリング
 属性のマッピング変更
 マルチフォレスト対応
 扱えるオブジェクト数に限界があるので、大規模ユーザ（50万とか）ではAzure
AD Premium＋FIMのAAD Connector（FIMライセンスはついてくる）
40

関連用語
41
用語 解説
Metaverse FIM Sync Service の中央レポジトリ
Connector Space（CS） 各 ID Store 用のステージング領域
Management Agent
（MA）
各 CS のデータを実際の ID Store と接続するためのエージェント
Synchronization Metaverse と各 CS の間のデータを同期する（差分、フル）
Import 各 ID Store から対応する CS にデータを取り込む（差分、フル）
Export 各 CS から対応する ID Store にデータを出力する
Run Profile Import / Export / Synchronization の処理の定義

コア・アーキテクチャ
42
MetaverseMAID Store CS
CS
CS
CS
MA
MA
MA ID
Store
各ID Store用
のデータ
中央データ
ストア
同期 インポート
各ID Store用
の接続Agent エクスポート

ID連携の世界
クレームマッピング
ルール
認証ユーザとプロファイルのマッピング
ID プロバイダ SAML トークン
43
プロファイル
プロファイル
マッピングルールプロファイル
同期元
ディレクトリ同期の世界
認証されたユーザと
プロファイルの紐づけ
GUID nameIdentifier sourceAnchor
ImmutableId
displayName
sourceAnchor
displayName
displayName
GUID

アカウント管理
⇒Graph API
44

Graph とは？
 ソーシャルグラフ
 Thoughts on the Social Graph / Brad Fitzpatrick(ex-Six-Apart /
2007)
 http://bradfitz.com/social-graph-problem/
 人間関係図みたいなもの
 ノード：人間やアプリケーション、Webサイトなど
 エッジ：つながり（意味と方向性を持つ）
45

Graph
Tony Company1
website1Zakk
likeFriend
Employee
Employer
manage
ノード
エッジ
46

Graph API とは？
 Graph を操作するための API
 Facebook や Azure Active Directory がサポート
 RESTベース
 ノードの作成・検索やエッジの作成・検索などが可能
 例）Tonyさんの友達は？ ⇒ ZAKKさん
 例）TonyさんとZakkさんの関係は？ ⇒ 友達
47

何が良いのか？
 RESTベースなので簡単に実装できる⇒開発コストが安い
 SCIM はもっと標準化が進んでいるが。。（プロトコルとスキーマの標準化）
 Azure Active Directory の Graph API は Odata v3 準拠
 他のレポジトリに入っているユーザとの関係性を表現できる
 今のところ SCIM や LDAP は
 自身のレポジトリ内のオブジェクトとの関係しか表現できない
 関係性自体に意味を持たせられない
 クラウドとの親和性が高い ⇒ IDMaaSへの移行によるコスト低減の可能性
 プロトコル的にも、BYOI などの自由度的にも
48

Graphによるつながりの表現
 Multi dimensional protocol の必要性
 クラウドでは人、アプリケーションなどのオブジェクトが中央のディレクトリを
通じて連携しない
 関係性を柔軟に表現できる必要がある
 方向付けの表現（雇用と所属など）
person
organiz
ation
director
y
Apps
Servicesbelong
use
Apps
person
organiz
ation
Services
work
use
contract
49

ゆるく分散管理されたアイデンティティ
Private
Business
Company
Social
APL
Customer’s
Systems
Corporate
Systems
BYOIの許容
会社間での
協業
■自レポジトリ上の属性
- 氏名：Tony McAlpine
- 部署：Shrapnel 部
- 上司：Mike Varney
■取引先との関係
- Customerシステムを利用
■ソーシャルとの関係
- Facebook上のxxページの管理者
最低限の情報
管理
REST API
動的に関係性
を構築
50

Azure AD が Graph API を採用した理由
 Kim Cameron の blog（http://www.identityblog.com/?p=1222）
 It is because of the central importance of graph technology in being able to
manage connectedness - something that is at the core of the digital universe.
Treating the world as a graph allows us to have a unified approach to querying and
manipulating interconnected objects of many different kinds that exist in many
different relationships to each other.
 A directory has emerged that by August is projected to contain one billion users. True,
it's only one directory in a world with many directories (most agree too many). But
beyond the importance it achieves through its scale, it fundamentally changes what
it means to be a directory: it is a directory that surfaces a multi-dimensional network.
 This network isn't simply a network of devices or people. It's a network of people and
the actions they perform, the things they use and create, the things that are
important to them and the places they go. It's a network of relationships between
many meaningful things. And the challenge is now for all directories, in all domains,
to meet a new bar it has set.
51

Azure AD が Graph API を採用した理由
52

ユーザの作成
設定 値
エンドポイント https://graph.windows.net/{テナント名}/Users
メソッド POST
ヘッダ
Authorization 取得したアクセストークン
x-ms-dirapi-
data-contract-
version
APIバージョン
Content-Type application/atom+xml
ボディ
<entry xmlns="http://www.w3.org/2005/Atom"
xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices"
xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
<content type="application/xml">
<m:properties>
<d:ObjectType>User</d:ObjectType>
<d:AccountEnabled m:type="Edm.Boolean">true</d:AccountEnabled>
<d:DisplayName>織田信長</d:DisplayName>
<d:GivenName>信長</d:GivenName>
<d:Surname>織田</d:Surname>
<d:UserPrincipalName>nobunagao@＜テナントドメイン名＞.onmicrosoft.com</d:UserPrincipalName>
<d:MailNickname>nobunagao</d:MailNickname>
<d:Password>P@ssw0rd</d:Password>
</m:properties>
</content>
</entry>
53

属性の更新
設定 値
エンドポイント
https://graph.windows.net/advent2012.onmicrosoft.com/Users(‘＜対象ユーザ
名＞@＜テナントドメイン＞.onmicrosoft.com’)
メソッド PATCH
ヘッダ
Authorization 取得したアクセストークン
x-ms-dirapi-data-contract-
version
APIバージョン
Content-Type application/atom+xml
ボディ
<entry xmlns="http://www.w3.org/2005/Atom"
xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices"
xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metada
ta">
<content type="application/xml">
<m:properties>
<d:UsageLocation>JP </d:UsageLocation>
</m:properties>
</content>
</entry>
54

ライセンスの割り当て
設定 値
エンドポイント
https://directory.windows.net/＜取得したテナントドメイン
＞.onmicrosoft.com/Users('＜割り当てるユーザID＞@＜取得したテナントドメイン
＞.onmicrosoft.com')/AssignLicense
メソッド POST
ヘッダ
Authorization 取得したアクセストークン
x-ms-dirapi-data-
contract-version
APIバージョン
Content-Type application/json;odata=verbose;charset=utf-8
ボディ
{"AddLicenses":
[
{
"__metadata":
{"type":"Microsoft.WindowsAzure.ActiveDirectory.AssignedLicense"},
"DisabledPlans":
{"__metadata":
{"type":"Collection(Edm.Guid)"},
"results":[]},
"SkuId":"6fd2c87f-b296-42f0-b197-1e91e994b900"
}
],
"RemoveLicenses":null
55

他にも
 ユーザの削除
 グループ・連絡先などのオブジェクトの管理
 スキーマの拡張（Preview）
56

まとめ
57

まとめ
 ID連携は大事（特にクラウド環境では）
 パスワード分散のリスクを低減、利便性の向上
 Office365ではID連携、アカウント管理に標準プロトコルを使っている
 AD FS/ディレクトリ同期以外の選択肢もある
 設定によっては mixi アカウントでOffice365へログイン、なんてことも可能
 MSの想定ケースでは非AD環境（オンプレはLDAP）でOffice365を使う、なんてのも
 中身を知っておけばトラブルシューティングしやすい
 AD FSに関するトラブルの90%は設定のTYPO（by Laura E. Hunter / @adfskitteh）
 ID連携もアカウント管理もHTTPベースの通信なので通信フローをトレースすればだいたい
原因はわかる
58