汎用認証サイトの独自仕様 のバックアップ(No.2)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• 汎用認証サイトの独自仕様 へ行く。
  • 1 (2017-05-22 (月) 11:04:53)
  • 2 (2017-06-22 (木) 13:56:00)
  • 3 (2017-06-29 (木) 20:13:41)
  • 4 (2017-06-30 (金) 14:41:06)
  • 5 (2017-06-30 (金) 17:44:40)
  • 6 (2017-06-30 (金) 20:36:39)
  • 7 (2017-06-30 (金) 21:38:34)
  • 8 (2017-07-03 (月) 10:45:20)
  • 9 (2017-07-03 (月) 14:54:33)
  • 10 (2017-07-04 (火) 17:37:37)
  • 11 (2017-07-13 (木) 14:50:14)
  • 12 (2017-07-28 (金) 20:12:16)
  • 13 (2017-08-02 (水) 17:03:12)
  • 14 (2017-10-25 (水) 16:06:22)
  • 15 (2018-05-21 (月) 09:44:37)
  • 16 (2018-06-15 (金) 10:02:15)
  • 17 (2018-07-30 (月) 16:47:17)
  • 18 (2019-05-10 (金) 09:56:06)
  • 19 (2019-06-05 (水) 17:45:59)
  • 20 (2019-06-07 (金) 11:14:25)

---

「Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

• 戻る

目次 †

概要 †

汎用認証サイト（Multi-purpose Authentication Site）の独自仕様部分について説明する。

Idp仕様 †

概要 †

Idpの仕様については概ね、ASP.NET Identityに準拠。

ASP.NET Identity側の仕様については、「ASP.NET Identity」を参照。

カスタマイズ・ポイント †

マルチテナント化スイッチ †

RequireUniqueEmail?スイッチ †

• RequireUniqueEmail? : true
  • UserName? = E-mailアドレス
  • インターネット環境の標準の実装はこちら。
  • E-mailアドレスでサインアップし、
    直ちにE-mailアドレスの確認（E-mail confirmation）を行う。

• RequireUniqueEmail? : false
  • UserName? = 任意文字列
  • ユーザストアを管理者が準備するエンプラ向き実装はこちら。

• E-mailアドレスの確認（E-mail confirmation）は不要
  • サインアップで、E-mailアドレスが提供されないので、
    E-mailアドレスの確認（E-mail confirmation）が実質的に不可能。
  • サインアップ画面を提供せず、管理者がアカウント（E-mailアドレス）を準備する。
  • 若しくは、サインアップ画面を提供し、"ユーザ名 @ サイトのドメイン"でメアドを準備するなどとする。

• 外部ログインの場合
  • サインアップ・サインインも可能ではある。
  • しかし、基本的には"外部ログイン = OFF"だと考える。

デバッグ用スイッチ †

• 切替方法
  • スイッチのON/OFF
  • ユーザストアへのアクセスにメモリ・プロバイダを指定している場合。

• 動作
  • デバッグ時：通知プロバイダを使用しない
  • 本番時：通知プロバイダを使用する

利用するサービス †

外部ログイン †

• Microsoft
• Google
• Facebook

オンライン決済サービス †

• Stripe
• PAY.JP

通知プロバイダ †

• SMTP
• SMS (Twilio)

ユーザ・アカウント †

主要属性 †

• UserId? = GUID

• UserName?はスイッチ次第
  • 基本は、E-mailアドレス
  • スイッチ変更により、任意の文字列を使用可能。

• Passwordの強度は下記の設定に従う。

永続化 †

• EntityFrameworkをキャンセルしUserStore?クラスで実装。
• DBMSはSQL Server or PostgreSQLを使用。
• Dapperを使用してデータアクセスを実装。

スキーマ †

DDL †

Githubをポイント予定

編集処理 †

• 管理画面でユーザ・ロールの属性値の編集が可能
• マルチテナント化している場合、テナント・データのみが対象になる。

• ユーザ管理
  • 管理者アカウントによるユーザ管理
  • 管理者アカウントとマルチテナント
    • マルチテナントの場合：サインアップ・ユーザ
    • マルチテナントでない場合：システム管理者
  • 編集可能な属性についてはこちら。

• ロール管理
  • 管理者アカウントによるユーザ管理
  • 管理者アカウントとマルチテナント
    • マルチテナントの場合：サインアップ・ユーザ
    • マルチテナントでない場合：システム管理者

サインアップ・サインイン †

サインアップとE-mailアドレス確認 †

• E-mailアドレスの確認（E-mail confirmation）は、
  初回サインアップ後のレコードに対して行なう。

• E-mailアドレスの確認（E-mail confirmation）をしなかった場合、
  
  • サインアップをしようとすると、サインアップ済みの旨が表示される。
  • E-mailアドレス確認は、初回サインアップ後のレコード（ユーザID・PWD）に対して行なう。

