Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

マイクロWebアプリケーション - Developers.IO 2016

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 54 Anzeige

マイクロWebアプリケーション - Developers.IO 2016

Herunterladen, um offline zu lesen

マイクロサービスとしてバックエンドをHTTPで疎結合に繋ぐアーキテクチャに注目が集まっています。 そのようにバックエンドで実装した機能を直接ユーザに届けるコンポーネントである「Webアプリケーション」も、コントロールしやすい小さな単位でマイクロコンポーネントとして実装していく、そんな試みをご紹介します。

マイクロサービスとしてバックエンドをHTTPで疎結合に繋ぐアーキテクチャに注目が集まっています。 そのようにバックエンドで実装した機能を直接ユーザに届けるコンポーネントである「Webアプリケーション」も、コントロールしやすい小さな単位でマイクロコンポーネントとして実装していく、そんな試みをご紹介します。

Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Andere mochten auch (20)

Anzeige

Ähnlich wie マイクロWebアプリケーション - Developers.IO 2016 (20)

Weitere von 都元ダイスケ Miyamoto (20)

Anzeige

Aktuellste (20)

マイクロWebアプリケーション - Developers.IO 2016

  1. 1. Developers.IO 2016 #cmdevio2016 #A A-3 都元ダイスケ クラスメソッド株式会社 Ⓒ Classmethod, Inc. 2016年02月20日 マイクロWebアプリケーション
 複数サブシステムを OpenID Connect で繋ぐアーキテクチャ 1
  2. 2. #cmdevio2016 #AⒸ Classmethod, Inc. 自己紹介 ✦ よく訓練されたアップル信者、都元です。 ✦ Webアプリ屋出身のAWS屋 ✦ AWS歴4.5年(2011夏∼) ✦ Java歴約10年(2006頃∼) ✦ Twitter @daisuke_m 2 CloudFormation DynamoDB IAM Beanstalk OAuth OpenID Connect SpringDocker 主戦場・関心キーワード Java Gradle
  3. 3. #cmdevio2016 #A3Ⓒ Classmethod, Inc. 去年の都元セッション
  4. 4. #cmdevio2016 #AⒸ Classmethod, Inc. 去年の都元セッション ✦ 完全AWSネイティブ ✦ Multi-AZパターン ✦ Multi-AZジョブスケジューラ ✦ CloudFormation ✦ Java 8 + Spring ✦ Spring Data と DDD ✦ Spring Boot と Docker ✦ Spring Batch と SQS ✦ SingleCommandDeploy ✦ gradle-aws-plugin Gradle と Beanstalk ✦ Flyway と RDS ✦ APIファースト ✦ HATEOAS と HAL ✦ Swagger (現 OpenAPI) ✦ aurl 4 CMP(クラスメソッド・メンバーズポータル)
  5. 5. #cmdevio2016 #AⒸ Classmethod, Inc. CMPとは ✦ (1) 弊社サービス「メンバーズ」のお客様向けポータル ✦ AWSご利用料金の確認と分析 ✦ CloudTrailの集計結果確認 ✦ ライセンス期限管理 ✦ etc ✦ (2) 社内向け業務システム ✦ コンサルティング資料 ✦ 運用サポート情報管理 ✦ 請求書発行 5 ✦ (3) AWS実験場 ✦ AWS実運用経験の場 ✦ CloudFormation ✦ Elastic Beanstalk ✦ Elastic MapReduce ✦ IAM
  6. 6. #cmdevio2016 #AⒸ Classmethod, Inc. モノリシックと分割統治 ✦ 1つのサーバで、全てのソフトウェアをホスティング ✦ 1つのアプリで、UIからDBアクセスまで全てを制御 6 Monolith (c) 2011 Maik Meid https://flic.kr/p/ax2PX3 分割して統治することにより、個別のコンポーネントを独立したチームで開発でき、
 独自のサイクルでリリースできるようになる。はず。(←やったことないw)
  7. 7. #cmdevio2016 #AⒸ Classmethod, Inc. 技術レイヤによる分割 ✦ ユーザ I/F レイヤ ✦ Web API レイヤ ✦ Queue Worker レイヤ ✦ データストア レイヤ 7 これ以上分割しづらい。 スケールしない。 無理に分割してもメリットは…?
  8. 8. #cmdevio2016 #AⒸ Classmethod, Inc. ビジネスによる分割 ✦ AWSご利用料金集計・分析サービス ✦ CloudTrail 集計・分析サービス ✦ ライセンス期限管理サービス ✦ 請求書発行サービス ✦ 管理者用マスタメンテサービス(バックエンド用) ✦ 統合認証サービス ✦ etc... ✦ etc... 8
  9. 9. #cmdevio2016 #A マイクロサービスアーキテクチャ (MSA) 9Ⓒ Classmethod, Inc.
  10. 10. #cmdevio2016 #A 今、モノリスを見た気がする Monolith (c) 2012 Enrique Gutierrez https://flic.kr/p/egU1k9
  11. 11. #cmdevio2016 #A マイクロ Webアプリケーション (MWAとでも言っておきますか) 11
  12. 12. #cmdevio2016 #AⒸ Classmethod, Inc. AWSはMSAの体現 ✦ これはもう異論ないと思います。 ✦ EC2、S3、RDS、ELB、 AutoScaling、Beanstalk… ✦ Beanstalkは裏でS3やCFnを利用。 ✦ AutoScalingはEC2 APIを操作。 ✦ RDSやELBの実体はEC2……? ✦ 恐らくこれらのサービスも、我々 には見えない、さらに小さなサー ビスで構成されている。はず。 12
  13. 13. #cmdevio2016 #AⒸ Classmethod, Inc. AWSマネジメントコンソール ✦ では、そのフロントエンドである AWSマネジメントコンソールは
 モノリシックなアプリケーション だろうか? ✦ 恐らく、違う。 13
  14. 14. #cmdevio2016 #AⒸ Classmethod, Inc. Webアプリケーションもマイクロに ✦ タブを切り替えてサービ スを渡り歩くようなペー ジ構成。 ✦ これを一つのアプリケー ションとして実装しなけ ればならない、なんてい う制約はない。 14
  15. 15. #cmdevio2016 #A CMPもこうしたら良いのでは!? 15Ⓒ Classmethod, Inc.
  16. 16. #cmdevio2016 #A
  17. 17. #cmdevio2016 #AⒸ Classmethod, Inc. MWAで社内円満 ✦ before ✦ 「都元さーん」 ✦ 「嫌です」 ✦ 「いや、聞いてよw」 ✦ 「聞くだけなら…」 ✦ 「CMPにこんな機能が
   欲しいんだけど」 ✦ 「誰がやるんすか」 ✦ 「ですよねー。。。」 17 ✦ after ✦ 「CMPにこんな機能が
   欲しいんだけど」 ✦ 「勝手にサービスAPIと
  フロントエンドを
  デプロイして、
  リンク追加すれば
  いいじゃないすか。」 ✦ 「ファッ!?」 (恥ずかしながら、実話です)
  18. 18. #cmdevio2016 #AⒸ Classmethod, Inc. 超えなければいけない問題 ✦認証・認可(本セッションのメインテーマ) ✦ APIの権限管理とApp間でID統合とSSO (Single Sign-On) が必須。 ✦ これからじっくり話します。 ✦インフラコスト(MWAというよりMSAの宿命) ✦ モノリシックよりも大きくインフラを食ってしまう。 ✦ 要するに、OSやフレームワークなど、本来共通化出来る部分が、
 小さくに切り分けることによって冗長になる。 ✦ 確保従量 (pay-as-you-provision) モデル(EC2やDynamoDB等)ではなく、
 消費従量 (pay-as-you-consume) モデル(LambdaやS3等)の課金で、
 アプリケーション( ファンクション)をデプロイしたいなー。 18
  19. 19. #cmdevio2016 #A 認証 (Authentication) と 認可 (Authorization) 19
  20. 20. #cmdevio2016 #AⒸ Classmethod, Inc. みんな大好き、認証と認可 ✦ ざっくりとした説明。 ✦ 認証 Authentication (略して AuthN) ✦ 通信の相手が誰であるかを確認するプロセス。 ✦ 認可 Authorization (略して AuthZ) ✦ 誰かに対して、リソースアクセスの権限を与えるプロセス。 20
  21. 21. #cmdevio2016 #AⒸ Classmethod, Inc. 認証と認可の密結合 ✦ 素朴に捉えると ✦ 相手はAさんだから、アクセスが許可される。 ✦ 相手はAさんではないから、アクセスは許可されない。 ✦ アクセスが許可されるということは、相手はAさんだ。 ✦ アクセスが許可されないということは、相手はAさんではない。 ✦ モノリシックなシステムにおいては大抵、 ✦ 「認証」しなければ「認可」できなかった。 ✦ 誰だかを特定しないことにはアクセスを許可できなかった。 ✦ 誰だかを確認することが、アクセス許可と等価だった。 21
  22. 22. #cmdevio2016 #AⒸ Classmethod, Inc. 認証と認可の分離 ✦ 本来人間が持つ権限を、外部システムに委譲する
 仕組みが勃興。OAuth。 ✦ 例えばTwitterとTogetter ✦ Togetterは@daisuke_mに成り代わり(@daisuke_mの名の 下に)Twitterに対してリソースアクセスを要求する。 ✦ Twitterにとって、通信の相手はTogetterであるが、 @daisuke_m相当のアクセス権を持っている。 ✦ @daisuke_mの持つ権限を、別の主体であるTogetterに
 「認可」している。 22
  23. 23. #cmdevio2016 #AⒸ Classmethod, Inc. 認証 Authentication ✦ メタファーは「証明書の確認」もっと具体的には住基カード。 ✦ 証明書を検証して、通信の相手が誰であるかを確認する
 プロセス。 ✦ 純粋な認証は、完了したからといって
 何かが許されるとは限らない。 ✦ 認証されても、せいぜいシステムが
 「こんにちはmiyamotoさん」
 とか言い出す位だ、と認識すると良い。 23 Thumb Print Embroidery Wall Hanging (c) 2011 Hey Paul Studios https://flic.kr/p/a6vD7K
  24. 24. #cmdevio2016 #AⒸ Classmethod, Inc. 現実世界における認証の手段 ✦ 現実世界における認証ファクター ✦ WHAT YOU ARE (inherence factor) ✦ 顔貌、声、指紋、署名など、その人自身の提示。 ✦ WHAT YOU HAVE (possession factor) ✦ 身分証、携帯電話等、その人だけが持っているものの提示。 ✦ 顔写真等、結果的にWYAに依存するものもある。 ✦ WHAT YOU KNOW (knowledge factor) ✦ パスワード、秘密の質問等、その人だけが知っていることの提示。 ✦ MFA (multi-factor authentication) ✦ ガチ攻めすると哲学ゾーンに入る話。我思う故に我あり? ✦ 顔が同じなら、アイデンティティを確認できるのか? 人の記憶とは? ✦ 「ばかもーん!そいつがルパンだ、追えー!」 24
  25. 25. #cmdevio2016 #AⒸ Classmethod, Inc. 認可 Authorization ✦ メタファーは「 や切符の発行」 ✦ 誰かに対して、リソースアクセスの権限を与えるプロセス ✦ 認可にあたって相手の身元確認は必須ではない。(後述) ✦ 認可があるからといって、通信相手の身元が明らかにな るとは限らない。 ✦ 都元家の を持っている人はすべからく(当然)都元家の人間 とは限らない。信頼できる人に を預けている(委譲)かも? ✦ 「錠前」というシステムは、解錠にあたって「目の前に居る人 は誰か?」なんて考えていない。 を持っているから開けたの だ。 25 Keys (c) 2017 Moyan Brenn https://flic.kr/p/5eLUnX
  26. 26. #cmdevio2016 #AⒸ Classmethod, Inc. 認証と認可の分離に関する疑問 ✦ 認証せずに認可することなんてあるのか? ✦ 認可にあたってアイデンティティを確認する必要はない。 ✦ 電車の切符売り場では、認証せずとも切符を発行(認可)してくれる。 ✦ 「特定のIPアドレスからのアクセスはOK」なんてのも。(iptables) ✦ 認証したのに認可しないことなんてあるのか? ✦ モノリシックなスコープで考えると、まずない。 ✦ しかし、マイクロサービスのような分散環境において、
 「分散システムにおけるマクロなスコープでは認可はしていない。
  個々のサービス内で、ミクロなスコープでは認可しているかも
  しれない。まぁ、してないかもしれない。知らん。」
 という視点がありうる。(後述) 26
  27. 27. #cmdevio2016 #AⒸ Classmethod, Inc. 非対称的な並列比較に注意 (1) ✦ 認証 1.証明書の発行 2.証明書の検証よるアイデンティティの確認(←ココが認証) ✦ 認可 1. の発行(←ココが認可) 2. の検証によるアクセス権の確認 27 アクセス制御処理は2段階に分けられ、第1段階は「ポリシー定義段階」、第2 段階は「ポリシー施行段階」である。認可はポリシー定義段階の機能であり、 その後ポリシー施行段階で事前に定義された認可に基づき、アクセス要求を受 け入れるか拒否するかを決定する。(wikipedia http://bit.ly/1Qqmxmu )
  28. 28. #cmdevio2016 #A OpenID Connect 1.0 と OAuth 2.0 28
  29. 29. #cmdevio2016 #AⒸ Classmethod, Inc. まず、略称定義と概要。 ✦ OpenID Connect 1.0 ✦ 本スライドでは OIDC と書きます。 ✦ ちなみに OpenID と OpenID Connect は別の仕様です。 ✦ あるシステムが持つ「認証」の責務を外部システムに任せるため の仕組みです。 ✦ OAuth 2.0 ✦ 本スライドでは OAuth と書きます。 ✦ もちろん、OAuth 2.0 と OAuth 1.0a 等は別の仕様です。 ✦ あるシステムが外部システムに対するAPIアクセスの「認可」を受 け取るための仕組みです。 29
  30. 30. #cmdevio2016 #AⒸ Classmethod, Inc. OIDC と OAuth の関係 ✦ ボトムアップ視点(技術的な視点) ✦ まず、OAuth という認可に関する仕組みがある。 ✦ そこに認証に関する機能を持たせる拡張を行ったのが OIDC。 ✦ つまり、OIDC は OAuth のスーパーセットである。 ✦ OAuth を把握してから OIDC の理解に進みたい…? ✦ トップダウン視点(世間の要求と歴史経緯視点) ✦ OpenID という認証に関する仕組みがあった。 ✦ OAuth という認可に関する仕組みもあった。 ✦ 世間でOAuthがモテてたので、OpenIDがそれに乗っかった。 ✦ 認証すれば、どうせ認可の機能も求められる。 ✦ 実は OIDC を把握してから OAuth に話を繋いだ方が理解しや すい…?(都元の主観です) 30
  31. 31. #cmdevio2016 #AⒸ Classmethod, Inc. OIDCが実現してくれること ✦ OIDCの登場人物 ✦ End-User (EU) と User-Agent (UA) ✦ Relying Party (RP) ✦ OpenID Provider (OP, IdP) ✦ ストーリー ✦ あなたはあるWebアプリ(=RP)を作っているとする。 ✦ そのアプリでユーザ(=EU)の認証を行いたい。 ✦ けど自システム内でパスワードを保持したくない。 ✦ 願わくば、認証を外部システム(=OP)に丸投げしたい。 31
  32. 32. #cmdevio2016 #AⒸ Classmethod, Inc. OIDCのしくみ ✦ OPがID/passを検証 ✦ ID token を発行 ✦ 「この人はmiyamotoさんで す」という文書に、OPが電 子署名したもの。 ✦ RPはOPを全面信頼 ✦ 「OPがそう言うのだから信 じる。あなたはmiyamotoさ んだ。」 ✦ ただし、電子署名を検証して 改竄がないことを確認。 32
  33. 33. #cmdevio2016 #AⒸ Classmethod, Inc. OIDCをよく考えてみる。 ✦ OAuth って言うと、Web APIの話とか、そのAPIに 対するアクセス制御の話が浮かぶ。 ✦ 今の話に、Web APIのアクセス制御、出てきた? ✦ そう、やはり OIDC は OAuth とは別の話なのです。 ✦ マクロの視点では「認証」していない。 ✦ 恐らくRPはその後、OPから受け取った認証に基づい て、RP内部で独自に「認可」をしているであろう。 33
  34. 34. #cmdevio2016 #AⒸ Classmethod, Inc. OAuthが実現してくれること ✦ OAuthの登場人物 ✦ Resource Owner (RO) と User-Agent (UA) ✦ Client (CL) ✦ Authorization Server (AS) ✦ Resource Server (RS) ✦ ああ、なんか
 さっきより登場人物が1人多い。 34
  35. 35. #cmdevio2016 #AⒸ Classmethod, Inc. OAuthのストーリー ✦ ストーリー1 ✦ あなたはあるアプリ(=CL)を作っているとする。 ✦ そのアプリで別システム(=RS)の情報にアクセスしたい。 ✦ けどその情報へのアクセス権は、自分のアプリが持っているものでは なく、本来はこのアプリのユーザ(=RO)が持っているものである。 ✦ 願わくば、ROの許可のもと、RSへのアクセス権をCが持ちたい。 ✦ ストーリー2 ✦ あなたはあるサービス(=RS)を作っているとする。 ✦ このサービスが持つリソースを、広くサードパーティ(=CL)に公開 して、サービスのAPIエコシステムを広げたい。 ✦ ただし、ユーザ(=RO)の許可のもと、適切なアクセス制御が必要。 35
  36. 36. #cmdevio2016 #AⒸ Classmethod, Inc. OAuthのしくみ ✦ ASがROの認可意思を 確認 ✦ Access token を発行 ✦ RSにアクセスするための ✦ RSはASを全面信頼 ✦ ASが「 は正しい」と 言っているのだから許可 する。 36
  37. 37. #cmdevio2016 #A それにしても、似てない? 37Ⓒ Classmethod, Inc.
  38. 38. #cmdevio2016 #A それにしても、似てない? 38Ⓒ Classmethod, Inc.
  39. 39. #cmdevio2016 #A それにしても、似てない? 39Ⓒ Classmethod, Inc. だいたい一緒、でいいよね?(雑
  40. 40. #cmdevio2016 #AⒸ Classmethod, Inc. 非対称的な並列比較に注意 (2) ✦ OIDC は「認証の委譲」プロトコル。 ✦ OAuth は「認可の委譲」プロトコル。 40 RPが行うべき「認証」を 「OPに」委譲するのがOIDC EUが持つ「認可」を 「CLに」委譲するのがOAuth と言われます。
  41. 41. #cmdevio2016 #AⒸ Classmethod, Inc. 余談:OAuthで「認証」はできない? ✦ まぁ、出来ないわけではない。が問題点がある。 ✦ 権限の最小化問題 ✦ 要するに「この人は都元家に入る を持っているから都元さんとして認め る」という認証方法。ただ認証したいだけなのに、家財への認可を渡して しまうって、良いの? 権限大きすぎない? ✦ まぁ、適切に権限を絞ったAccess tokenを発行すれば大問題はない。 ✦ トークン置換攻撃問題 ✦ 素朴に作るとセキュリティ・ホールができる。 ✦ まぁ、適切にaudの検証ができる仕組みを用意すれば、大問題はない。 ✦ 非標準仕様問題 ✦ 「OAuthによる認証」は標準化された仕組みではない。 ✦ 誰もがオレオレ仕様を作り、実装することになる。 ✦ OIDCが標準化されてるんだから、それ使えば? 41
  42. 42. #cmdevio2016 #AⒸ Classmethod, Inc. ちょっと話戻すよ。 ✦ そうです。CMPとかの話です。 ✦ 各マイクロWebアプリケーションは、OIDCのRPに なればいい。中央のOPに認証を委譲する。 ✦ 各マイクロWebアプリケーションは、OAuthのCLに なればいい。ROの意思表示に基づき、APIへのアク セス認可を得る。 ✦ 各マイクロサービスは、OAuthのRSになればいい。 ASの発行したアクセストークンを持っていればリ ソースへのアクセスを許可する。 42
  43. 43. #cmdevio2016 #A Single Sign-On (SSO) 43
  44. 44. #cmdevio2016 #AⒸ Classmethod, Inc. まだ問題は残る ✦ 各マイクロWebアプリは共通のIDで認証できるよう になった(ID統合)。 ✦ だが、各アプリの認証は独立しているため、アプリが 切り替わる度にログインを要求してしまう。 ✦ ID統合とSSOはまた別の話。 44
  45. 45. #cmdevio2016 #AⒸ Classmethod, Inc. Single Sign-On ✦ 1回ログインしたら、別のシステムに遷移した時も、 再びログイン画面を出さないようにしたい。 ✦ これにより、エンドユーザにマイクロWebアプリケー ションを意識させず、1つのアプリケーションのよう に使ってもらうことができる。 45
  46. 46. #cmdevio2016 #AⒸ Classmethod, Inc. OIDCにおける「認証」の根っこ ✦ OIDCのOPは、結局は目の前にいるユーザを「認証」 しなければならない。委譲される立場なのだから。 ✦ ただ、仕様においては、その「認証」の方法を具体的 には定めていない。実装に任せる。 ✦ 別にBasic認証でも、クライアント証明書認証でも、生体認証 でも構わない。 ✦ 現実的にはフォーム認証が一般的。ID / pass (WYK) ✦ つまり、session cookieによる認証でもOK。 46
  47. 47. #cmdevio2016 #AⒸ Classmethod, Inc. 認証とセッション ✦ HTTPとは元来statelessなプロトコル。 ✦ ただ、人間が扱うシステムで毎回認証のための情報を 送らなきゃいけないのは話にならない。 ✦ 一度認証したら、セッションIDをcookieに払い出し、 一定期間はこのcookieを確認することを以って認証 を代替する。 ✦ セッションIDという名がついているが、identifierであると共 にcredentialである、いわゆる認証トークンの一種であるこ とに注意。 47
  48. 48. #cmdevio2016 #AⒸ Classmethod, Inc. OIDCにおけるSSO ✦ RPからのAuthZ Requestに対し て毎回ログインフォームを出して認 証を行わない。 ✦ OP上でのセッションが生きていれ ば、それを認証とする。 ✦ 結果、OP上でのセッションが生き ている限り、どのOPから何回 AuthZ Requestが来ても、ログ インフォームが現れない。 48
  49. 49. #cmdevio2016 #AⒸ Classmethod, Inc. OIDCにおけるSSO ✦ RPからのAuthZ Requestに対し て毎回ログインフォームを出して認 証を行わない。 ✦ OP上でのセッションが生きていれ ば、それを認証とする。 ✦ 結果、OP上でのセッションが生き ている限り、どのOPから何回 AuthZ Requestが来ても、ログ インフォームが現れない。 49 ↑セッションによって EUとのインタラクションを 回避したフロー
  50. 50. #cmdevio2016 #A Global Navigation Menu Service 50
  51. 51. #cmdevio2016 #AⒸ Classmethod, Inc. Look and Feel ✦ ここまでの施策を適用した上で、各マイクロWebア プリケーション間で look & feel を合わせておけば、 全体を1つのアプリケーションだと錯覚する。 ✦ ユーザは複数のWebアプリケーションを意識しない。 ✦ 各Webアプリケーションの単位は、グローバルナビ ゲーションメニューの単位にほぼ等しい?(仮説) 51
  52. 52. #cmdevio2016 #AⒸ Classmethod, Inc. Global Navigation Menu Service ✦ 全てのWebアプリケーションが(概ね)共通して持つ、 グローバルナビゲーションがある。 ✦ これを表示するためには、全てのWebアプリケーション が、SSOの輪の中にあるWebアプリケーションを相互に 知っていなければならなくなる。 ✦ それを解消するために、「SSOの輪の中にあるWebアプ リケーション」を管理し、ナビゲーションメニューを構築 するために必要な情報を提供するサービスがあると良い。 52
  53. 53. #cmdevio2016 #A まぁ、まだ、ない。
  54. 54. Developers.IO 2016 #cmdevio2016 #A54 A-3 Ⓒ Classmethod, Inc. ✦ マイクロサービス ✦ マイクロWebアプリケーション ✦ 認証と認可 ✦ OpenID Connect 1.0 と OAuth 2.0 ✦ Single Sign On ✦ Global Navigation Menu Service 本日のスライド bit.ly/cm-microwebapp マイクロWebアプリケーション
 複数サブシステムを OpenID Connect で繋ぐアーキテクチャ

×