「Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
汎用認証サイト（Multi-purpose Authentication Site）の独自仕様部分について説明する。
Idp仕様 †
概要 †
Idpの仕様については概ね、ASP.NET Identityに準拠。
ASP.NET Identity側の仕様については、「ASP.NET Identity」を参照。
カスタマイズ・ポイント †
以下のスイッチで大きな動作変更が可能。
詳しくは「汎用認証サイトのコンフィギュレーション」を参照のこと。
利用するサービス †
- Microsoft
- Google
- Facebook
ユーザ・アカウント †
主要属性 †
- UserName?はスイッチ次第
- 基本は、E-mailアドレス
- スイッチ変更により、任意の文字列を使用可能。
永続化 †
スキーマ †
DDL †
https://github.com/OpenTouryoProject/MultiPurposeAuthSite/tree/develop/root/files/resource/Sql
編集処理 †
サインアップ・サインイン †
サインアップとE-mailアドレス確認 †
- E-mailアドレスの確認（E-mail confirmation）は、
初回サインアップ後のレコードに対して行なう。
- E-mailアドレスの確認（E-mail confirmation）をしなかった場合、
- サインアップをしようとすると、サインアップ済みの旨が表示される。
- E-mailアドレス確認は、初回サインアップ後のレコード（ユーザID・PWD）に対して行なう。
- 初回サインアップ後、
- E-mailアドレス確認のメールをロストした場合、
サインインを繰り返せば、再び、E-mailアドレス確認メールは飛ぶ。
- パスワードを失念した場合、パスワード・リセットを行えばサインアップできる。
サインイン・サインアウト †
通常通り。
パスワード・リセット †
- パスワードを失念した場合
- サインアップ時のパスワードを失念した場合にも使用可能。
アカウント編集 †
パスワード †
- 変更
- 設定（外部ログイン後、ローカル・ログオンを可能にする場合）
電話番号 †
2要素認証 (2FA) のON/OFF
外部ログインの一覧表示と追加・削除
クレジット・カードの登録
属性データ（非定型データ） †
OAuth2データ †
ユーザ毎に、
- client_id
- client_secret
- redirect_uri（code）
- redirect_uri（token）
のデータを設定し、
OAuth2アクセストークンを取得可能。
2要素認証 †
有効化 †
アカウント編集にて有効化
他のブラウザでテスト †
- 有効化した後は、他のブラウザでテストする。
- 2要素認証はCookieを使用しているため、ブラウザ単位で行う。
運用 †
アカウント・ロックアウト †
指定回数、ログインをミスすると、指定時間ロックアウトされる。
パスワード・リセット †
- 例外的に以下のシナリオで使用する。
- 初回サインアップ時のパスワードを失念した場合のシナリオ。
- 外部ログイン後、ローカル・ログオンを可能にするシナリオ。
SecurityStamp? †
- アカウント編集後にサインアウトされる。
- アカウント編集後にサインアウト・サインインする実装になっている理由はコレ。
外部ログイン仕様 †
概要 †
概ね、ASP.NET Identityに準拠。
ASP.NET Identity側の仕様については、「ASP.NET Identityの外部ログイン」を参照。
カスタマイズ・ポイント †
外部ログイン処理の仕様について。
外部ログイン・サービス †
- Microsoft
- Google
- Facebook
- Twitter
外部ログインでサインアップ †
サインアップを外部ログインで行った場合、
- パスワードを持たないアカウントになる。
- この場合、後からパスワードを設定することで、ローカル・ログオンが可能になる。
- 管理画面でパスワード追加する。
- パスワード・リセットを行なう。
- E-mailアドレスの確認（E-mail confirmation）
- 外部ログイン処理で取得したE-mailアドレスは確認しない。
- E-mailアドレスでサインアップして、そのままサインインする。
外部ログインでサインイン †
- サインインのみ外部ログインで行った場合、
- 既存のアカウントに認証連携でサインインできる。
- 認証連携で必要なクレーム（属性値）を連携して上書きできる。
- UserName?やE-mailなど、変更できない属性値もある。
- 外部ログイン追加、サインアップ、サインインの成・否は既定の動作のため省略。
外部ログインの一覧と削除 †
- サインアップ済みの状態から外部ログインの追加 → 削除
外部ログイン削除後のタイミングで、ログアウトしていないのは、
代替のログイン手段を持っているため問題無いということ。
- サインアップせずに、外部ログインの追加 → 削除
- ローカル・ログオンを可能にしていない場合、最後の外部ログインを削除できなくなる。
- パスワード追加でローカル・ログオンを有効化すれば外部ログインを削除できる。
外部ログインの詳細 †
ExternalLoginCallback?の条件分岐
- (2) 外部ログインの有・無
- 既存の外部ログインがある → クレームを更新してサインイン（正常終了）
- 既存の外部ログインがない →新規の外部ログインの追加、(3) へ。
- (3) 外部ログインの追加
- 当該ユーザが既にサインアップされている。
→ 外部ログイン、クレームを追加してサインイン（正常終了）
- 当該ユーザが未だサインアップされていない。
→ サインアップ後に外部ログイン、クレームを追加してサインイン（正常終了）
- (2) 外部ログインの有・無
- 既存の外部ログインがある → クレーム更新のみ行う（正常終了）
- 既存の外部ログインがない →新規の外部ログインの追加、(3) へ。
- (3) 外部ログインの追加
- 当該ユーザが既にサインアップされている。
→ 外部ログイン、クレームを追加してサインイン（正常終了）
- 当該ユーザが未だサインアップされていない。
→ このケースはありえない。
- クレームの連携（追加・更新）時に、ユーザ属性を更新するかどうか？
- 案件毎に決定してカスタマイズする。
- 既定では、ユーザ属性の更新はしていない。
OAuth 2.0 Server仕様 †
概要 †
概ね、ASP.NET Identityに準拠。
については、「ASP.NET IdentityによるSTS実装」を参照。
共通 †
Server側 †
- AuthorizationServer?
- 認可エンドポイント
- redirect_uriチェックは不要（部分一致をサポートしない完全事前登録制とするため）
- Tokenエンドポイント（Access Tokenの発行方法）
- scope=その他の値の場合、scopeパラメタ値をClaimに格納する（通常の動作）。
Client側 †
- パラメタ
- redirect_uri指定は不要（部分一致をサポートしない完全事前登録制とするため）
- state指定は必須（ID Tokenのnonce Claimにコレを設定する）。
- ResourceServer?リソース・アクセス用のWeb APIにアクセスする場合、
- Access TokenをHTTPヘッダに指定して送信する。
Access Token †
- Access TokenのフォーマットにはJWTアサーションを使用する。
- このJWTアサーションには、OpenID Connectと同様のID Tokenを含める。
- Access TokenはOAuthAuthorizationServerOptions?.AccessTokenFormat?に設定した、モジュールで生成される。
- AccessTokenFormat?モジュールとの情報の受け渡しには、
クライアント認証 †
ここでのクライアントとは、ユーザではなく、OAuth 2.0 のClientを指しているので注意する。
- 認可エンドポイントでは、クライアント認証ではなく、Redirectエンドポイントの検証を行う。
- クライアント認証は、Tokenエンドポイントにアクセスする際に行なう。
- ベーシック認証の認証ヘッダを使用してクライアント識別子を送信する。
クライアント識別子 †
- GUIDを使用する
- 32文字の英数字。
- URLに指定するので、[{}, -] は無し。
- client_id
全てのグラント種別以外で必須
- client_secret
- Implicitグラント種別以外で必須
- ただし、ユーザ認証で使用する場合は、Implicitグラント種別でも必須。
ユーザ認証 †
Server側 †
- Access TokenにOpenID Connectと同様のID Token（JWTアサーション）を含める。
- ApplicationOAuthBearerTokenProvider?の実装
- ValidateClientRedirectUri?のオーバーライド
- xxxxx
Client側 †
- グラント種別
- できるだけ、Authorization Codeグラント種別を使用する。
- Implicitグラント種別もサポートするが、その場合、
ユーザ認証用Access Tokenとクライアント識別子の露見のリスクがあることに注意すること。
- 従って、できるだけ、JWTアサーションをClient側で検証することが推奨される。
- パラメタ
- response_typeには、"code"(推奨) or "token"を指定する。
- ResourceServer?のユーザ認証専用のWebAPIにアクセスする場合、
ResourceServer?のWebAPI †
- /api/OAuthResourceApi?/GetUserClaim?
使用するパラメタについて、コチラに纏めた。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
