マイクロwebアプリケーション - developers.io 2016

Developers.IO 2016

#cmdevio2016 #A

A-3

都元ダイスケクラスメソッド株式会社

Ⓒ Classmethod, Inc.

2016年02月20日

マイクロWebアプリケーション複数サブシステムを OpenID Connect で繋ぐアーキテクチャ

1

#cmdevio2016 #AⒸ Classmethod, Inc.

自己紹介✦よく訓練されたアップル信者、都元です。 ✦Webアプリ屋出身のAWS屋

✦AWS歴4.5年（2011夏～） ✦ Java歴約10年（2006頃～）

✦Twitter @daisuke_m

2

CloudFormationDynamoDB

IAM

BeanstalkOAuth

OpenID Connect

Spring Docker

主戦場・関心キーワードJavaGradle

#cmdevio2016 #A3Ⓒ Classmethod, Inc.

去年の都元セッション


去年の都元セッション

✦完全AWSネイティブ ✦Multi-AZパターン ✦Multi-AZジョブスケジューラ ✦CloudFormation

✦ Java 8 + Spring ✦Spring Data と DDD ✦Spring Boot と Docker ✦Spring Batch と SQS

✦Single Command Deploy ✦ gradle-aws-plugin Gradle と Beanstalk

✦ Flyway と RDS ✦APIファースト

✦HATEOAS と HAL ✦Swagger (現 OpenAPI) ✦ aurl

4

CMP（クラスメソッド・メンバーズポータル）


CMPとは✦ (1) 弊社サービス「メンバーズ」のお客様向けポータル

✦AWSご利用料金の確認と分析 ✦CloudTrailの集計結果確認 ✦ライセンス期限管理 ✦ etc

✦ (2) 社内向け業務システム ✦コンサルティング資料 ✦運用サポート情報管理 ✦請求書発行

5

✦ (3) AWS実験場 ✦AWS実運用経験の場 ✦CloudFormation ✦Elastic Beanstalk ✦Elastic MapReduce ✦ IAM


モノリシックと分割統治✦1つのサーバで、全てのソフトウェアをホスティング ✦1つのアプリで、UIからDBアクセスまで全てを制御

6

Monolith (c) 2011 Maik Meid https://flic.kr/p/ax2PX3

分割して統治することにより、個別のコンポーネントを独立したチームで開発でき、独自のサイクルでリリースできるようになる。はず。（←やったことないｗ）

https://flic.kr/p/ax2PX3


技術レイヤによる分割✦ユーザ I/F レイヤ ✦Web API レイヤ ✦Queue Worker レイヤ ✦データストアレイヤ

7

これ以上分割しづらい。スケールしない。

無理に分割してもメリットは…？


ビジネスによる分割✦AWSご利用料金集計・分析サービス ✦CloudTrail 集計・分析サービス ✦ライセンス期限管理サービス ✦請求書発行サービス ✦管理者用マスタメンテサービス（バックエンド用） ✦統合認証サービス ✦ etc... ✦ etc...

8

#cmdevio2016 #A

マイクロサービスアーキテクチャ (MSA)

9Ⓒ Classmethod, Inc.

#cmdevio2016 #A

今、モノリスを見た気がする

Monolith (c) 2012 Enrique Gutierrez https://flic.kr/p/egU1k9

https://flic.kr/p/egU1k9

#cmdevio2016 #A

マイクロ Webアプリケーション（MWAとでも言っておきますか）

11


AWSはMSAの体現✦これはもう異論ないと思います。 ✦EC2、S3、RDS、ELB、AutoScaling、Beanstalk… ✦Beanstalkは裏でS3やCFnを利用。 ✦AutoScalingはEC2 APIを操作。 ✦RDSやELBの実体はEC2……？

✦恐らくこれらのサービスも、我々には見えない、さらに小さなサービスで構成されている。はず。

12


