「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- 多数のサイド（＝グループ）にまとわりつかれたプラットフォームの意味。
- シングルビジネスモデルからマルチビジネスモデルへ
- 2つ以上の顧客グループを互いに引き合わせる＝マッチメイク
- 相互依存の関係にある２つのグループをつなぎ合わせるプラットフォーム
認証サイト（Idp + STS） †
多用途認証サイト（Multi-purpose Authentication Site）
- User・Client（ = 認証サイトのクライアント）に、認証結果として、JWTアサーションを発行する。
- これにより、複数のUser・Clientを紐つけるマルチサイド・プラットフォームとして機能する。
IdP †
IdPはUser認証を行い、複数のUserを識別できる。
STS †
認証・認可 †
- また、OAuth2.0 などの STS をサポートすれば、
- User認証だけでなく（Authorization Codeグラント種別、Implicitグラント種別）、
- Client認証（Webサイトの認証）も可能（Client Credentialsグラント種別）
- 認証・認可の結果として、JWTアサーションをClient・UserAgent?に発行する。
- OAuth2.0で認証・認可云々の話はコチラを参考。
Claimの連携 †
処理に必要なClaim属性値をClient・UserAgent?に連携する。
User・Client †
User・Clientを特定するには、
- 認証サイト（Idp + STS）
- Client（Webサイト）
- UserAgent?（WWWブラウザなど）
間で、認証サイト（Idp + STS）がClient・UserAgent?に発行したJWTアサーションを交換し合う。
User †
Userは、OAuth2.0のAuthorization Code・Implicitグラント種別など、
認証連携プロトコルを使用して、単一のIdPで認証され、STSからJWTアサーションを取得する。
Client †
Clientは、OAuth2.0のClient Credentialsグラント種別を使用して、STSからJWTアサーションを取得する。
マルチサイド・プラットフォーム †
認証サイト（Idp + STS）をマルチサイド・プラットフォームとして機能させ、
User・Client、外部サービスを連携させる方法をいろいろと考える。
User・Client †
- JWTアサーションを交換し合うことで、
- 認証サイト（Idp + STS）
- Client（Webサイト）
- UserAgent?（WWWブラウザなど）
の間は身元を特定できる。
- 外部サービスとの連携については、
- 認証サイトのResources Serverにハブ実装を追加して集約するか、
- Client・UserAgent?から直接利用するかの二択になる。
外部サービス †
JWTアサーションを交換できない外部サービスが含まれてくると話は複雑になる。
Idp + STSをサポートする外部サービス †
- 例えば、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をサポートしない外部サービス †
- 例えば、基本認証や、OAuth 2.0のClient Credentialsグラント種別を使用して、
認証サイト（Resources Server）でWebAPIを集約するシナリオ。
- 通常の外部サービスは、ClientのCredentialsが必要になる。
なので、認証サイトが、マルチサイド・プラットフォームとして機能する場合、
認証サイト経由で認証サイトのCredentialsを使用して外部サービスを使用する。
- このパターンは無駄に認証サイト経由を強いるためイイ方法ではない可能性があるが、
認証サイト側が価値提案する機能で外部サービスのAPIの粒度を上げることができれば意味がある。
User・Client、外部サービスを連携させるユースケース †
認証サイト †
- 認証サイトは、複数のClientの認証基盤として機能する。
- 認証サイトは、Client・UserAgent?に、JWTアサーションを用いてUser・Clientの認証情報を提供する。
Client †
- ClientはWebサービスを公開する。
- Clientが公開したWebサービスは、使用したUser・Clientを適切に識別出来る。
- Clientは、自分以外のClientとJWTアサーションを交換することによって、
User・Clientへの申請や請求などの連携処理を実装できる。
外部サービス †
- Idp + STSをサポートする外部サービス
- Facebookと連携する場合。
- Facebookで外部ログイン
- FacebookのAccessToken?を使用して、Facebookに投稿を行う。
- StripeのConnect機能で、Standalone Accountを使用するケースなど、
認証とUser・Clientの接続の機能が外部サービスの内部に実装されているようなケース。
- StripeのConnect機能で、Managed Accountを使用するケースなど、
認証とUser・Clientの接続の機能が外部サービスの外部にオフロードされているようなケース。
- この場合、このオフロード処理は、認証サイトが担うため、
認証サイト経由で、外部サービス（ここでは、StripeのConnect機能）を使用する必要がある。
- 認証サイトで、外部サービス（ここでは、StripeのConnect機能）のアカウントを管理することで、
認証サイトは、User・Client、外部サービスを連携させるハブとして機能できる。
参考 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
