2014年6月28日 .NETラボ「認証系を勉強する一日」で使ったスライド。 Azure ADのIdentity管理の話。OAuthでWebAPIを保護する方法、OpenID Connectへの対応状況など。

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

2. 自己紹介
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

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

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

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

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

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

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

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

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

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

12. ID連携（フェデレーション）をする理由
 認証システムの分散を防ぐ
 クレデンシャル（パスワード等）を保持する箇所を極小化する
 強度の高い認証システムで一括してアイデンティティ情報を保持・保
護する
 利便性を高める
 Cookieドメインを跨いだシングルサインオンの実現
12
クラウド活用のシナリオではドメインやネッ
トワークがセキュリティ境界ではなくなる
⇒Identity is the next perimeter

13. Identity is the next perimeter
13
FW
企業内ネットワーク（ドメイン）
企業内ネットワーク（ドメイン）
SaaS
アプリ
FW
悪い人
外出中
中の人
協業先
安全
安全 安全

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

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

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

17. Azure AD概要
17

18. Azure Active Directory構成概要
18

19. 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

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
20

21. 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

22. 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
22

23. OAuth 2.0 AuthZ code flow
23

24. Protected Resource登録（Web API）
 Azure ADアプリとして登録
 Manifest登録
 パーミッションの登録
24

25. OAuth Clientの登録
25
 Azure ADアプリとして登録
 他のアプリ（Protected
Resource）へのアクセス許可

26. 動作確認（認可コードの取得）
 OAuth認可エンドポイントへアクセス
 https://login.windows.net/{テナントID}
/oauth2/authorize?api-version=1.0
 パラメータ
 response_type : code
 client_id : （OAuth ClientのクライアントID）
26

27. アクセストークンの取得
 OAuthトークンエンドポイントへアクセス
 https://login.windows.net/{テナントID}/oauth2/token?api-version=1.0
 パラメータ
 grant_type : authorization_code
 client_id : （OAuth ClientのクライアントID）
 client_secret : （OAuth Clientのクライアントシークレット）
 code : 取得した認可コード
 resource : Protected Resourceのエンドポイント
27

28. アクセストークン（JWT）の中身
（https://developers.google.com/wallet/digital/docs/jwtdecoder）
{
"upn": "admin@nfujie.onmicrosoft.com",
"family_name": "¥u5c1a¥u5bdb",
"unique_name": "admin@nfujie.onmicrosoft.com",
"ver": "1.0",
"aud": "http://localhost:52941",
"acr": "1",
"iss": "https://sts.windows.net/25461....snip....f759/",
"oid": "020c15ea-1b….snip….ddcea6df",
"scp": "user_impersonation",
28
"appidacr": "1",
"given_name": "¥u5bcc¥u58eb¥u69ae",
"exp": 1403927033,
"appid": "9b8b91….snip…. 98afa177217",
"tid": "25461215-0c….snip….e6f3f759",
"iat": 1403923133,
"amr": [ "pwd" ],
"nbf": 1403923133,
"sub": "bqL0uiLls….snip…..8wUJ5M“
}

29. Protected Resourceへのアクセス
 APIエンドポイントへアクセス
 http://localhost:52941/Api/Values
 ヘッダ
 Authorization : Bearer ｛取得したアクセストークン｝
29

30. OpenID Connectサポート
 思想
 簡単なことは簡単に
 難しいことも可能に
 モジュラーデザイン
 実装
 OAuthのフローをベースに認証結果、属性（クレーム）のやり取りを行う
 id_tokenを利用（JSON Web Token）
30

31. id_token（JWT）
 ヘッダ
 署名アルゴリズム
 クレーム
 認証情報、人の属性
 署名
31
{
"x5t": "kriMPdmBvx68skT8-mPAB3BseeA",
"alg": "RS256",
"typ": "JWT"
}
{
"upn": "admin@nfujie.onmicrosoft.com",
"unique_name": "admin@nfujie.onmicrosoft.com",
"aud": "3803a5d1….snip….b22972ec1329",
"iss": "https://sts.windows.net/25ffc-..snip..f3f759/",
"exp": 1403932390,
"iat": 1403928490,
"amr": [ "pwd" ],
"nbf": 1403928490,
"sub": "xzLmdafwuzD5ifD2iQGZMRoWnz5a5U0KthBj2fRr690"
}