AWSマネジメントコンソール✦ では、そのフロントエンドであるAWSマネジメントコンソールはモノリシックなアプリケーションだろうか？

✦恐らく、違う。

13


Webアプリケーションもマイクロに✦タブを切り替えてサービスを渡り歩くようなページ構成。

✦これを一つのアプリケーションとして実装しなければならない、なんていう制約はない。

14

#cmdevio2016 #A

CMPもこうしたら良いのでは！？


#cmdevio2016 #A


MWAで社内円満✦before

✦ 「都元さーん」 ✦ 「嫌です」 ✦ 「いや、聞いてよｗ」 ✦ 「聞くだけなら…」 ✦ 「CMPにこんな機能が　　欲しいんだけど」

✦ 「誰がやるんすか」 ✦ 「ですよねー。。。」

17

✦after ✦ 「CMPにこんな機能が　　欲しいんだけど」

✦ 「勝手にサービスAPIと　フロントエンドを　デプロイして、　リンク追加すれば　いいじゃないすか。」

✦ 「ファッ！？」

（恥ずかしながら、実話です）


超えなければいけない問題✦認証・認可（本セッションのメインテーマ）

✦APIの権限管理とApp間でID統合とSSO (Single Sign-On) が必須。 ✦これからじっくり話します。

✦インフラコスト（MWAというよりMSAの宿命） ✦モノリシックよりも大きくインフラを食ってしまう。

✦要するに、OSやフレームワークなど、本来共通化出来る部分が、小さくに切り分けることによって冗長になる。

✦確保従量 (pay-as-you-provision) モデル（EC2やDynamoDB等）ではなく、消費従量 (pay-as-you-consume) モデル（LambdaやS3等）の課金で、アプリケーション（≠ファンクション）をデプロイしたいなー。

18

#cmdevio2016 #A

認証 (Authentication) と認可 (Authorization)

19


みんな大好き、認証と認可

✦ざっくりとした説明。

✦認証 Authentication （略して AuthN） ✦通信の相手が誰であるかを確認するプロセス。

✦認可 Authorization （略して AuthZ） ✦誰かに対して、リソースアクセスの権限を与えるプロセス。

20


認証と認可の密結合✦素朴に捉えると

✦相手はAさんだから、アクセスが許可される。 ✦相手はAさんではないから、アクセスは許可されない。 ✦アクセスが許可されるということは、相手はAさんだ。 ✦アクセスが許可されないということは、相手はAさんではない。

✦モノリシックなシステムにおいては大抵、 ✦「認証」しなければ「認可」できなかった。 ✦誰だかを特定しないことにはアクセスを許可できなかった。 ✦誰だかを確認することが、アクセス許可と等価だった。

21


認証と認可の分離✦本来人間が持つ権限を、外部システムに委譲する仕組みが勃興。OAuth。

✦例えばTwitterとTogetter ✦ Togetterは@daisuke_mに成り代わり（@daisuke_mの名の下に）Twitterに対してリソースアクセスを要求する。

✦ Twitterにとって、通信の相手はTogetterであるが、@daisuke_m相当のアクセス権を持っている。

✦ @daisuke_mの持つ権限を、別の主体であるTogetterに「認可」している。

22


認証 Authentication✦メタファーは「証明書の確認」もっと具体的には住基カード。

✦証明書を検証して、通信の相手が誰であるかを確認するプロセス。

✦純粋な認証は、完了したからといって何かが許されるとは限らない。 ✦認証されても、せいぜいシステムが「こんにちはmiyamotoさん」とか言い出す位だ、と認識すると良い。

23

Thumb Print Embroidery Wall Hanging (c) 2011 Hey Paul Studios https://flic.kr/p/a6vD7K

https://flic.kr/p/a6vD7K


現実世界における認証の手段✦現実世界における認証ファクター

✦WHAT YOU ARE (inherence factor) ✦顔貌、声、指紋、署名など、その人自身の提示。

