![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「[[.NET 開発基盤部会 Wiki>http://dotnetdevelopmentinfrastructure.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -戻る --[[企画]] --[[SaaS設計のポイント]] *目次 [#q3448ed0] #contents *概要 [#qd1e9d05] -多数のサイド（＝グループ）にまとわりつかれたプラットフォームの意味。 --シングルビジネスモデルからマルチビジネスモデルへ --2つ以上の顧客グループを互いに引き合わせる＝マッチメイク --相互依存の関係にある２つのグループをつなぎ合わせるプラットフォーム -マルチサイド・プラットフォームとして機能するであろう認証サイト（Idp + STS）、~ [[多用途認証サイト（Multi-purpose Authentication Site）>認証基盤]]のユースケースをいろいろと考えている。 *認証サイト（Idp + STS） [#p5066930] [[多用途認証サイト（Multi-purpose Authentication Site）>認証基盤]] -User・Client（ = 認証サイトのクライアント）に、認証結果として、JWTアサーションを発行する。 -これにより、複数のUser・Clientを紐つけるマルチサイド・プラットフォームとして機能する。 **IdP [#ea5c6594] IdPはUser認証を行い、複数のUserを識別できる。 **STS [#x152ba45] ***認証・認可 [#x6080f3b] -また、OAuth2.0 などの STS をサポートすれば、 --User認証だけでなく（Authorization Codeグラント種別、Implicitグラント種別）、 --Client認証（Webサイトの認証）も可能（Client Credentialsグラント種別） -認証・認可の結果として、JWTアサーションをClient・UserAgentに発行する。 -OAuth2.0で認証・認可云々の話は[[コチラ>https://techinfoofmicrosofttech.osscons.jp/index.php?OAuth#add861ca]]を参考。 ***Claimの連携 [#l0fc6611] 処理に必要なClaim属性値をClient・UserAgentに連携する。 *User・Client [#neee7ba7] User・Clientを特定するには、 -認証サイト（Idp + STS） -Client（Webサイト） -UserAgent（WWWブラウザなど） 間で、認証サイト（Idp + STS）がClient・UserAgentに発行したJWTアサーションを交換し合う。 **User [#c933fad9] Userは、OAuth2.0のAuthorization Code・Implicitグラント種別など、~ 認証連携プロトコルを使用して、単一のIdPで認証され、STSからJWTアサーションを取得する。 **Client [#p1327831] Clientは、OAuth2.0のClient Credentialsグラント種別を使用して、STSからJWTアサーションを取得する。 *マルチサイド・プラットフォーム [#j22c90ae] 認証サイト（Idp + STS）をマルチサイド・プラットフォームとして機能させ、~ User・Client、[[外部サービス>#r76af078]]を連携させる方法をいろいろと考える。 **User・Client [#za795d8c] -JWTアサーションを交換し合うことで、認証サイト（Idp + STS）、Client、UserAgentの間は身元を特定できる。 -JWTアサーションを交換し合うことで、 --認証サイト（Idp + STS） --Client（Webサイト） --UserAgent（WWWブラウザなど） >の間は身元を特定できる。 -[[外部サービス>#r76af078]]との連携については、 --認証サイトのResources Serverにハブ実装を追加して集約するか、 --Client・UserAgentから直接利用するかの二択になる。 **外部サービス [#r76af078] JWTアサーションを交換できない外部サービスが含まれてくると話は複雑になる。 ***Idp + STSをサポートする外部サービス [#j1bf1029] -例えば、OAuth 2.0のAuthorization Code・Implicitグラント種別を使用して、~ Client・UserAgentから直接WebAPIを利用するシナリオ。 --Client・UserAgentが外部サービスを直接利用する場合、外部サービスのTokenを連携する。 --これには、外部サービスが、Client IDやClient Secretを必要とせず、Tokenだけで使用できる必要がある。 --以下は、外部サービス → 認証サイト → Client・UserAgentと、Tokenを連携する方法。 ---外部サービスと連携し、認証サイトはTokenを取得する。 ---Clientは、認証サイトと連携し、TokenをClaimとして要求・取得する。 ***Idpをサポートしない外部サービス [#pdc2fca1] -例えば、基本認証や、OAuth 2.0のClient Credentialsグラント種別を使用して、~ 認証サイト（Resources Server）でWebAPIを集約するシナリオ。 --通常の外部サービスは、ClientのCredentialsが必要になる。~ なので、認証サイトが、マルチサイド・プラットフォームとして機能する場合、~ 認証サイト経由で認証サイトのCredentialsを使用して外部サービスを使用する。 --このパターンは無駄に認証サイト経由を強いるためイイ方法ではない可能性があるが、~ 認証サイト側が価値提案する機能で外部サービスのAPIの粒度を上げることができれば意味がある。~ **User・Client、外部サービスを連携させるユースケース [#pb0111b4] ***認証サイト [#y26267de] -認証サイトは、複数のClientの認証基盤として機能する。 -認証サイトは、Client・UserAgentに、JWTアサーションを用いてUser・Clientの認証情報を提供する。 ***Client [#a248af7f] -ClientはWebサービスを公開する。 -Clientが公開したWebサービスは、使用したUser・Clientを適切に識別出来る。 -Clientは、自分以外のClientとJWTアサーションを交換することによって、~ User・Clientへの申請や請求などの連携処理を実装できる。 ***外部サービス [#j9527e8f] -Idp + STSをサポートする外部サービス --Facebookと連携する場合。 ---Facebookで外部ログイン ---FacebookのAccessTokenを使用して、Facebookに投稿を行う。 --[[Stripe]]のConnect機能で、Standalone Accountを使用するケースなど、~ 認証とUser・Clientの接続の機能が外部サービスの内部に実装されているようなケース。 -Idpをサポートしない外部サービス --[[Stripe]]のConnect機能で、Managed Accountを使用するケースなど、~ 認証とUser・Clientの接続の機能が外部サービスの外部にオフロードされているようなケース。 ---この場合、このオフロード処理は、認証サイトが担うため、~ 認証サイト経由で、外部サービス（ここでは、[[Stripe]]のConnect機能）を使用する必要がある。 ---認証サイトで、外部サービス（ここでは、[[Stripe]]のConnect機能）のアカウントを管理することで、~ 認証サイトは、User・Client、外部サービスを連携させるハブとして機能できる。 *参考 [#be115182] -ビジネスモデル・キャンバスのパターンについて~ インバウンドマーケティング/Facebookアプリ/Web制作 Hivelocity ハイベロシティ~ https://www.hivelocity.co.jp/blog/17328 -マルチサイドプラットフォームのパターン - 研究所blog~ http://www.manegement-tk.jp/blog/2014/05/post-1955.html -マルチサイドプラットフォーム戦略からのケース分析 (No.758) | 経営からの地域再生・都市再生 [木下斉]~ http://blog.revitalization.jp/?eid=697446 -顧客獲得コストを劇的に削減し売上を飛躍的に伸ばすマルチサイド - 『ビジネスパーソン最強化プロ... - 総務の森~ http://www.soumunomori.com/column/article/atc-110843/