32. サポート・パラメータ 32
{
"issuer":"https://sts.windows.net/b9a84eb8-a888-4f41-bb75-43447e36486a/",
"authorization_endpoint":"https://login.windows.net/b9a84eb8-a888-4f41-bb75-43447e36486a/oauth2/authorize",
"token_endpoint":"https://login.windows.net/b9a84eb8-a888-4f41-bb75-43447e36486a/oauth2/token",
"token_endpoint_auth_methods_supported":["client_secret_post","private_key_jwt"],
"jwks_uri":"https://login.windows.net/common/discovery/keys",
"response_types_supported":["code","id_token","code id_token"],
"response_modes_supported":["query","fragment","form_post"],
"subject_types_supported":["pairwise"],
"scopes_supported":["openid"],
"id_token_signing_alg_values_supported":["RS256"],
"microsoft_multi_refresh_token":true,
"check_session_iframe":"https://login.windows.net/b9a84eb8-a888-4f41-bb75-43447e36486a/oauth2/checksession",
"end_session_endpoint":"https://login.windows.net/b9a84eb8-a888-4f41-bb75-43447e36486a/oauth2/logout"
}

33. ちょっとイレギュラー？
response_mode = form_post
<html>
<head>
<title>Working...</title>
</head>
<body>
<form method="POST" name="hiddenform" action="https://localhost:44307">
<input type="hidden" name="id_token" value="eyJ0eXAiOiJKV1QiLA....snip....fsmGwysr9XLbg" />
<input type="hidden" name="state" value="OpenIdConnect.AuthenticationProperties=XK..snip..Q" />
<input type="hidden" name="session_state" value="99..snip...47b2b" />
<noscript>
<p>Script is disabled. Click Submit to continue.</p>
<input type="submit" value="Submit" />
</noscript>
</form>
<script language="javascript">window.setTimeout('document.forms[0].submit()', 0);</script>
</body>
</html>
33
取得したid_tokenを
formでPOSTするHTMLで
認可エンドポイントが返却する

34. OpenID Connect（OWIN）
34

35. 35

36. 36

37. OWIN OpenIdConnect Middleware
app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions
{
Client_Id = "be6ddad6-3eca-433c-a00b-b5753c04c703",
Authority = "https://login.windows.net/nfujie.onmicrosoft.com",
Description = new Microsoft.Owin.Security.AuthenticationDescription()
{
Caption = "OpenID Connect"
}
});
37

38. OpenIdConnectAuthenticationNotifications
以下のイベントに応じて処理を記述
※今のところPOSTにしか反応しない。response_mode=form_postがデフォルトの理由？
（Fragmentの時は自分でPOSTし直すコードを書く必要あり）
 AccessCodeReceived
 AuthenticationFailed
 MessageReceived
 RedirectToIdentityProvider,
 SecurityTokenReceived
 SecurityTokenValidated
 SignedIn
 SignedOut
38

39. AccessCodeRecieved:code->token
Notifications = new OpenIdConnectAuthenticationNotifications()
{
AccessCodeReceived = (context) =>
{
var code = context.Code;
ClientCredential credential = new ClientCredential(clientId, appKey);
AuthenticationContext authContext = new AuthenticationContext(authority);
AuthenticationResult result = authContext.AcquireTokenByAuthorizationCode(
code, new Uri(HttpContext.Current.Request.Url.GetLeftPart(UriPartial.Path)),
credential, graphResourceId);
}
39

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

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

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

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

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

45. SAML トークン構造
 発行者（Issuer）
45
<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

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

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

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

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

50. SAML トークン構造
 認可決定ｱｻｰｼｮﾝ（AuthzDecisionStatement）
50
<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 を許可する例

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

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

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

54. 関連用語
54
用語 解説
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 の処理の定義

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

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

57. アカウント管理
⇒Graph API
57

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

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

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

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

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

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

64. 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.
64

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

66. ユーザの作成
設定 値
エンドポイント 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>
66

67. 属性の更新
設定 値
エンドポイント
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>
67

68. ライセンスの割り当て
設定 値
エンドポイント
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
68

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

70. まとめ
70

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