✦WHAT YOU HAVE (possession factor) ✦身分証、携帯電話等、その人だけが持っているものの提示。 ✦顔写真等、結果的にWYAに依存するものもある。

✦WHAT YOU KNOW (knowledge factor) ✦パスワード、秘密の質問等、その人だけが知っていることの提示。

✦MFA (multi-factor authentication) ✦ガチ攻めすると哲学ゾーンに入る話。我思う故に我あり？

✦顔が同じなら、アイデンティティを確認できるのか？人の記憶とは？ ✦「ばかもーん！そいつがルパンだ、追えー！」

24


認可 Authorization✦メタファーは「鍵や切符の発行」

✦誰かに対して、リソースアクセスの権限を与えるプロセス ✦認可にあたって相手の身元確認は必須ではない。（後述）

✦認可があるからといって、通信相手の身元が明らかになるとは限らない。 ✦都元家の鍵を持っている人はすべからく（当然）都元家の人間とは限らない。信頼できる人に鍵を預けている（委譲）かも？

✦「錠前」というシステムは、解錠にあたって「目の前に居る人は誰か？」なんて考えていない。鍵を持っているから開けたのだ。

25

Keys (c) 2017 Moyan Brenn https://flic.kr/p/5eLUnX

https://flic.kr/p/5eLUnX


認証と認可の分離に関する疑問✦認証せずに認可することなんてあるのか？

✦認可にあたってアイデンティティを確認する必要はない。 ✦電車の切符売り場では、認証せずとも切符を発行（認可）してくれる。 ✦「特定のIPアドレスからのアクセスはOK」なんてのも。（iptables）

✦認証したのに認可しないことなんてあるのか？ ✦モノリシックなスコープで考えると、まずない。 ✦しかし、マイクロサービスのような分散環境において、「分散システムにおけるマクロなスコープでは認可はしていない。　個々のサービス内で、ミクロなスコープでは認可しているかも　しれない。まぁ、してないかもしれない。知らん。」という視点がありうる。（後述）

26


非対称的な並列比較に注意 (1)✦認証 1.証明書の発行 2.証明書の検証よるアイデンティティの確認（←ココが認証）

✦認可 1.鍵の発行（←ココが認可） 2.鍵の検証によるアクセス権の確認

27

アクセス制御処理は2段階に分けられ、第1段階は「ポリシー定義段階」、第2段階は「ポリシー施行段階」である。認可はポリシー定義段階の機能であり、その後ポリシー施行段階で事前に定義された認可に基づき、アクセス要求を受け入れるか拒否するかを決定する。（wikipedia http://bit.ly/1Qqmxmu ）

http://bit.ly/1Qqmxmu

#cmdevio2016 #A

OpenID Connect 1.0 と OAuth 2.0

28


まず、略称定義と概要。✦OpenID Connect 1.0

✦本スライドでは OIDC と書きます。 ✦ちなみに OpenID と OpenID Connect は別の仕様です。 ✦あるシステムが持つ「認証」の責務を外部システムに任せるための仕組みです。

✦OAuth 2.0 ✦本スライドでは OAuth と書きます。 ✦もちろん、OAuth 2.0 と OAuth 1.0a 等は別の仕様です。 ✦あるシステムが外部システムに対するAPIアクセスの「認可」を受け取るための仕組みです。

29


OIDC と OAuth の関係✦ボトムアップ視点（技術的な視点）

✦まず、OAuth という認可に関する仕組みがある。 ✦そこに認証に関する機能を持たせる拡張を行ったのが OIDC。 ✦つまり、OIDC は OAuth のスーパーセットである。 ✦OAuth を把握してから OIDC の理解に進みたい…？

✦トップダウン視点（世間の要求と歴史経緯視点） ✦OpenID という認証に関する仕組みがあった。 ✦OAuth という認可に関する仕組みもあった。 ✦世間でOAuthがモテてたので、OpenIDがそれに乗っかった。 ✦認証すれば、どうせ認可の機能も求められる。 ✦実は OIDC を把握してから OAuth に話を繋いだ方が理解しやすい…？（都元の主観です）

