「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- 説明を始めると、
「単に「ユーザストアを使ってアプリを認証する。」ということではない。」
というトコロからの説明が必要になります。
導入 †
要件の確認 †
SSO（Single Sign-On）をサポートする。 †
が必要。
認証 / 認可フレームワークをサポートする。 †
- 認証 / 認可フレームワークとはなにか？
- このフレームワーク中で各登場人物はどのようなロールを担うか？
（Web）APIエコノミーをサポートする。 †
システム間を連携させるAPI(Application Programing Interface)を通じて、
既存のサービスやデータをつなぎ、新たなビジネスや価値を生み出す仕組み。
ID連携、IDフェデレーション、Federated identityをサポートする。 †
- 認証用のユーザストアと属性格納用のユーザストアを分離できる。
を維持しつつ、アプリケーション、サービス側で、柔軟な対応をとることができる。
4つの登場人物 †
「OAuth2の4つの登場人物」についての説明が必要。
Resource Owner †
認証 / 認可を行うユーザー
Authorization Server †
認証 / 認可の根幹となる機能を提供するプログラム。
- IdPとSTSから構成される。
- IdP
- Identity Provider
- サインアップ、サインイン・サインアウトの機能を提供。
Resource Server †
Authorization Serverに対応したWebAPIを提供するプログラム。
Client †
Authorization Serverを使用してResource ServerのWebAPIにアクセスするプログラム。
よくある誤解 †
Cookie認証チケットとAccessToken?の違い †
- Cookie認証チケット
- ログインは通常、Cookie認証チケットによって形成される「ログイン・セッション」に依存する。
- 以下の2つの「ログイン・セッション」を別々に認識する必要がある。
- Authorization Server側のCookie認証チケットによるログイン・セッション
- Client側のCookie認証チケットによるログイン・セッション
- AccessToken?
AccessToken?はあくまで、
- IdPで認証できたという結果をうけて
- STSが生成・通知するtokenなので、
上記の２つのCookie認証チケットとは別物になる。
詳細 †
そもそも認証から（IdP単品） †
IdPの機能をフルサポートするのは大変 †
コチラが参考になる。
STSにより、独自ユーザストアから全社認証基盤へ。 †
- システムやパッケージに独自ユーザストアを持つのは、
非効率、且つ、セキュリティ的にも脆弱になり易いという問題を持つ。
クロスプラットフォーム & コンパチブル †
- オープンなプロトコルを使用しているため、
クロスプラットフォーム対応可能であること。
- 故に、4つの登場人物がプラットフォームや言語に依存せず、
クロスプラットフォーム & コンパチブルであることが求められる。
Authorization Serverからの視点 †
Authorization Server提供者は、
Resource Serverからの視点 †
Resource Server提供者は、
- 様々なAuthorization Serverと連携可能な提案を行う必要がある。
Clientからの視点 †
Client提供者は、
- 使用するAuthorization Server、Resource Serverを選択する。
- この場合、サポートされるFlowやTokenのフォーマットを理解する必要がある。
IDフェデレーションの段階 †
以下の、3つの段階がある。
Single †
Client *--- IdP (Authorization Server)
- IdPのみユーザストアを持つ。
Clientは、
- 認証結果のClaimをAuthorization Serverから受け取り、
- 認証済みの処理を行う。
- IdPとClientがユーザストアを持つ。
Clientは、
- 認証結果のClaimをAuthorization Serverから受け取り、
- Claimをユーザストアに格納し、
- そこに補足的ユーザ属性を加え、
- 認証済みの処理を行う。
Hybrid †
Hybrid-IdP (Client *--- IdP2 *--- IdP1)
- IdP1とIdP2がユーザストアを持つ。
Clientから要求を受けた、Authorization Server1は、
- 認証結果のClaimをAuthorization Server2から受け取り、
- ClaimをAuthorization Server1のユーザストアに格納し、
- そこに補足的ユーザ属性を加え、
- 次いで、要求元のClientに、認証結果のClaimを返す。
- 最後に、Clientは、認証済みの処理を行う。
- ClientとIdP1とIdP2がユーザストアを持つ。
Clientから要求を受けた、Authorization Server1は、
- 認証結果のClaimをAuthorization Server2から受け取り、
- ClaimをAuthorization Server1のユーザストアに格納し、
- そこに補足的ユーザ属性を加え、
- 次いで、要求元のClientに、認証結果のClaimを返す。
- Clientは
- Claimをユーザストアに格納し、
- そこに補足的ユーザ属性を加え、
- 認証済みの処理を行う。
※ 認証はAuthorization Server2で、属性編集はAuthorization Server1で可能。
@.net †
ASP.NET Identity（2系）を使うダケで頑張れるか？と言えばそんなこともありません。
カスタマイズ †
ASP.NET Identity（2系）を覚えるダケでも、ある程度、大変ですが、
更に、IdP & STSは、カスタマイズが必要となるケースが多い。
Bearer Token †
プロトコル †
参考 †
説明に使用した図 †
説明しながら伝導活動の重要性を感じた次第です。
OSSコンソーシアム †
Tags: :認証基盤, :クレームベース認証, :OAuth
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