• 初回サインアップ後、
  • E-mailアドレス確認のメールをロストした場合、
    サインインを繰り返せば、再び、E-mailアドレス確認メールは飛ぶ。
  • パスワードを失念した場合、パスワード・リセットを行えばサインアップできる。

サインイン・サインアウト †

通常通り。

パスワード・リセット †

• パスワードを失念した場合
• サインアップ時のパスワードを失念した場合にも使用可能。

アカウント編集 †

パスワード †

• 変更
• 設定（外部ログイン後、ローカル・ログオンを可能にする場合）

外部ログイン †

外部ログインの一覧表示と追加・削除

電話番号 †

• 編集（設定・削除）が可能
• 通知プロバイダのSMSを使用。

二要素認証 (2FA) †

二要素認証 (2FA) のON/OFF

オンライン決済サービス †

クレジット・カードの登録

, etc. (任意項目を追加可能) †

二要素認証 †

有効化 †

アカウント編集にて有効化

他のブラウザでテスト †

• 有効化した後は、他のブラウザでテストする。
• 二要素認証は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?の条件分岐

• AccountController?
  • (1) 外部ログインの成否
    • 失敗（異常終了）
    • 成功、(2) へ。

• (2) 外部ログインの有・無
  • 既存の外部ログインがある → クレームを更新してサインイン（正常終了）
  • 既存の外部ログインがない →新規の外部ログインの追加、(3) へ。

• (3) 外部ログインの追加
  • 当該ユーザが既にサインアップされている。
    → 外部ログイン、クレームを追加してサインイン（正常終了）
  • 当該ユーザが未だサインアップされていない。
    → サインアップ後に外部ログイン、クレームを追加してサインイン（正常終了）

• ManageController?
  • (1) 外部ログインの成否
    • 失敗（異常終了）
    • 成功、(2) へ。

• (2) 外部ログインの有・無
  • 既存の外部ログインがある → クレーム更新のみ行う（正常終了）
  • 既存の外部ログインがない →新規の外部ログインの追加、(3) へ。

• (3) 外部ログインの追加
  • 当該ユーザが既にサインアップされている。
    → 外部ログイン、クレームを追加してサインイン（正常終了）
  • 当該ユーザが未だサインアップされていない。
    → このケースはありえない。

• クレームの連携（追加・更新）時に、ユーザ属性を更新するかどうか？
  • 案件毎に決定してカスタマイズする。
  • 既定では、ユーザ属性の更新はしていない。

OAuth 2.0 Server仕様 †

概要 †

概ね、ASP.NET Identityに準拠。

• ASP.NET Identity側の仕様
• OAuthを拡張した認証の仕様

については、「ASP.NET IdentityによるSTS実装」を参照。

共通 †

Server側 †

• AuthorizationServer?
  • 認可エンドポイント
    • redirect_uriチェックは不要（部分一致をサポートしない完全事前登録制とするため）
  • Tokenエンドポイント（Access Tokenの発行方法）
    • scope=その他の値の場合、scopeパラメタ値をClaimに格納する（通常の動作）。

• ResourceServer?
  • リソース・アクセス用のWeb APIを提供する。

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?モジュールとの情報の受け渡しには、
  • ASP.NET Identityの仕組みに準拠し、ClaimsIdentity?を使用する。
  • ClaimsIdentity?には、以下のようなURN形式の文字列をkeyに使用して、
    OAuthAuthorizationServer?側からvalueの追加を行う（以下はscopeの値を設定する例）。

    claimsIdentity.AddClaim(new Claim("urn:oauth:scope", xxxxx));

クライアント認証 †

ここでのクライアントとは、ユーザではなく、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
    • xxxxxxxxxx

• クライアント識別子は全てのグラント種別で必須となる。

Client側 †

• グラント種別
  • できるだけ、Authorization Codeグラント種別を使用する。
  • Implicitグラント種別もサポートするが、その場合、
    ユーザ認証用Access Tokenとクライアント識別子の露見のリスクがあることに注意すること。
  • 従って、できるだけ、JWTアサーションをClient側で検証することが推奨される。

• パラメタ
  • response_typeには、"code"(推奨) or "token"を指定する。

• ResourceServer?のユーザ認証専用のWebAPIにアクセスする場合、
  • ユーザ認証用Access Tokenに加え、前述のクライアント識別子をPOSTで送信する。

ResourceServer?のWebAPI †

• /api/OAuthResourceApi?/GetUserClaim?

パラメタ化 †

• ASP.NET Identityや、
• 汎用認証サイトのアプリケーションで

使用するパラメタについて、コチラに纏めた。

     

Site admin: OpenTouryo

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.065 sec.