30


OIDCが実現してくれること✦OIDCの登場人物

✦ End-User (EU) と User-Agent (UA) ✦Relying Party (RP) ✦OpenID Provider (OP, IdP)

✦ストーリー ✦あなたはあるWebアプリ（=RP）を作っているとする。 ✦そのアプリでユーザ（=EU）の認証を行いたい。 ✦けど自システム内でパスワードを保持したくない。 ✦願わくば、認証を外部システム（=OP）に丸投げしたい。

31


OIDCのしくみ✦OPがID/passを検証 ✦ ID token を発行

✦「この人はmiyamotoさんです」という文書に、OPが電子署名したもの。

✦RPはOPを全面信頼 ✦「OPがそう言うのだから信じる。あなたはmiyamotoさんだ。」

✦ただし、電子署名を検証して改竄がないことを確認。

32


OIDCをよく考えてみる。✦OAuth って言うと、Web APIの話とか、そのAPIに対するアクセス制御の話が浮かぶ。

✦今の話に、Web APIのアクセス制御、出てきた？ ✦そう、やはり OIDC は OAuth とは別の話なのです。

✦マクロの視点では「認証」していない。 ✦恐らくRPはその後、OPから受け取った認証に基づいて、RP内部で独自に「認可」をしているであろう。

33


OAuthが実現してくれること✦OAuthの登場人物

✦Resource Owner (RO) と User-Agent (UA) ✦Client (CL) ✦Authorization Server (AS) ✦Resource Server (RS)

✦ああ、なんかさっきより登場人物が1人多い。

34


OAuthのストーリー✦ストーリー1

✦あなたはあるアプリ（=CL）を作っているとする。 ✦そのアプリで別システム（=RS）の情報にアクセスしたい。 ✦けどその情報へのアクセス権は、自分のアプリが持っているものではなく、本来はこのアプリのユーザ（=RO）が持っているものである。

✦願わくば、ROの許可のもと、RSへのアクセス権をCが持ちたい。 ✦ストーリー2

✦あなたはあるサービス（=RS）を作っているとする。 ✦このサービスが持つリソースを、広くサードパーティ（=CL）に公開して、サービスのAPIエコシステムを広げたい。

✦ただし、ユーザ（=RO）の許可のもと、適切なアクセス制御が必要。

35


OAuthのしくみ✦ASがROの認可意思を確認

✦Access token を発行 ✦RSにアクセスするための鍵

✦RSはASを全面信頼 ✦ASが「鍵は正しい」と言っているのだから許可する。

36

#cmdevio2016 #A

それにしても、似てない？


#cmdevio2016 #A



#cmdevio2016 #A



だいたい一緒、でいいよね？（雑


非対称的な並列比較に注意 (2)✦OIDC は「認証の委譲」プロトコル。 ✦OAuth は「認可の委譲」プロトコル。

40

RPが行うべき「認証」を「OPに」委譲するのがOIDC

EUが持つ「認可」を「CLに」委譲するのがOAuth

と言われます。


余談：OAuthで「認証」はできない？✦まぁ、出来ないわけではない。が問題点がある。 ✦権限の最小化問題

✦要するに「この人は都元家に入る鍵を持っているから都元さんとして認める」という認証方法。ただ認証したいだけなのに、家財への認可を渡してしまうって、良いの？権限大きすぎない？

✦まぁ、適切に権限を絞ったAccess tokenを発行すれば大問題はない。 ✦トークン置換攻撃問題

✦素朴に作るとセキュリティ・ホールができる。 ✦まぁ、適切にaudの検証ができる仕組みを用意すれば、大問題はない。

