マイクロWebアプリケーション - Developers.IO 2016
•
19 gefällt mir•8,920 views
マイクロサービスとしてバックエンドをHTTPで疎結合に繋ぐアーキテクチャに注目が集まっています。 そのようにバックエンドで実装した機能を直接ユーザに届けるコンポーネントである「Webアプリケーション」も、コントロールしやすい小さな単位でマイクロコンポーネントとして実装していく、そんな試みをご紹介します。
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie マイクロWebアプリケーション - Developers.IO 2016
Ähnlich wie マイクロWebアプリケーション - Developers.IO 2016 (20)
Mehr von 都元ダイスケ Miyamoto
Mehr von 都元ダイスケ Miyamoto (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (11)
マイクロWebアプリケーション - Developers.IO 2016
- 1. Developers.IO 2016 #cmdevio2016 #A A-3 都元ダイスケ クラスメソッド株式会社 Ⓒ Classmethod, Inc. 2016年02月20日 マイクロWebアプリケーション 複数サブシステムを OpenID Connect で繋ぐアーキテクチャ 1
- 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. #cmdevio2016 #A3Ⓒ Classmethod, Inc. 去年の都元セッション
- 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. #cmdevio2016 #AⒸ Classmethod, Inc. CMPとは ✦ (1) 弊社サービス「メンバーズ」のお客様向けポータル ✦ AWSご利用料金の確認と分析 ✦ CloudTrailの集計結果確認 ✦ ライセンス期限管理 ✦ etc ✦ (2) 社内向け業務システム ✦ コンサルティング資料 ✦ 運用サポート情報管理 ✦ 請求書発行 5 ✦ (3) AWS実験場 ✦ AWS実運用経験の場 ✦ CloudFormation ✦ Elastic Beanstalk ✦ Elastic MapReduce ✦ IAM
- 6. #cmdevio2016 #AⒸ Classmethod, Inc. モノリシックと分割統治 ✦ 1つのサーバで、全てのソフトウェアをホスティング ✦ 1つのアプリで、UIからDBアクセスまで全てを制御 6 Monolith (c) 2011 Maik Meid https://flic.kr/p/ax2PX3 分割して統治することにより、個別のコンポーネントを独立したチームで開発でき、 独自のサイクルでリリースできるようになる。はず。（←やったことないｗ）
- 7. #cmdevio2016 #AⒸ Classmethod, Inc. 技術レイヤによる分割 ✦ ユーザ I/F レイヤ ✦ Web API レイヤ ✦ Queue Worker レイヤ ✦ データストア レイヤ 7 これ以上分割しづらい。 スケールしない。 無理に分割してもメリットは…？
- 8. #cmdevio2016 #AⒸ Classmethod, Inc. ビジネスによる分割 ✦ AWSご利用料金集計・分析サービス ✦ CloudTrail 集計・分析サービス ✦ ライセンス期限管理サービス ✦ 請求書発行サービス ✦ 管理者用マスタメンテサービス（バックエンド用） ✦ 統合認証サービス ✦ etc... ✦ etc... 8
- 9. #cmdevio2016 #A マイクロサービスアーキテクチャ (MSA) 9Ⓒ Classmethod, Inc.
- 10. #cmdevio2016 #A 今、モノリスを見た気がする Monolith (c) 2012 Enrique Gutierrez https://flic.kr/p/egU1k9
- 12. #cmdevio2016 #AⒸ Classmethod, Inc. AWSはMSAの体現 ✦ これはもう異論ないと思います。 ✦ EC2、S3、RDS、ELB、 AutoScaling、Beanstalk… ✦ Beanstalkは裏でS3やCFnを利用。 ✦ AutoScalingはEC2 APIを操作。 ✦ RDSやELBの実体はEC2……？ ✦ 恐らくこれらのサービスも、我々 には見えない、さらに小さなサー ビスで構成されている。はず。 12
- 13. #cmdevio2016 #AⒸ Classmethod, Inc. AWSマネジメントコンソール ✦ では、そのフロントエンドである AWSマネジメントコンソールは モノリシックなアプリケーション だろうか？ ✦ 恐らく、違う。 13
- 14. #cmdevio2016 #AⒸ Classmethod, Inc. Webアプリケーションもマイクロに ✦ タブを切り替えてサービ スを渡り歩くようなペー ジ構成。 ✦ これを一つのアプリケー ションとして実装しなけ ればならない、なんてい う制約はない。 14
- 16. #cmdevio2016 #A
- 17. #cmdevio2016 #AⒸ Classmethod, Inc. MWAで社内円満 ✦ before ✦ 「都元さーん」 ✦ 「嫌です」 ✦ 「いや、聞いてよｗ」 ✦ 「聞くだけなら…」 ✦ 「CMPにこんな機能が 欲しいんだけど」 ✦ 「誰がやるんすか」 ✦ 「ですよねー。。。」 17 ✦ after ✦ 「CMPにこんな機能が 欲しいんだけど」 ✦ 「勝手にサービスAPIと フロントエンドを デプロイして、 リンク追加すれば いいじゃないすか。」 ✦ 「ファッ！？」 （恥ずかしながら、実話です）
- 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. #cmdevio2016 #A 認証 (Authentication) と 認可 (Authorization) 19
- 20. #cmdevio2016 #AⒸ Classmethod, Inc. みんな大好き、認証と認可 ✦ ざっくりとした説明。 ✦ 認証 Authentication （略して AuthN） ✦ 通信の相手が誰であるかを確認するプロセス。 ✦ 認可 Authorization （略して AuthZ） ✦ 誰かに対して、リソースアクセスの権限を与えるプロセス。 20
- 21. #cmdevio2016 #AⒸ Classmethod, Inc. 認証と認可の密結合 ✦ 素朴に捉えると ✦ 相手はAさんだから、アクセスが許可される。 ✦ 相手はAさんではないから、アクセスは許可されない。 ✦ アクセスが許可されるということは、相手はAさんだ。 ✦ アクセスが許可されないということは、相手はAさんではない。 ✦ モノリシックなシステムにおいては大抵、 ✦ 「認証」しなければ「認可」できなかった。 ✦ 誰だかを特定しないことにはアクセスを許可できなかった。 ✦ 誰だかを確認することが、アクセス許可と等価だった。 21
- 22. #cmdevio2016 #AⒸ Classmethod, Inc. 認証と認可の分離 ✦ 本来人間が持つ権限を、外部システムに委譲する 仕組みが勃興。OAuth。 ✦ 例えばTwitterとTogetter ✦ Togetterは@daisuke_mに成り代わり（@daisuke_mの名の 下に）Twitterに対してリソースアクセスを要求する。 ✦ Twitterにとって、通信の相手はTogetterであるが、 @daisuke_m相当のアクセス権を持っている。 ✦ @daisuke_mの持つ権限を、別の主体であるTogetterに 「認可」している。 22
- 23. #cmdevio2016 #AⒸ Classmethod, Inc. 認証 Authentication ✦ メタファーは「証明書の確認」もっと具体的には住基カード。 ✦ 証明書を検証して、通信の相手が誰であるかを確認する プロセス。 ✦ 純粋な認証は、完了したからといって 何かが許されるとは限らない。 ✦ 認証されても、せいぜいシステムが 「こんにちはmiyamotoさん」 とか言い出す位だ、と認識すると良い。 23 Thumb Print Embroidery Wall Hanging (c) 2011 Hey Paul Studios https://flic.kr/p/a6vD7K
- 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. #cmdevio2016 #AⒸ Classmethod, Inc. 認可 Authorization ✦ メタファーは「 や切符の発行」 ✦ 誰かに対して、リソースアクセスの権限を与えるプロセス ✦ 認可にあたって相手の身元確認は必須ではない。（後述） ✦ 認可があるからといって、通信相手の身元が明らかにな るとは限らない。 ✦ 都元家の を持っている人はすべからく（当然）都元家の人間 とは限らない。信頼できる人に を預けている（委譲）かも？ ✦ 「錠前」というシステムは、解錠にあたって「目の前に居る人 は誰か？」なんて考えていない。 を持っているから開けたの だ。 25 Keys (c) 2017 Moyan Brenn https://flic.kr/p/5eLUnX
- 26. #cmdevio2016 #AⒸ Classmethod, Inc. 認証と認可の分離に関する疑問 ✦ 認証せずに認可することなんてあるのか？ ✦ 認可にあたってアイデンティティを確認する必要はない。 ✦ 電車の切符売り場では、認証せずとも切符を発行（認可）してくれる。 ✦ 「特定のIPアドレスからのアクセスはOK」なんてのも。（iptables） ✦ 認証したのに認可しないことなんてあるのか？ ✦ モノリシックなスコープで考えると、まずない。 ✦ しかし、マイクロサービスのような分散環境において、 「分散システムにおけるマクロなスコープでは認可はしていない。 個々のサービス内で、ミクロなスコープでは認可しているかも しれない。まぁ、してないかもしれない。知らん。」 という視点がありうる。（後述） 26
- 27. #cmdevio2016 #AⒸ Classmethod, Inc. 非対称的な並列比較に注意 (1) ✦ 認証 1.証明書の発行 2.証明書の検証よるアイデンティティの確認（←ココが認証） ✦ 認可 1. の発行（←ココが認可） 2. の検証によるアクセス権の確認 27 アクセス制御処理は2段階に分けられ、第1段階は「ポリシー定義段階」、第2 段階は「ポリシー施行段階」である。認可はポリシー定義段階の機能であり、 その後ポリシー施行段階で事前に定義された認可に基づき、アクセス要求を受 け入れるか拒否するかを決定する。（wikipedia http://bit.ly/1Qqmxmu ）
- 28. #cmdevio2016 #A OpenID Connect 1.0 と OAuth 2.0 28
- 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. #cmdevio2016 #AⒸ Classmethod, Inc. OIDC と OAuth の関係 ✦ ボトムアップ視点（技術的な視点） ✦ まず、OAuth という認可に関する仕組みがある。 ✦ そこに認証に関する機能を持たせる拡張を行ったのが OIDC。 ✦ つまり、OIDC は OAuth のスーパーセットである。 ✦ OAuth を把握してから OIDC の理解に進みたい…？ ✦ トップダウン視点（世間の要求と歴史経緯視点） ✦ OpenID という認証に関する仕組みがあった。 ✦ OAuth という認可に関する仕組みもあった。 ✦ 世間でOAuthがモテてたので、OpenIDがそれに乗っかった。 ✦ 認証すれば、どうせ認可の機能も求められる。 ✦ 実は OIDC を把握してから OAuth に話を繋いだ方が理解しや すい…？（都元の主観です） 30
- 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. #cmdevio2016 #AⒸ Classmethod, Inc. OIDCのしくみ ✦ OPがID/passを検証 ✦ ID token を発行 ✦ 「この人はmiyamotoさんで す」という文書に、OPが電 子署名したもの。 ✦ RPはOPを全面信頼 ✦ 「OPがそう言うのだから信 じる。あなたはmiyamotoさ んだ。」 ✦ ただし、電子署名を検証して 改竄がないことを確認。 32
- 33. #cmdevio2016 #AⒸ Classmethod, Inc. OIDCをよく考えてみる。 ✦ OAuth って言うと、Web APIの話とか、そのAPIに 対するアクセス制御の話が浮かぶ。 ✦ 今の話に、Web APIのアクセス制御、出てきた？ ✦ そう、やはり OIDC は OAuth とは別の話なのです。 ✦ マクロの視点では「認証」していない。 ✦ 恐らくRPはその後、OPから受け取った認証に基づい て、RP内部で独自に「認可」をしているであろう。 33
- 34. #cmdevio2016 #AⒸ Classmethod, Inc. OAuthが実現してくれること ✦ OAuthの登場人物 ✦ Resource Owner (RO) と User-Agent (UA) ✦ Client (CL) ✦ Authorization Server (AS) ✦ Resource Server (RS) ✦ ああ、なんか さっきより登場人物が1人多い。 34
- 35. #cmdevio2016 #AⒸ Classmethod, Inc. OAuthのストーリー ✦ ストーリー1 ✦ あなたはあるアプリ（=CL）を作っているとする。 ✦ そのアプリで別システム（=RS）の情報にアクセスしたい。 ✦ けどその情報へのアクセス権は、自分のアプリが持っているものでは なく、本来はこのアプリのユーザ（=RO）が持っているものである。 ✦ 願わくば、ROの許可のもと、RSへのアクセス権をCが持ちたい。 ✦ ストーリー2 ✦ あなたはあるサービス（=RS）を作っているとする。 ✦ このサービスが持つリソースを、広くサードパーティ（=CL）に公開 して、サービスのAPIエコシステムを広げたい。 ✦ ただし、ユーザ（=RO）の許可のもと、適切なアクセス制御が必要。 35
- 36. #cmdevio2016 #AⒸ Classmethod, Inc. OAuthのしくみ ✦ ASがROの認可意思を 確認 ✦ Access token を発行 ✦ RSにアクセスするための ✦ RSはASを全面信頼 ✦ ASが「 は正しい」と 言っているのだから許可 する。 36
- 39. #cmdevio2016 #A それにしても、似てない？ 39Ⓒ Classmethod, Inc. だいたい一緒、でいいよね？（雑
- 40. #cmdevio2016 #AⒸ Classmethod, Inc. 非対称的な並列比較に注意 (2) ✦ OIDC は「認証の委譲」プロトコル。 ✦ OAuth は「認可の委譲」プロトコル。 40 RPが行うべき「認証」を 「OPに」委譲するのがOIDC EUが持つ「認可」を 「CLに」委譲するのがOAuth と言われます。
- 41. #cmdevio2016 #AⒸ Classmethod, Inc. 余談：OAuthで「認証」はできない？ ✦ まぁ、出来ないわけではない。が問題点がある。 ✦ 権限の最小化問題 ✦ 要するに「この人は都元家に入る を持っているから都元さんとして認め る」という認証方法。ただ認証したいだけなのに、家財への認可を渡して しまうって、良いの？ 権限大きすぎない？ ✦ まぁ、適切に権限を絞ったAccess tokenを発行すれば大問題はない。 ✦ トークン置換攻撃問題 ✦ 素朴に作るとセキュリティ・ホールができる。 ✦ まぁ、適切にaudの検証ができる仕組みを用意すれば、大問題はない。 ✦ 非標準仕様問題 ✦ 「OAuthによる認証」は標準化された仕組みではない。 ✦ 誰もがオレオレ仕様を作り、実装することになる。 ✦ OIDCが標準化されてるんだから、それ使えば？ 41
- 42. #cmdevio2016 #AⒸ Classmethod, Inc. ちょっと話戻すよ。 ✦ そうです。CMPとかの話です。 ✦ 各マイクロWebアプリケーションは、OIDCのRPに なればいい。中央のOPに認証を委譲する。 ✦ 各マイクロWebアプリケーションは、OAuthのCLに なればいい。ROの意思表示に基づき、APIへのアク セス認可を得る。 ✦ 各マイクロサービスは、OAuthのRSになればいい。 ASの発行したアクセストークンを持っていればリ ソースへのアクセスを許可する。 42
- 43. #cmdevio2016 #A Single Sign-On (SSO) 43
- 44. #cmdevio2016 #AⒸ Classmethod, Inc. まだ問題は残る ✦ 各マイクロWebアプリは共通のIDで認証できるよう になった（ID統合）。 ✦ だが、各アプリの認証は独立しているため、アプリが 切り替わる度にログインを要求してしまう。 ✦ ID統合とSSOはまた別の話。 44
- 45. #cmdevio2016 #AⒸ Classmethod, Inc. Single Sign-On ✦ 1回ログインしたら、別のシステムに遷移した時も、 再びログイン画面を出さないようにしたい。 ✦ これにより、エンドユーザにマイクロWebアプリケー ションを意識させず、1つのアプリケーションのよう に使ってもらうことができる。 45
- 46. #cmdevio2016 #AⒸ Classmethod, Inc. OIDCにおける「認証」の根っこ ✦ OIDCのOPは、結局は目の前にいるユーザを「認証」 しなければならない。委譲される立場なのだから。 ✦ ただ、仕様においては、その「認証」の方法を具体的 には定めていない。実装に任せる。 ✦ 別にBasic認証でも、クライアント証明書認証でも、生体認証 でも構わない。 ✦ 現実的にはフォーム認証が一般的。ID / pass (WYK) ✦ つまり、session cookieによる認証でもOK。 46
- 47. #cmdevio2016 #AⒸ Classmethod, Inc. 認証とセッション ✦ HTTPとは元来statelessなプロトコル。 ✦ ただ、人間が扱うシステムで毎回認証のための情報を 送らなきゃいけないのは話にならない。 ✦ 一度認証したら、セッションIDをcookieに払い出し、 一定期間はこのcookieを確認することを以って認証 を代替する。 ✦ セッションIDという名がついているが、identifierであると共 にcredentialである、いわゆる認証トークンの一種であるこ とに注意。 47
- 48. #cmdevio2016 #AⒸ Classmethod, Inc. OIDCにおけるSSO ✦ RPからのAuthZ Requestに対し て毎回ログインフォームを出して認 証を行わない。 ✦ OP上でのセッションが生きていれ ば、それを認証とする。 ✦ 結果、OP上でのセッションが生き ている限り、どのOPから何回 AuthZ Requestが来ても、ログ インフォームが現れない。 48
- 49. #cmdevio2016 #AⒸ Classmethod, Inc. OIDCにおけるSSO ✦ RPからのAuthZ Requestに対し て毎回ログインフォームを出して認 証を行わない。 ✦ OP上でのセッションが生きていれ ば、それを認証とする。 ✦ 結果、OP上でのセッションが生き ている限り、どのOPから何回 AuthZ Requestが来ても、ログ インフォームが現れない。 49 ↑セッションによって EUとのインタラクションを 回避したフロー
- 50. #cmdevio2016 #A Global Navigation Menu Service 50
- 51. #cmdevio2016 #AⒸ Classmethod, Inc. Look and Feel ✦ ここまでの施策を適用した上で、各マイクロWebア プリケーション間で look & feel を合わせておけば、 全体を1つのアプリケーションだと錯覚する。 ✦ ユーザは複数のWebアプリケーションを意識しない。 ✦ 各Webアプリケーションの単位は、グローバルナビ ゲーションメニューの単位にほぼ等しい？（仮説） 51
- 52. #cmdevio2016 #AⒸ Classmethod, Inc. Global Navigation Menu Service ✦ 全てのWebアプリケーションが（概ね）共通して持つ、 グローバルナビゲーションがある。 ✦ これを表示するためには、全てのWebアプリケーション が、SSOの輪の中にあるWebアプリケーションを相互に 知っていなければならなくなる。 ✦ それを解消するために、「SSOの輪の中にあるWebアプ リケーション」を管理し、ナビゲーションメニューを構築 するために必要な情報を提供するサービスがあると良い。 52
- 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 で繋ぐアーキテクチャ