Office365のIdentity管理

12,319 views

Published on

Office365におけるアイデンティティ管理の話
SQL World 2014/06/21 大阪

Published in: Technology

Office365のIdentity管理

  1. 1. Office365とIdentity管理 MVP for Forefront Identity Manager Naohiro Fujie / @phr_eidentity / http://idmlab.eidentity.jp 1
  2. 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. 3. Agenda  アイデンティティ管理の基礎Ⅰ  アイデンティティとはなにか?関連キーワードと実装は?  アイデンティティ管理の基礎Ⅱ  ID連携(フェデレーション)が必要な理由は?APIアクセスの場合は?  Office365におけるアイデンティティ管理  Azure AD概要  ID連携プロトコル(SAMLの例)  アカウント管理(FIM Sync)  アカウント管理(Graph API) 3
  4. 4. アイデンティティ 管理の基礎Ⅰ 4
  5. 5. アイデンティティとは “ID”から連想するよくある間違い 識別子(Identifier) 番号 ログインID “ID”=“アイデンティティ” 実体(Entity)に関連する属性の集合/ISO/IEC 24760 5
  6. 6. アイデンティティの構成要素 要素 解説 例 属性 後天的に取得された主体に関わる情 報(後から変化する) 名前、電話番号、社員番号、 メールアドレス、認証状態、 位置情報 好み 主体の嗜好に関わる情報 甘いものが好き 形質 主体の先天的な特有の性質 (後から変化しにくい) 生年月日、性別? 関係性 他の主体との関係に関わる情報(一 部属性と重複) XX大学卒業、YY部所属 6 これらをコンピューターシステム上に反映したもの (コンピューターシステム上での実体を表すもの) ⇒ デジタル・アイデンティティ
  7. 7. アイデンティティの構成要素:3A 7 構成要素 意味 認証(Authentication) ユーザの正当性を検証すること (ユーザがデジタル・アイデンティティを利用する 権利があることを検証する) 認可(Authorization) 認証されたユーザに権限を与えること (デジタル・アイデンティティに何を許可するかを 決定する) 属性(Attribute) ユーザを構成する情報 (何でデジタル・アイデンティティを構成するかを 決定する) ※注)大前提として、デジタル・アイデンティティの正当性の保証を行うことが大切である (実体に紐づく属性の精度・鮮度の保証、存在の確認など)
  8. 8. 実装と管理  実装手段  認証:パスワード、証明書、OTP、リスクベース  認可:リソース(フォルダ等)へのアクセス権付与  属性:ユーザ DB の整備(AD、DBMSなど)  分散システムにおける管理手段  アカウント管理(プロビジョニング)  オーソリティ(人事DB等)にある属性情報を他システムへ反映する  ID連携(フェデレーション)  認証状態などを含むアイデンティティ情報をシステム間で受け渡す  受け取ったシステム側に保持しているアイデンティティ情報と渡された情報を紐付けることで シングルサインオンなどを実現する 8
  9. 9. 実装例:アカウント管理 (プロビジョニング) 9 ユーザ 利用 対象システム ID管理システム人事DB 入社、異動、退社 などのイベントに 合わせて人事情報 を取込み 利用ポリシーに合 わせて各システム へ ID を配布 各システム間のアイ デンティティ情報の 整合性を担保
  10. 10. 事前信頼指定 実装例:ID連携(フェデレーション) 10 認証サーバ Identity Provider / IdP アプリケーション (Relying Party / RP) ①アクセス ②認証状態チェック ③リダイレクト ④認証指示 ⑤認証 ⑥トークン発行 ユーザ 信頼できるサーバから 発行されたトークンの 中のID情報を自前のID 情報と紐付ける ⇒SSOの実現
  11. 11. アイデンティティ 管理の基礎Ⅱ 11
  12. 12. ID連携(フェデレーション)をする理由  認証システムの分散を防ぐ  クレデンシャル(パスワード等)を保持する箇所を極小化する  強度の高い認証システムで一括してアイデンティティ情報を保持・保 護する  利便性を高める  Cookieドメインを跨いだシングルサインオンの実現 12
  13. 13. 単純なシングルサインオン 13 認証サーバアプリケーション アプリケーション パスワードの分散 システム毎に認証 アプリケーション パスワードの一元管理 認証Cookieの共有に よるSSO 分散管理状態(SSO不可) 認証サーバの外だし、パスワードの一元管理、 ドメイン内で認証Cookieを共有してSSO ドメイン境界
  14. 14. ドメイン境界 ID連携(フェデレーション) 14 認証サーバ アプリケーション パスワードの一元管理 認証Cookieの共有に よるSSO 認証サーバの外だし、パスワードの一元管理、 ドメイン内で認証Cookieを共有してSSO 認証サーバ アプリケーション パスワードの一元管理 認証サーバの外だし、パスワードの一元管理、 ドメインを跨いだSSO アプリケーション ID連携 サーバ ID連携サーバを経由す ることによるドメイン 間で認証Cookie変換 ドメイン境界 このあたりのやり取り方法を規定したものが ws-federation/SAML/OpenID Connect
  15. 15. APIアクセス時の認証・認可 15 認証サーバ アプリケーション バックエンド サービス ユーザの代わりにアプ リがサービスを利用 パスワードをアプリに 渡したくはない 必要以上にアプリがサー ビスを使ってほしくない 認証サーバ アプリケーション認可サーバ バックエンド サービス アクセストークンを 使ってサービス利用 認可サーバで必要な権限に応じ たアクセストークンを発行、ア プリへ渡す このあたりのやり取り方法を規定したもの がOAuth
  16. 16. Office365の アイデンティティ ⇒Azure AD概要 16
  17. 17. 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
  18. 18. Azure Active Directory構成概要 18
  19. 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. 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. 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. 22. Sequence 22
  23. 23. 23
  24. 24. 24
  25. 25. 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
  26. 26. 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
  27. 27. ID連携プロトコル SAML2.0の例 27 AD FSを使ってAzure ADとID連携をする場合は ws-federationを使いますが、流れは似ている ので、3rdパーティIdPを使う場合にサポートさ れているSAML2.0の例を解説します。
  28. 28. ID連携の流れ 28 サービスへアクセス 認証要求を ID プロバイダ へリダイレクト 認証 Service ユーザ認証 トークン発行 ACS トークンを POST トークンの 生成と署名 トークン署名 の検証 サービスへリダイレクト サービスを利用 ※ACS : Assertion Consumer Service ユーザ IDプロバイダ Azure AD 外部IdPに対するSPと して動く Office365に対しては IdPとして動く ⇒ID連携のChain
  29. 29. SAML アーキテクチャ  SAML オーソリティの構造と AD FS 29 認証 オーソリティ 認証 アサーション 属性 オーソリティ 属性 アサーション ポリシー決 定ポイント 認可決定 アサーション ポリシー実 施ポイント SAMLリ クエス ト アクセス要求を 受けたサーバ クレデンシャル 情報 アプリケーション要求 AD FS 2.0 の世界では 認証オーソリティはAD DSのみ 属性オーソリティはAD DS/SQL/カスタム ポリシー決定ポイントはAD DS/SQL/カスタム
  30. 30. SAML 2.0 の構成要素 構成要素 解説 トークン(アサー ション) IdP が発行するトークンでありアイデンティティ情報が 記載されたもの プロトコル アサーションを要求・返答するための方法 バインディング プロトコルを通信に乗せる方法(HTTP / SOAP /PAOS など) プロファイル プロトコルとバインディングとアサーションを組み合わ せた方法 メタデータ プロトコルやサービスエンドポイントが記載されたもの 30
  31. 31. SAML トークン構造(※SAML2.0。1.1でも似たようなもの)  発行者(Issuer)  誰が、いつ発行したトークンなのか  識別子(Subject)  何(誰)に関するトークンなのか  受信者(AudienceRestriction)  誰宛に発行されたトークンなのか  アサーション(クレーム)  認証アサーション(AuthNStatement)  認証された時間、手段  属性アサーション(AttributeStatement)  属性情報(属性と値)  認可決定アサーション(AuthzDecisionStatement)  特定リソースへのアクセス許可されているか  デジタル署名 31 トークン 属性アサーション 認可決定アサーション デジタル署名 認証アサーション
  32. 32. 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
  33. 33. SAML トークン構造  識別子(Subject) 33 <saml:Subject> <saml:NameID> hoge@mygapps.com </saml:NameID> </saml:Subject> フェデレーションにおけるアイデンティティの紐付け ⇒アプリケーション(RP)はこの識別子の属性名および属性値が自身の保持するアイデンティティと一致す ることで紐付を行う。 例)Office365 の場合、NameIdentifier 属性に入っている値(通常はGUIDをBASE64エンコードしたもの) が Azure AD 上のアカウントの ImmutableId と一致すればそのユーザに関する情報とみなす。
  34. 34. SAML トークン構造  受信者(AudienceRestriction) 34 <saml:AudienceRestriction> <saml:Audience>google.com/a/mydomain</saml:Audience> </saml:AudienceRestriction> フェデレーションにおける事前信頼 ⇒アプリケーション(RP)はこの発行者情報(エンドポイントアドレス)およびトークンに付与されるデジ タル署名の情報を登録する ⇒AD FS 2.0 の「証明書利用者信頼の識別子」の URI
  35. 35. 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 認証の場合
  36. 36. 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 となる例
  37. 37. 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 を許可する例
  38. 38. SAML トークン構造  デジタル署名 38 <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> ……(デジタル署名に関する情報)…… </ds:Signature> フェデレーションにおける事前信頼 ⇒アプリケーション(RP)はこのデジタル署名に関する情報を事前に登録する ⇒AD FS 2.0 のトークン署名証明書
  39. 39. アカウント管理 ⇒FIM Sync 39 ディレクトリ同期ツール(DirSync)はFIMの限 定版なので構造はFIM Syncと同じです。
  40. 40. ディレクトリ同期とFIM  ディレクトリ同期(DirSync)=FIMからSynchronization Serviceを切り出して AD、AADとの接続設定をプリセットしたもの  既存のmiisclientを実は使える  新バージョン(AAD Sync。現在ベータ版)では色々と改良されている  AD上のアカウントのフィルタリング  属性のマッピング変更  マルチフォレスト対応  扱えるオブジェクト数に限界があるので、大規模ユーザ(50万とか)ではAzure AD Premium+FIMのAAD Connector(FIMライセンスはついてくる) 40
  41. 41. 関連用語 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. 42. コア・アーキテクチャ 42 MetaverseMAID Store CS CS CS CS MA MA MA ID Store 各ID Store用 のデータ 中央データ ストア 同期 インポート 各ID Store用 の接続Agent エクスポート
  43. 43. ID連携の世界 クレームマッピング ルール 認証ユーザとプロファイルのマッピング ID プロバイダ SAML トークン 43 プロファイル プロファイル マッピングルールプロファイル 同期元 ディレクトリ同期の世界 認証されたユーザと プロファイルの紐づけ GUID nameIdentifier sourceAnchor ImmutableId displayName sourceAnchor displayName displayName GUID
  44. 44. アカウント管理 ⇒Graph API 44
  45. 45. Graph とは?  ソーシャルグラフ  Thoughts on the Social Graph / Brad Fitzpatrick(ex-Six-Apart / 2007)  http://bradfitz.com/social-graph-problem/  人間関係図みたいなもの  ノード:人間やアプリケーション、Webサイトなど  エッジ:つながり(意味と方向性を持つ) 45
  46. 46. Graph Tony Company1 website1Zakk likeFriend Employee Employer manage ノード エッジ 46
  47. 47. Graph API とは?  Graph を操作するための API  Facebook や Azure Active Directory がサポート  RESTベース  ノードの作成・検索やエッジの作成・検索などが可能  例)Tonyさんの友達は? ⇒ ZAKKさん  例)TonyさんとZakkさんの関係は? ⇒ 友達 47
  48. 48. 何が良いのか?  RESTベースなので簡単に実装できる⇒開発コストが安い  SCIM はもっと標準化が進んでいるが。。(プロトコルとスキーマの標準化)  Azure Active Directory の Graph API は Odata v3 準拠  他のレポジトリに入っているユーザとの関係性を表現できる  今のところ SCIM や LDAP は  自身のレポジトリ内のオブジェクトとの関係しか表現できない  関係性自体に意味を持たせられない  クラウドとの親和性が高い ⇒ IDMaaSへの移行によるコスト低減の可能性  プロトコル的にも、BYOI などの自由度的にも 48
  49. 49. Graphによるつながりの表現  Multi dimensional protocol の必要性  クラウドでは人、アプリケーションなどのオブジェクトが中央のディレクトリを 通じて連携しない  関係性を柔軟に表現できる必要がある  方向付けの表現(雇用と所属など) person organiz ation director y Apps Servicesbelong use Apps person organiz ation Services work use contract 49
  50. 50. ゆるく分散管理されたアイデンティティ Private Business Company Social APL Customer’s Systems Corporate Systems BYOIの許容 会社間での 協業 ■自レポジトリ上の属性 - 氏名:Tony McAlpine - 部署:Shrapnel 部 - 上司:Mike Varney ■取引先との関係 - Customerシステムを利用 ■ソーシャルとの関係 - Facebook上のxxページの管理者 最低限の情報 管理 REST API 動的に関係性 を構築 50
  51. 51. 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
  52. 52. Azure AD が Graph API を採用した理由 52
  53. 53. ユーザの作成 設定 値 エンドポイント 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
  54. 54. 属性の更新 設定 値 エンドポイント 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
  55. 55. ライセンスの割り当て 設定 値 エンドポイント 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
  56. 56. 他にも  ユーザの削除  グループ・連絡先などのオブジェクトの管理  スキーマの拡張(Preview) 56
  57. 57. まとめ 57
  58. 58. まとめ  ID連携は大事(特にクラウド環境では)  パスワード分散のリスクを低減、利便性の向上  Office365ではID連携、アカウント管理に標準プロトコルを使っている  AD FS/ディレクトリ同期以外の選択肢もある  設定によっては mixi アカウントでOffice365へログイン、なんてことも可能  MSの想定ケースでは非AD環境(オンプレはLDAP)でOffice365を使う、なんてのも  中身を知っておけばトラブルシューティングしやすい  AD FSに関するトラブルの90%は設定のTYPO(by Laura E. Hunter / @adfskitteh)  ID連携もアカウント管理もHTTPベースの通信なので通信フローをトレースすればだいたい 原因はわかる 58

×