✦非標準仕様問題 ✦「OAuthによる認証」は標準化された仕組みではない。 ✦誰もがオレオレ仕様を作り、実装することになる。 ✦OIDCが標準化されてるんだから、それ使えば？

41


ちょっと話戻すよ。✦そうです。CMPとかの話です。 ✦各マイクロWebアプリケーションは、OIDCのRPになればいい。中央のOPに認証を委譲する。

✦各マイクロWebアプリケーションは、OAuthのCLになればいい。ROの意思表示に基づき、APIへのアクセス認可を得る。

✦各マイクロサービスは、OAuthのRSになればいい。ASの発行したアクセストークンを持っていればリソースへのアクセスを許可する。

42

#cmdevio2016 #A

Single Sign-On (SSO)

43


まだ問題は残る✦各マイクロWebアプリは共通のIDで認証できるようになった（ID統合）。

✦だが、各アプリの認証は独立しているため、アプリが切り替わる度にログインを要求してしまう。

✦ ID統合とSSOはまた別の話。

44


Single Sign-On✦1回ログインしたら、別のシステムに遷移した時も、再びログイン画面を出さないようにしたい。

✦これにより、エンドユーザにマイクロWebアプリケーションを意識させず、1つのアプリケーションのように使ってもらうことができる。

45


OIDCにおける「認証」の根っこ✦OIDCのOPは、結局は目の前にいるユーザを「認証」しなければならない。委譲される立場なのだから。

✦ただ、仕様においては、その「認証」の方法を具体的には定めていない。実装に任せる。 ✦別にBasic認証でも、クライアント証明書認証でも、生体認証でも構わない。

✦現実的にはフォーム認証が一般的。ID / pass (WYK)

✦つまり、session cookieによる認証でもOK。

46


認証とセッション✦HTTPとは元来statelessなプロトコル。 ✦ただ、人間が扱うシステムで毎回認証のための情報を送らなきゃいけないのは話にならない。

✦一度認証したら、セッションIDをcookieに払い出し、一定期間はこのcookieを確認することを以って認証を代替する。 ✦セッションIDという名がついているが、identifierであると共にcredentialである、いわゆる認証トークンの一種であることに注意。

47


OIDCにおけるSSO✦RPからのAuthZ Requestに対して毎回ログインフォームを出して認証を行わない。

✦OP上でのセッションが生きていれば、それを認証とする。

✦結果、OP上でのセッションが生きている限り、どのOPから何回AuthZ Requestが来ても、ログインフォームが現れない。

48


OIDCにおけるSSO✦RPからのAuthZ Requestに対して毎回ログインフォームを出して認証を行わない。

✦OP上でのセッションが生きていれば、それを認証とする。

✦結果、OP上でのセッションが生きている限り、どのOPから何回AuthZ Requestが来ても、ログインフォームが現れない。

49

↑セッションによって EUとのインタラクションを

回避したフロー

#cmdevio2016 #A

Global Navigation Menu Service

50


Look and Feel✦ここまでの施策を適用した上で、各マイクロWebアプリケーション間で look & feel を合わせておけば、全体を1つのアプリケーションだと錯覚する。

✦ユーザは複数のWebアプリケーションを意識しない。

✦各Webアプリケーションの単位は、グローバルナビゲーションメニューの単位にほぼ等しい？（仮説）

51


Global Navigation Menu Service✦全てのWebアプリケーションが（概ね）共通して持つ、グローバルナビゲーションがある。

✦これを表示するためには、全てのWebアプリケーションが、SSOの輪の中にあるWebアプリケーションを相互に知っていなければならなくなる。

✦それを解消するために、「SSOの輪の中にあるWebアプリケーション」を管理し、ナビゲーションメニューを構築するために必要な情報を提供するサービスがあると良い。

52

#cmdevio2016 #A

まぁ、まだ、ない。

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 で繋ぐアーキテクチャ

http://bit.ly/cm-microwebapp

マイクロwebアプリケーション - developers.io 2016

Technology