Windows Phone アプリケーション開発支援セミナー~ 認証と認可の仕組み実装する<br />2011年8月19日<br />第01版<br />日本マイクロソフト株式会社<br />エバンジェリスト<br />安納 順一<br />h...
アプリケーション<br />Twitter<br />利用者<br />いきなりですが 意味 わかりますか?<br />アプリ利用開始<br />Request Token を要求<br />Redirect<br />Request Toke...
本日の内容<br />企業内システム と ソーシャルアプリの思想の違いから発生する、認証および認可の考え方とアーキテクチャの違いについて理解しましょう<br />Windows Azure AppFabric ACS が Windows Pho...
Agenda<br />認証と認可を取り巻くトレンド<br />企業システムとソーシャルアプリの違い<br />何を認可するのか?<br />Windows Phone への実装<br />Twitter を使用するためのコーディング例<br ...
登場人物と相関図<br />サービスの利用者<br />アプリを使いたい人<br />サービス<br />(Twitter, Facebook 等)<br />利用している<br />使いたい<br />自分のもの<br />アクセスしたい<b...
認証と認可を取り巻くトレンド<br />ここを理解すること<br />
認証と認可<br />認証:本人であることを確認<br />認可:アクセス権を与えること<br />認証<br />認可<br />どんなシステムにも「認証」と「認可」はつきまとう<br />「認可」に関するプロトコルが注目を浴びている<br />
なぜ「認可」に注目が?<br />システム間の連携(主に SSO)<br />アイデンティティ・フェデレーション<br />クレームベース セキュリティ<br />クラウドへの移行<br />社内ディレクトリサービスの活用<br />ソーシャル...
OAuthと SAML の違い<br /><ul><li>いずれも認可をするためのプロトコル
認可プロセスの中に(必然的に)認証が含まれる
OAuth:「API へのアクセス」を「利用者が」認可する
SAML  :「情報の送出」を「管理者が」認可する
現在はSAML 対応製品のほうが細かな制御ができる</li></ul>システム管理者<br />事前に<br />環境設定<br />SAML<br />IdP<br />承認<br />要求「情報が欲しい!」<br />応答「氏名、メアド.....
企業内システムとソーシャルアプリの違い<br />企業内システム<br />システム間で「信頼」が担保されている<br />アプリケーションを認証する必要は無い<br />認証と認可の対象は「利用者」<br />SNS および ソーシャルアプリ...
なぜ ソーシャルアプリ は複雑なのか<br />「システム」と「情報」と「アプリ」の持ち主が異なる<br />アプリは「人」の認可を受けて、初めて「情報」にアクセス可能<br />特定アプリへの情報公開<br />広範囲な漏えいからの保護<br...
アプリから情報へのアクセスを認可する方法 ①<br />アプリに ID と Password を渡してしまう<br /><ul><li>アプリは信頼できる?
パスワードが変わったら?</li></ul>UserID<br />Password<br />自分のもの<br />アクセス<br />
アプリから情報へのアクセスを認可する方法 ②<br />情報にアクセスするための 「API へのアクセス権」を与える<br />利用者は自身の判断でいつでもアクセス権をはく奪できる<br />Lv1認可<br />自分のもの<br />API<...
“API へのアクセスを認可する” とは?<br />外部のアプリケーションに対し、<br />各種情報にアクセスするためのAPIの利用を認可する仕組み<br />Identity&Service Provider<br />(Twitter/...
Twitter クライアントを作成する<br />Windows Phone への実装<br />
Twitter ~ OAuth 1.0a の場合<br />アプリケーション<br />Twitter<br />利用者<br />アプリ利用開始<br />Request Token を要求<br />/request_token<br />...
Facebook ~ OAuth 2.0 の場合<br />アプリケーション<br />Facebook<br />利用者<br />アプリ利用開始<br />認証/認可画面へRedirect<br />認証/認可 画面表示<br />認証/認...
Twitter アプリ サンプルコード<br />BLOGにプロジェクトをアップロードしておきます<br />(参考)<br />Building a ‘real’ Windows Phone 7 Twitter App Part 2 - oA...
OAuth 1.0a のポイント<br />Request Token と AccessToken<br />Request Token:Access Token を取得するためのトークン<br />Access Token:API にアクセス...
ちなみに OpenID とは?<br /><ul><li>認証のためのプロトコル
どの OpenIDProvider(OP)の ID を使用してもRPにログオンできる
OP と RP の信頼は必須ではない(必要であれば RP で独自に実装する)
OAuth2.0 ベースの OpenID Connect のリリースも控えている</li></ul>OP<br />OP<br />OP<br />SSO<br />OP<br />OP<br />RP<br />RP<br />RP<br />
OpenIDと OAuthの違い<br />お勧め:非技術者のためのOAuth認証(?)とOpenIDの違い入門    http://www.sakimura.org/2011/05/1087/<br />by 崎村さん(OpenID Foun...
RP ごとにID/Password が異なる不便を回避
どの OP で認証しても RP にアクセスできる
OAuthは API へのアクセス認可のためのプロトコル
アプリケーションやWEBサイトに、ユーザーIDとパスワードを渡す必要が無い</li></li></ul><li>OAuthを「認証」に使うことの危険性<br />OAuthは「APIアクセスを認可」するためのプロトコル<br />認可された A...
複数 IdP に対応させる<br />Windows Phone への実装<br />
インターネットにはIdP がいっぱい<br />
個別に対応すると大変...orz<br />AccessToken<br />IdP<br />ここで複数IdPに対応<br />Windows Live<br />Google<br />Yahoo!<br />Facebook<br />O...
Windows Azure AppFabric ACS を使うと...<br />IdP<br />アプリは AppFabric ACS にだけ対応すればよい<br />Windows Live<br />Google<br />Yahoo!<...
Windows Azure AppFabricAccess Control ServiceV2<br />クラウド上に用意された STS<br />アプリケーションのコードを変更することなく、新たな Identity Provider と<br...
WS-Federation
WS-Trust
OAuth 2.0 (Draft 13)
Upcoming SlideShare
Loading in …5
×

Windows Phone アプリに認証と認可を実装する V1.0

3,218 views

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,218
On SlideShare
0
From Embeds
0
Number of Embeds
33
Actions
Shares
0
Downloads
53
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Windows Phone アプリに認証と認可を実装する V1.0

  1. 1. Windows Phone アプリケーション開発支援セミナー~ 認証と認可の仕組み実装する<br />2011年8月19日<br />第01版<br />日本マイクロソフト株式会社<br />エバンジェリスト<br />安納 順一<br />http://blogs.technet.com/junichia/<br />twitter @junichia<br />
  2. 2. アプリケーション<br />Twitter<br />利用者<br />いきなりですが 意味 わかりますか?<br />アプリ利用開始<br />Request Token を要求<br />Redirect<br />Request Token 発行<br />認証/認可の画面を要求<br />認証/認可 画面表示<br />認証/認可を完了<br />CallBackurlにRedirect<br />Access Token 要求<br />Access Token 発行<br />API 呼び出し<br />API<br />
  3. 3. 本日の内容<br />企業内システム と ソーシャルアプリの思想の違いから発生する、認証および認可の考え方とアーキテクチャの違いについて理解しましょう<br />Windows Azure AppFabric ACS が Windows Phone アプリに与えるインパクトを理解しましょう<br />IAM テクノロジーに萌えましょう<br />
  4. 4. Agenda<br />認証と認可を取り巻くトレンド<br />企業システムとソーシャルアプリの違い<br />何を認可するのか?<br />Windows Phone への実装<br />Twitter を使用するためのコーディング例<br />OAuth 1.0aへの対応<br />Windows Azure AppFabric ACS を使用したコーディング例<br />複数 IdPへの一括対応<br />まとめ<br />
  5. 5. 登場人物と相関図<br />サービスの利用者<br />アプリを使いたい人<br />サービス<br />(Twitter, Facebook 等)<br />利用している<br />使いたい<br />自分のもの<br />アクセスしたい<br />サービスに保存されている個人情報<br />個人情報にアクセスしたいアプリ<br />
  6. 6. 認証と認可を取り巻くトレンド<br />ここを理解すること<br />
  7. 7. 認証と認可<br />認証:本人であることを確認<br />認可:アクセス権を与えること<br />認証<br />認可<br />どんなシステムにも「認証」と「認可」はつきまとう<br />「認可」に関するプロトコルが注目を浴びている<br />
  8. 8. なぜ「認可」に注目が?<br />システム間の連携(主に SSO)<br />アイデンティティ・フェデレーション<br />クレームベース セキュリティ<br />クラウドへの移行<br />社内ディレクトリサービスの活用<br />ソーシャルな IdP の活用<br />ソーシャルアプリの台頭<br />個人情報の保護<br />SAML<br />OAuth<br />
  9. 9. OAuthと SAML の違い<br /><ul><li>いずれも認可をするためのプロトコル
  10. 10. 認可プロセスの中に(必然的に)認証が含まれる
  11. 11. OAuth:「API へのアクセス」を「利用者が」認可する
  12. 12. SAML :「情報の送出」を「管理者が」認可する
  13. 13. 現在はSAML 対応製品のほうが細かな制御ができる</li></ul>システム管理者<br />事前に<br />環境設定<br />SAML<br />IdP<br />承認<br />要求「情報が欲しい!」<br />応答「氏名、メアド...」<br />アプリケーション<br />承認<br />ユーザーの情報<br />その都度<br />OAuth<br />利用者(情報の持ち主)<br />
  14. 14. 企業内システムとソーシャルアプリの違い<br />企業内システム<br />システム間で「信頼」が担保されている<br />アプリケーションを認証する必要は無い<br />認証と認可の対象は「利用者」<br />SNS および ソーシャルアプリ<br />システム間の「信頼」は担保されていない<br />信頼関係のない者同志の認証と認可が必須<br />「サービス」と「人」<br />「サービス」と「アプリ」<br />「人」と「アプリ」<br />「情報」と「アプリ」<br />登場人物が多い!<br />
  15. 15. なぜ ソーシャルアプリ は複雑なのか<br />「システム」と「情報」と「アプリ」の持ち主が異なる<br />アプリは「人」の認可を受けて、初めて「情報」にアクセス可能<br />特定アプリへの情報公開<br />広範囲な漏えいからの保護<br />企業システム<br />主にシステム / 管理者<br />ソーシャルアプリ<br />主にシステム<br />情報の持ち主<br />
  16. 16. アプリから情報へのアクセスを認可する方法 ①<br />アプリに ID と Password を渡してしまう<br /><ul><li>アプリは信頼できる?
  17. 17. パスワードが変わったら?</li></ul>UserID<br />Password<br />自分のもの<br />アクセス<br />
  18. 18. アプリから情報へのアクセスを認可する方法 ②<br />情報にアクセスするための 「API へのアクセス権」を与える<br />利用者は自身の判断でいつでもアクセス権をはく奪できる<br />Lv1認可<br />自分のもの<br />API<br />(Lv1)<br />API<br />(Lv2)<br />アクセス<br />API<br />(Lv3)<br />
  19. 19. “API へのアクセスを認可する” とは?<br />外部のアプリケーションに対し、<br />各種情報にアクセスするためのAPIの利用を認可する仕組み<br />Identity&Service Provider<br />(Twitter/Facebook/Google 等)<br />ユーザー情報<br />① アプリ登録<br />各種特権<br />氏名を閲覧<br />アプリ<br />API Lv1<br />メールアドレスを閲覧<br />API Lv2<br />③ APIにアクセス<br />投稿を閲覧<br />API Lv3<br />つながりを閲覧<br />API Lv4<br />② アクセス認可<br />近況を投稿<br />つながりを編集<br />属性の主体<br />(持ち主)<br />
  20. 20. Twitter クライアントを作成する<br />Windows Phone への実装<br />
  21. 21. Twitter ~ OAuth 1.0a の場合<br />アプリケーション<br />Twitter<br />利用者<br />アプリ利用開始<br />Request Token を要求<br />/request_token<br />Redirect<br />Request Token 発行<br />認証/認可の画面を要求<br />/authorize<br />認証/認可 画面表示<br />認証/認可を完了<br />CallBackurlにRedirect<br />Access Token 要求<br />/Access_token<br />Access Token 発行<br />API 呼び出し<br />API<br />
  22. 22. Facebook ~ OAuth 2.0 の場合<br />アプリケーション<br />Facebook<br />利用者<br />アプリ利用開始<br />認証/認可画面へRedirect<br />認証/認可 画面表示<br />認証/認可を完了<br />CallBackurlにRedirect<br />認可コードを発行<br />Access Token 要求<br />Access Token 発行<br />API 呼び出し<br />API<br />
  23. 23. Twitter アプリ サンプルコード<br />BLOGにプロジェクトをアップロードしておきます<br />(参考)<br />Building a ‘real’ Windows Phone 7 Twitter App Part 2 - oAuthhttp://samjarawan.blogspot.com/2010/09/building-real-windows-phone-7-twitter_18.html<br />※Phone アプリを一から勉強するのに最適!<br />使用している OAuthライブラリ<br /><ul><li>Hammock.dll(hammock.codeplex.com)</li></li></ul><li>Twitter(OAuth 1.0a)での認可に必要な情報<br />開発者サイトにアプリを登録すると提示される<br />(参考)https://dev.twitter.com/docs/api/<br />ConsumerKey= "NsO5AFDsI0mzKD---------";<br />ConsumerKeySecret= "wE8aiRp1cbj4bb7wAf8onWbOQXhc--------";<br />RequestTokenUri= "https://api.twitter.com/oauth/request_token";<br />AuthorizeUri= "https://api.twitter.com/oauth/authorize";<br />AccessTokenUri= "https://api.twitter.com/oauth/access_token";<br />CallbackUri = "http://www.bing.com";<br />
  24. 24. OAuth 1.0a のポイント<br />Request Token と AccessToken<br />Request Token:Access Token を取得するためのトークン<br />Access Token:API にアクセスするためのトークン<br />Callback Url<br />OAuth 1.0a では必須<br />最終的に戻したいアプリケーションのURL<br />デスクトップアプリの場合はダミーURLを入れて、リダイレクトをキャンセル<br />※xAuthではデスクトップアプリに対応<br />
  25. 25. ちなみに OpenID とは?<br /><ul><li>認証のためのプロトコル
  26. 26. どの OpenIDProvider(OP)の ID を使用してもRPにログオンできる
  27. 27. OP と RP の信頼は必須ではない(必要であれば RP で独自に実装する)
  28. 28. OAuth2.0 ベースの OpenID Connect のリリースも控えている</li></ul>OP<br />OP<br />OP<br />SSO<br />OP<br />OP<br />RP<br />RP<br />RP<br />
  29. 29. OpenIDと OAuthの違い<br />お勧め:非技術者のためのOAuth認証(?)とOpenIDの違い入門    http://www.sakimura.org/2011/05/1087/<br />by 崎村さん(OpenID Foundation)<br /><ul><li>OpenID はユーザー認証のためのプロトコル
  30. 30. RP ごとにID/Password が異なる不便を回避
  31. 31. どの OP で認証しても RP にアクセスできる
  32. 32. OAuthは API へのアクセス認可のためのプロトコル
  33. 33. アプリケーションやWEBサイトに、ユーザーIDとパスワードを渡す必要が無い</li></li></ul><li>OAuthを「認証」に使うことの危険性<br />OAuthは「APIアクセスを認可」するためのプロトコル<br />認可された API は使い放題!<br />家の鍵を預けるようなもの(崎村氏)<br />Twitter の場合<br />ここまでの権限が本当に必要?<br />
  34. 34. 複数 IdP に対応させる<br />Windows Phone への実装<br />
  35. 35. インターネットにはIdP がいっぱい<br />
  36. 36. 個別に対応すると大変...orz<br />AccessToken<br />IdP<br />ここで複数IdPに対応<br />Windows Live<br />Google<br />Yahoo!<br />Facebook<br />OpenID<br />AD FS 2.0<br />RESTful Web Service<br />AccessToken の正当性に不安<br />改ざんされているかも!?<br />Application<br />
  37. 37. Windows Azure AppFabric ACS を使うと...<br />IdP<br />アプリは AppFabric ACS にだけ対応すればよい<br />Windows Live<br />Google<br />Yahoo!<br />Facebook<br />OpenID<br />Request Token<br />AD FS 2.0<br />RESTful Web Service<br />信頼<br />Access<br />Token<br />信頼<br />Application<br />Windows AzureAppFabric ACS<br />
  38. 38. Windows Azure AppFabricAccess Control ServiceV2<br />クラウド上に用意された STS<br />アプリケーションのコードを変更することなく、新たな Identity Provider と<br />連携することができる<br />サポートされているプロトコル<br /><ul><li>OAuth WRAP 2.0
  39. 39. WS-Federation
  40. 40. WS-Trust
  41. 41. OAuth 2.0 (Draft 13)
  42. 42. OpenID 2.0</li></ul>トークンフォーマット<br /><ul><li>Simple Web Token(SWT)
  43. 43. SAML 1.1/2.0</li></ul>既成の Identity Provider との Passive な連携<br /><ul><li>Windows Live ID/ Google/ Facebool/ Yahoo!(.com)/ OpenID
  44. 44. Active Directory Federation Service 2.0</li></li></ul><li>コーディング例<br />Windows Azure Toolkit for Windows Phone 7└ WindowsPhoneCloud.ACS<br />詳細な使用方法をBLOGにまとめますのでお待ちを<br />
  45. 45. WindowsPhoneCloud.ACSで使われているオリジナルライブラリ<br />AspProviders: Windows Azure Tables 用の ASP.NET Providers (Membership, Roles, Profile and Session State Store)<br />System.Data.Services.Client: Windows Phone 用の OData client library (http://odata.codeplex.com)。Azure Tables へのアクセスで使用。<br />WindowsPhoneCloud.StorageClient: Windows Phone 用の Windows Azure Storage Client library .<br />DPE.OAuth: Microsoft DPE OAuth2 library.<br />SL.Phone.Federation: Microsoft Silverlight ACS sign in control.<br />Notification Services (MPNS): Tile, Toast, and Raw.<br />WindowsPhone.Recipes.Push.Messages: Push Notification Server Side Helper Library, a part of the Windows Phone 7 Push Recipe, that provides an easy way to send all three types of push notification messages that are currently supported by Microsoft Push<br />Windows Phone では WIF(Windows Identity Foundation)がサポートされていないため、とても便利!<br />
  46. 46. WindowsPhoneCloud.ACS がやってること<br />IdP<br />WP7CloudApp5.Phone<br />Windows Live<br />Google<br />ACS sign in control で簡単に実装<br />Yahoo!<br />Isolated Storage にクレデンシャルとクレームを格納<br />Facebook<br />OpenID<br />OAuth 2.0<br />Simple Web Token<br />AD FS 2.0<br />http authorization ヘッダーに入れて送信<br />REST(OData)<br />信頼<br />WP7CloudApp5.Web<br />OAuth Wrap<br />REST<br />クレーム変換ルール<br />サービスへのアクセスを認可<br />格納<br />信頼<br />Windows Azure<br />Windows AzureAppFabric ACS<br />
  47. 47. SWT ~ Simple Web Token<br />ACSから返された SWT は SL.Phone.Federation.Controls.RequestSecurityTokenResponseCompletedEventArgs から取得できる<br />ACS から発行された SWT は、HTTPAuthorization ヘッダーに格納して RESTService に POST する<br />"http%3a%2f%2fschemas.xmlsoap.org%2fws%2f2005%2f05%2fidentity%2fclaims%2femailaddress=junichia%40xxx.com&http%3a%2f%2fschemas.xmlsoap.org%2fws%2f2005%2f05%2fidentity%2fclaims%2fname=Junichi+Anno&http%3a%2f%2fschemas.xmlsoap.org%2fws%2f2005%2f05%2fidentity%2fclaims%2fnameidentifier=https%3a%2f%2fwww.google.com%2faccounts%2fo8%2fid%3fid%3dAItOawlmkqO3aqYE1CE1PvWTjCLngPgHng3gZ6k&http%3a%2f%2fschemas.microsoft.com%2faccesscontrolservice%2f2010%2f07%2fclaims%2fidentityprovider=Google&Audience=uri%3awp7cloudapp5&ExpiresOn=1313686502&Issuer=https%3a%2f%2ftfazureforitpro.accesscontrol.windows.net%2f&HMACSHA256=g1WSUMaW8aOmO0kvfvtNj451qYIJODug29kx1H8l1Bo%3d"<br />ACSに保存されている<br />Claim 1<br />Claim 2<br />Key<br />Claim n<br />Issure<br />Audience<br />Hash<br />ExpiresOn<br />HMACHA256<br />
  48. 48. SWT を分解すると<br />http%3a%2f%2fschemas.xmlsoap.org%2fws%2f2005%2f05%2fidentity%2fclaims%2femailaddress=junichia%40xxx.com<br />&<br />http%3a%2f%2fschemas.xmlsoap.org%2fws%2f2005%2f05%2fidentity%2fclaims%2fname=Junichi+Anno<br />&<br />http%3a%2f%2fschemas.xmlsoap.org%2fws%2f2005%2f05%2fidentity%2fclaims%2fnameidentifier=https%3a%2f%2fwww.google.com%2faccounts%2fo8%2fid%3fid%3dAItOawlmkqO3aqYE1CE1PvWTjCLngPgHng3gZ6k<br />&<br />http%3a%2f%2fschemas.microsoft.com%2faccesscontrolservice%2f2010%2f07%2fclaims%2fidentityprovider=Google<br />&<br />Audience=uri%3awp7cloudapp5<br />&<br />ExpiresOn=1313686502<br />&<br />Issuer=https%3a%2f%2ftfazureforitpro.accesscontrol.windows.net%2f<br />&<br />HMACSHA256=g1WSUMaW8aOmO0kvfvtNj451qYIJODug29kx1H8l1Bo%3d<br />
  49. 49. アプリケーション側の対応<br />Windows Phone アプリケーション<br />SWT 内の 4つの主要クレームを検証する<br />署名 :HMACSHA256<br />発行者 : Issuer<br />発行先 : Audience(==applies_to)<br />有効期限 : ExpiresOn<br />SWT を Authorization ヘッダーに格納して REST サービスに POST<br />REST サービス<br /><ul><li>HTTPAuthorization ヘッダーからクレームを取り出す
  50. 50. クレームの活用
  51. 51. ユーザーのロールを判断し、サービスへのアクセス権を与える
  52. 52. データとしてストレージに保存</li></li></ul><li>Windows Phone セキュリティトピック<br />
  53. 53. Windows Phoneのセキュリティ関連機能対応状況<br />修正<br />隠しURLによる配信が可能<br />Private Application Deployment7.1<br />Windows LiveIDClientAPI ×-> OAuth 2.0 が使えます<br />Credential Manager & DPAPINative コードのみ<br />Client Certificates ×<br />Device Encryption ×<br />Local Authentication Subsystem ×<br />NTLM や Kerberos が使えない<br />Windows 統合認証が使えない<br />WIFSupport ×<br />IPSECNetworking Stack × <br />IRMProtected Document 7.1<br />Encrypted Credential Store 7.1<br />WIF:Windows Identity Foundation<br />
  54. 54. (参考)Active Directory の認証を受けるには<br />Phone SDK は DirectoryServiceNamespace に対応しておらず、現時点では Windows 統合認証も使えない∴ WCFを経由して AD FS を使用する<br />イントラネット<br />DMZ<br />ADDS<br />ADFS PROXY<br />ADFS<br />WCFService<br />https<br />445<br />
  55. 55. まとめ<br />
  56. 56. まとめ<br />アプリケーションの利用シナリオを明確にしましょう<br /><ul><li>企業 or ソーシャルアプリ</li></ul>情報漏えい[元]にならないように気を付けましょう<br /><ul><li>余分な特権は要求しない</li></ul>OAuthと OpenID 周辺の動向に注目しましょう<br /><ul><li>OAuth 2.0 Draft 20(Final)
  57. 57. OpenIDConnect
  58. 58. トラストフレームワーク</li></ul>企業システムには SAML も重要です<br />アイデンティティ萌えは アリ です<br />
  59. 59. 世界中の “ID” が利用者になる<br />

×