azure adとidentity管理
Post on 15-Jun-2015
5.352 Views
Preview:
DESCRIPTION
TRANSCRIPT
Azure ADと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アクセスの場合は？
Azure Active Directoryにおけるアイデンティティ管理
Azure AD概要（OAuth、OpenID Connect）
ID連携プロトコル（SAMLの例）
アカウント管理（FIM Sync）
アカウント管理（Graph API）
3
アイデンティティ管理の基礎Ⅰ
4
アイデンティティとは
“ID”から連想するよくある間違い
識別子（Identifier）
番号
ログインID
“ID”=“アイデンティティ”
実体（Entity）に関連する属性の集合/ISO/IEC 24760
5
アイデンティティの構成要素
要素 解説 例
属性 後天的に取得された主体に関わる情報（後から変化する）
名前、電話番号、社員番号、メールアドレス、認証状態、位置情報
好み 主体の嗜好に関わる情報 甘いものが好き
形質 主体の先天的な特有の性質（後から変化しにくい）
生年月日、性別？
関係性 他の主体との関係に関わる情報（一部属性と重複）
XX大学卒業、YY部所属
6
これらをコンピューターシステム上に反映したもの（コンピューターシステム上での実体を表すもの）
⇒デジタル・アイデンティティ
アイデンティティの構成要素：3A7
構成要素 意味
認証（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
クラウド活用のシナリオではドメインやネットワークがセキュリティ境界ではなくなる
⇒Identity is the next perimeter
Identity is the next perimeter
13
FW
企業内ネットワーク（ドメイン）
企業内ネットワーク（ドメイン）
SaaSアプリ
FW
悪い人
外出中
中の人
協業先
安全安全 安全
単純なシングルサインオン14
認証サーバアプリケーション アプリケーション
パスワードの分散
システム毎に認証
アプリケーション
パスワードの一元管理
認証Cookieの共有によるSSO
分散管理状態（SSO不可） 認証サーバの外だし、パスワードの一元管理、ドメイン内で認証Cookieを共有してSSO
ドメイン境界
ドメイン境界
ID連携（フェデレーション）15
認証サーバ アプリケーション
パスワードの一元管理
認証Cookieの共有によるSSO
認証サーバの外だし、パスワードの一元管理、ドメイン内で認証Cookieを共有してSSO
認証サーバ アプリケーション
パスワードの一元管理
認証サーバの外だし、パスワードの一元管理、ドメインを跨いだSSO
アプリケーションID連携サーバ
ID連携サーバを経由することによるドメイン間で認証Cookie変換
ドメイン境界
このあたりのやり取り方法を規定したものが
ws-federation/SAML/OpenID Connect
APIアクセス時の認証・認可16
認証サーバ アプリケーションバックエンドサービス
ユーザの代わりにアプリがサービスを利用
パスワードをアプリに渡したくはない
必要以上にアプリがサービスを使ってほしくない
認証サーバ アプリケーション認可サーババックエンドサービス
アクセストークンを使ってサービス利用
認可サーバで必要な権限に応じたアクセストークンを発行、ア
プリへ渡す
このあたりのやり取り方法を規定したものがOAuth
Azure AD概要
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 ServerRegister WebApps/API as protected resource
19
Identity Provider
Application
SAML-SP
Application
ws-fed RP
ApplicationOpenID
Connect RP
Microsoft
Account
Azure AD
Account
https://login.windows.com
3rd Party
SAML IdP
SAML
EndPoint
ws-fed
EndPoint
Ext IdPs
RPsHome
Realm
Discov
erOAuth2.0
AuthZ/Token
EndPoint
20
Identity Provider
Application
SAML-SP
Application
ws-fed RP
ApplicationOpenID
Connect RP
Microsoft
Account
Azure AD
Account
https://login.windows.com
3rd Party
SAML IdP
SAML
EndPoint
ws-fed
EndPoint
Ext IdPs
RPsHome
Realm
Discov
erOAuth2.0
AuthZ/Token
EndPoint
ws-
fed
ws-
fed
ws-
fedSAML
ws
res
SAML
SP
21
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
OAuth 2.0 AuthZ code flow
23
Protected Resource登録（Web API）
Azure ADアプリとして登録
Manifest登録
パーミッションの登録
24
OAuth Clientの登録25
Azure ADアプリとして登録
他のアプリ（Protected
Resource）へのアクセス許可
動作確認（認可コードの取得）
OAuth認可エンドポイントへアクセス
https://login.windows.net/{テナントID}
/oauth2/authorize?api-version=1.0
パラメータ
response_type : code
client_id : （OAuth ClientのクライアントID）
26
アクセストークンの取得
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
アクセストークン（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“
}
Protected Resourceへのアクセス
APIエンドポイントへアクセス
http://localhost:52941/Api/Values
ヘッダ
Authorization : Bearer ｛取得したアクセストークン｝
29
OpenID Connectサポート
思想
簡単なことは簡単に
難しいことも可能に
モジュラーデザイン
実装
OAuthのフローをベースに認証結果、属性（クレーム）のやり取りを行う
id_tokenを利用（JSON Web Token）
30
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
{
"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"
}
ちょっとイレギュラー？
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で認可エンドポイントが返却する
OpenID Connect（OWIN）34
35
36
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
OpenIdConnectAuthenticationNotifications
以下のイベントに応じて処理を記述
※今のところPOSTにしか反応しない。response_mode=form_postがデフォルトの理由？
（Fragmentの時は自分でPOSTし直すコードを書く必要あり）
AccessCodeReceived
AuthenticationFailed
MessageReceived
RedirectToIdentityProvider,
SecurityTokenReceived
SecurityTokenValidated
SignedIn
SignedOut
38
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
ID連携プロトコルSAML2.0の例
40
AD FSを使ってAzure ADとID連携をする場合はws-federationを使いますが、流れは似ているので、3rdパーティIdPを使う場合にサポートされているSAML2.0の例を解説します。
ID連携の流れ41
サービスへアクセス
認証要求を ID プロバイダへリダイレクト
認証
Service
ユーザ認証
トークン発行
ACS
トークンを POST
トークンの生成と署名
トークン署名の検証
サービスへリダイレクト
サービスを利用
※ACS : Assertion Consumer Service
ユーザ IDプロバイダ Azure AD
外部IdPに対するSPとして動く
Office365に対してはIdPとして動く⇒ID連携のChain
SAML
アーキテクチャ
SAML オーソリティの構造と AD FS
42
認証ｵｰｿﾘﾃｨ
認証ｱｻｰｼｮﾝ
属性ｵｰｿﾘﾃｨ
属性ｱｻｰｼｮﾝ
ﾎﾟﾘｼｰ決定ﾎﾟｲﾝﾄ
認可決定ｱｻｰｼｮﾝ
ﾎﾟﾘｼｰ実施ﾎﾟｲﾝﾄ
SAMLリクエスト
アクセス要求を受けたサーバ
ｸﾚﾃﾞﾝｼｬﾙ情報
アプリケーション要求
AD FS 2.0 の世界では認証ｵｰｿﾘﾃｨはAD DSのみ
属性ｵｰｿﾘﾃｨはAD DS/SQL/ｶｽﾀﾑﾎﾟﾘｼｰ決定ﾎﾟｲﾝﾄはAD DS/SQL/ｶｽﾀﾑ
SAML 2.0 の構成要素
構成要素 解説
トークン（アサーション）
IdP が発行するトークンでありアイデンティティ情報が記載されたもの
プロトコル アサーションを要求・返答するための方法
バインディング プロトコルを通信に乗せる方法（HTTP / SOAP /PAOS
など）
プロファイル プロトコルとバインディングとアサーションを組み合わせた方法
メタデータ プロトコルやサービスエンドポイントが記載されたもの
43
SAML トークン構造（※SAML2.0。1.1でも似たようなもの）
発行者（Issuer）
誰が、いつ発行したトークンなのか
識別子（Subject）
何（誰）に関するトークンなのか
受信者（AudienceRestriction）
誰宛に発行されたトークンなのか
アサーション（クレーム）
認証アサーション（AuthNStatement）
認証された時間、手段
属性アサーション（AttributeStatement）
属性情報（属性と値）
認可決定アサーション（AuthzDecisionStatement）
特定リソースへのアクセス許可されているか
デジタル署名
44
トークン
属性アサーション
認可決定アサーション
デジタル署名
認証アサーション
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
SAML トークン構造
識別子（Subject）
46
<saml:Subject>
<saml:NameID>
hoge@mygapps.com
</saml:NameID>
</saml:Subject>
フェデレーションにおけるアイデンティティの紐付け⇒アプリケーション（RP）はこの識別子の属性名および属性値が自身の保持するアイデンティティと一致することで紐付を行う。例）Office365 の場合、NameIdentifier 属性に入っている値（通常はGUIDをBASE64エンコードしたもの）が Azure AD 上のアカウントの ImmutableId と一致すればそのユーザに関する情報とみなす。
SAML トークン構造
受信者（AudienceRestriction）
47
<saml:AudienceRestriction>
<saml:Audience>google.com/a/mydomain</saml:Audience>
</saml:AudienceRestriction>
フェデレーションにおける事前信頼⇒アプリケーション（RP）はこの発行者情報（エンドポイントアドレス）およびトークンに付与されるデジタル署名の情報を登録する⇒AD FS 2.0 の「証明書利用者信頼の識別子」の URI
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 認証の場合
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 となる例
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 を許可する例
SAML トークン構造
デジタル署名
51
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">……（デジタル署名に関する情報）……
</ds:Signature>
フェデレーションにおける事前信頼⇒アプリケーション（RP）はこのデジタル署名に関する情報を事前に登録する⇒AD FS 2.0 のトークン署名証明書
アカウント管理
⇒FIM Sync
52
ディレクトリ同期ツール（DirSync）はFIMの限定版なので構造はFIM Syncと同じです。
ディレクトリ同期とFIM
ディレクトリ同期（DirSync）＝FIMからSynchronization Serviceを切り出してAD、AADとの接続設定をプリセットしたもの
既存のmiisclientを実は使える
新バージョン（AAD Sync。現在ベータ版）では色々と改良されている
AD上のアカウントのフィルタリング
属性のマッピング変更
マルチフォレスト対応
扱えるオブジェクト数に限界があるので、大規模ユーザ（50万とか）ではAzure
AD Premium＋FIMのAAD Connector（FIMライセンスはついてくる）
53
関連用語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
MetaverseMAID Store CS
CS
CS
CS
MA
MA
MA ID
Store
各ID Store用のデータ
中央データストア
同期 インポート
各ID Store用の接続Agent エクスポート
ID連携の世界
クレームマッピングルール
認証ユーザとプロファイルのマッピング
ID プロバイダ SAML トークン
56
プロファイル
プロファイルマッピングルールプロファイル
同期元
ディレクトリ同期の世界
認証されたユーザとプロファイルの紐づけ
GUID nameIdentifier sourceAnchor
ImmutableId
displayName
sourceAnchor
displayName
displayName
GUID
アカウント管理
⇒Graph API
57
Graph とは？
ソーシャルグラフ
Thoughts on the Social Graph / Brad Fitzpatrick(ex-Six-Apart /
2007)
http://bradfitz.com/social-graph-problem/
人間関係図みたいなもの
ノード：人間やアプリケーション、Webサイトなど
エッジ：つながり（意味と方向性を持つ）
58
Graph
Tony Company1
website1Zakk
likeFriend
Employee
Employer
manage
ノード
エッジ
59
Graph API とは？
Graph を操作するための API
Facebook や Azure Active Directory がサポート
RESTベース
ノードの作成・検索やエッジの作成・検索などが可能
例）Tonyさんの友達は？ ⇒ ZAKKさん
例）TonyさんとZakkさんの関係は？ ⇒ 友達
60
何が良いのか？
RESTベースなので簡単に実装できる⇒開発コストが安い
SCIM はもっと標準化が進んでいるが。。（プロトコルとスキーマの標準化）
Azure Active Directory の Graph API は Odata v3 準拠
他のレポジトリに入っているユーザとの関係性を表現できる
今のところ SCIM や LDAP は
自身のレポジトリ内のオブジェクトとの関係しか表現できない
関係性自体に意味を持たせられない
クラウドとの親和性が高い⇒ IDMaaSへの移行によるコスト低減の可能性
プロトコル的にも、BYOI などの自由度的にも
61
Graphによるつながりの表現
Multi dimensional protocol の必要性
クラウドでは人、アプリケーションなどのオブジェクトが中央のディレクトリを通じて連携しない
関係性を柔軟に表現できる必要がある
方向付けの表現（雇用と所属など）
person
organiz
ation
director
y
Apps
Servicesbelonguse
Appsperson
organiz
ation
Services
work
use
contract
62
ゆるく分散管理されたアイデンティティ
Private
Business
CompanySocial
APL
Customer’s
Systems
Corporate
Systems
BYOIの許容
会社間での協業
■自レポジトリ上の属性- 氏名：Tony McAlpine
- 部署：Shrapnel 部- 上司：Mike Varney
■取引先との関係- Customerシステムを利用■ソーシャルとの関係- Facebook上のxxページの管理者
最低限の情報管理
REST API
動的に関係性を構築
63
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
Azure AD が Graph API を採用した理由65
ユーザの作成設定 値
エンドポイント 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
属性の更新
設定 値
エンドポイントhttps://graph.windows.net/advent2012.onmicrosoft.com/Users(‘＜対象ユーザ名＞@＜テナントドメイン＞.onmicrosoft.com’)
メソッド PATCH
ヘッダ
Authorization 取得したアクセストークン
x-ms-dirapi-data-contract-
versionAPIバージョン
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
ライセンスの割り当て設定 値
エンドポイントhttps://directory.windows.net/＜取得したテナントドメイン＞.onmicrosoft.com/Users('＜割り当てるユーザID＞@＜取得したテナントドメイン＞.onmicrosoft.com')/AssignLicense
メソッド POST
ヘッダ
Authorization 取得したアクセストークン
x-ms-dirapi-data-
contract-versionAPIバージョン
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
他にも
ユーザの削除
グループ・連絡先などのオブジェクトの管理
スキーマの拡張（Preview）
69
まとめ
70
まとめ
ID連携は大事（特にクラウド環境では）
パスワード分散のリスクを低減、利便性の向上
Azure ADではID連携、アカウント管理に標準プロトコルを使っている
AD FS/ディレクトリ同期以外の選択肢もある
設定によってはmixiアカウントでOffice365へログイン、なんてことも可能
MSの想定ケースでは非AD環境（オンプレはLDAP）でOffice365を使う、なんてのも
中身を知っておけばトラブルシューティングしやすい
AD FSに関するトラブルの90%は設定のTYPO（by Laura E. Hunter / @adfskitteh）
ID連携もアカウント管理もHTTPベースの通信なので通信フローをトレースすればだいたい原因はわかる
71
top related