Multi-AuthSystem独自仕様のバックアップ(No.6)

バックアップ一覧
ソースを表示
Multi-AuthSystem独自仕様は削除されています。
- 1 (2016-12-20 (火) 09:04:23)
- 2 (2016-12-20 (火) 11:45:53)
- 3 (2016-12-20 (火) 18:38:18)
- 4 (2016-12-20 (火) 20:09:06)
- 5 (2016-12-21 (水) 12:59:03)
- 6 (2016-12-22 (木) 13:16:40)
- 7 (2016-12-22 (木) 17:38:51)

Open棟梁 wiki

戻る?

↑

概要 †

Multi-AuthSystem?独自仕様部分について説明する。

↑

Idp仕様 †

Idpの使用について。

↑

概要 †

概ね、ASP.NET Identityに準拠。

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

↑

カスタマイズポイント †

↑

ユーザアカウント †

UserId? = e-mail address = UserName?とする。
Passwordの強度は下記の設定に従う。

↑

UserStore? †

EntityFramework?をキャンセルしUserStore?クラスで実装。
DBMSはSQL Server or PostgreSQLを使用。
Open棟梁のB・D層を使用してデータアクセスを実装。

↑

パラメタ化 †

ASP.NET Identityや、その他、アプリケーションで使用するパラメタについて。

↑

SecurityStamp? †

<!-- SecurityStamp（検証間隔は10秒、本番は長めに設定-->
<add key="SecurityStampValidateIntervalFromSeconds" value="10" />

↑

ユーザ名と、その検証 †

<!--ユーザ名検証（ユーザ名は、E-mail-->
<add key="AllowOnlyAlphanumericUserNames" value="false" />
<add key="RequireUniqueEmail" value="true" />

↑

パスワード検証 †

<!--パスワード検証（8文字以上の大文字・小文字、数値、記号-->
<add key="RequiredLength" value="8" />
<add key="RequireNonLetterOrDigit" value="true" />
<add key="RequireDigit" value="true" />
<add key="RequireLowercase" value="true" />
<add key="RequireUppercase" value="true" />

↑

ユーザロックアウト †

<!--ユーザ ロックアウト（5 回入力ミスすると、5分ロックアウト-->
<add key="UserLockoutEnabledByDefault" value="true" />
<add key="DefaultAccountLockoutTimeSpanFromSeconds" value="300" />
<add key="MaxFailedAccessAttemptsBeforeLockout" value="5" />

↑

二要素認証 †

<!-- 二要素認証（2FA:TwoFactorAuthentication）-->
<!-- 必要に応じてユーザが有効にするので初期値は false -->
<add key="TwoFactorEnabled" value="false" /> 
<!-- Cookieの有効期限は二週間 24 * 14 = 336 時間 -->
<add key="TwoFactorCookieExpiresFromHours" value="336" />

↑

外部認証仕様（≒ OAuth 2.0 Client仕様） †

「≒」としたのは、外部認証の主要プロトコルがOAuth 2.0であって、
今後、OpenID Connectなどの他のプロトコルに置き換えられていく可能性があるため。

↑

概要 †

概ね、ASP.NET Identityに準拠。

ASP.NET Identity側の仕様については、「ASP.NET Identityの外部ログイン」を参照。

↑

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

外部認証処理の仕様について。

外部認証処理で取得したe-mail addressは検証しない。
e-mail addressでサインアップして、そのままサインインする。
初回のサインアップを外部認証で行った場合、パスワードを持たないアカウントになる。
この場合、後からパスワードを持ったアカウントとしての登録が不可能になる（★パスワードリセット不可能？）。

↑

パラメタ化 †

以下のように各、外部ログイン・プロバイダの（OAuth等）の

有効化・無効化
クライアント認証のためのクライアント識別子

を設定できる。

<!-- 外部ログインの追加時に XSRF の防止 -->
<add key="XsrfKey" value="(サイト毎にで変更する、公開しないこと)" />
 
<!--外部ログイン（MicrosoftAccountAuthentication）-->
<add key="MicrosoftAccountAuthentication" value="true" />
<add key="MicrosoftAccountAuthenticationClientId" value="・・・" />
<add key="MicrosoftAccountAuthenticationClientSecret" value="・・・" />
 
<!--外部ログイン（GoogleAuthentication）-->
<add key="GoogleAuthentication" value="true" />
<add key="GoogleAuthenticationClientId" value="・・・" />
<add key="GoogleAuthenticationClientSecret" value="・・・" />
 
<!--外部ログイン（FacebookAuthentication）-->
<add key="FacebookAuthentication" value="true" />
<add key="FacebookAuthenticationClientId" value="・・・" />
<add key="FacebookAuthenticationClientSecret" value="・・・" />

↑

設定値の取得方法など †

クライアント識別子は、外部ログイン・サービスの管理画面から取得する。

合わせてここでRedirectエンドポイントの設定などを行う必要がある。
これは、外部ログイン・サービス毎に設定方法が異なるので注意する。

例えばマイクロソフト・アカウントでは、以下の様な設定を行う。、

https://fqdnname:nnnnn/signin-microsoft

外部ログイン・サービスによっては、
httpやlocalhostをサポートしないことがある。

マイクロソフト・アカウントでは、部分一致をサポートしており、
Redirectエンドポイントの以降のパスはredirect_uriから指定する。

外部ログインは、HttpUnauthorizedResultのActionResult?を返すことで開始する。
redirect_uriはHttpUnauthorizedResult?のコンストラクタから指定できる。

↑

XsrfKey? †

asp.net mvc 5 - What is the XsrfKey? used for and should I set the XsrfId? to something else? - Stack Overflow
http://stackoverflow.com/questions/32121504/what-is-the-xsrfkey-used-for-and-should-i-set-the-xsrfid-to-something-else

XsrfKey?は、XSRF = CSRFを防ぐためのstateパラメタの生成に使用される。
stateパラメタは暗号化によって生成されるので、XsrfKey?自体が露見することはない。
従って、この値としても、無作為な値を使用する必要はない。

↑

OAuth 2.0 Server仕様 †

↑

概要 †

概ね、ASP.NET Identityに準拠。

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

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

↑

共通 †

↑

Server側 †

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

ResourceServer?
- リソース・アクセス用のWebAPIを提供する。
  - "urn:oauth:scope"のClaimがあった場合、scopeの値に適合した範囲のアクセス権で処理を行う。

↑

Client側 †

パラメタ
- redirect_uri指定は不要（部分一致をサポートしない完全事前登録制とするため）
- stateの使用を強く推奨する（Access Token露見は、Client側の自己責任のため）。

ResourceServer?リソース・アクセス用のWebAPIにアクセスする場合、
- Access TokenをHTTPヘッダに指定して送信する。

↑

Access Tokenへの情報格納方法 †

ClaimsIdentity?を使用する。以下のようなURN形式をkeyに使用してvalueの追加を行う。

"scope=auth"の場合（Access Tokenがユーザ認証用であることを意味する。詳しくは下記参照）
```
claimsIdentity.AddClaim(new Claim("urn:oauth:auth", client_id));
```

"scope=その他の値"の場合、

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

↑

クライアント認証 †

ここでのクライアントとは、OAuth 2.0 のClientを指しているので注意する。

認可エンドポイントでは、クライアント認証ではなく、Redirectエンドポイントの検証を行う。
クライアント認証は、Tokenエンドポイントにアクセスする際に行なう。
ベーシック認証の認証ヘッダを使用してクライアント識別子を送信する。

↑

クライアント識別子 †

GUIDを使用する
- 32文字の英数字。
- URLに指定するので、[{}, -] は無し。

client_id
全てのグラント種別以外で必須
client_secret
- Implicitグラント種別以外で必須
- ただし、ユーザ認証で使用する場合は、Implicitグラント種別でも必須。

↑

ユーザ認証 †

ユーザ認証に利用する場合、以下の仕様に準拠する。
クライアント識別子は全てのグラント種別で必須

↑

Server側 †

AuthorizationServer?
- Tokenエンドポイント（Access Tokenの発行方法）
  - scope=authの場合、client_idをClaimに格納し、Access Tokenがユーザ認証用であることを明示する。

ResourceServer?
- ユーザ認証専用のWebAPIを提供する。
  - "urn:oauth:auth"のClaimがあった場合、Access Tokenがユーザ認証用であることを意味する。
  - この場合、POSTされたクライアント識別子でクライアント認証をした後、
    そのClaim値とclient_idを比較してTokenに問題がないかをチェックする。

↑

Client側 †

グラント種別
- できるだけ、Authorization Codeグラント種別を使用する。
- Implicitグラント種別もサポートするが、その場合、
  ユーザ認証用Access Tokenとクライアント識別子の露見のリスクがあることに注意すること。

パラメタ
- response_typeには、"code"(推奨) or "token"を指定する。
- ユーザ認証を行なう場合、scopeパラメタに"auth"を指定する。

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

↑

ResourceServer?のWebAPI †

認証専用のWebAPI
- /api/OAuthResourceApi?/GetAuthenticatedUsersClaim?

リソース・アクセス用のWebAPI
- /api/OAuthResourceApi?/XXXXX

↑

パラメタ化 †

↑

共通設定 †

<add key="EquipOAuthServer" value="true" />
<add key="OAuthIssuerId" value="IssuerId:サイト毎にGUIDの32文字を生成して設定" />
<add key="AllowOAuthInsecureHttpEndpoints" value="true" />
<add key="OAuthAuthorizeEndpointCanDisplayErrors" value="true" />
<add key="OAuthAccessTokenExpireTimeSpanFromMinutes" value="360" />

↑

Server側エンドポイント †

Multi-AuthSystem?が保有するエンドポイントなで、相対パスで良い。

<!-- 認可エンドポイント -->
<add key="OAuthAuthorizeEndpoint" value="/Account/OAuthAuthorize" />
<!-- Tokenエンドポイント -->
<add key="OAuthBearerTokenEndpoint" value="/OAuthBearerToken" />
<!-- ResourceServerエンドポイント -->
<add key="OAuthAuthenticateAPI" value="/api/OAuthResourceApi/Authenticate" />
<add key="OAuthAuthorizedUserClaimAPI" value="/api/OAuthResourceApi/GetAuthorizedUserClaim" />

↑

Client側エンドポイント †

Clientだが、Multi-AuthSystem?が保有するセルフRedirectエンドポイントなので、相対パスで良い。

<!-- Redirectエンドポイント -->

<!--  - self_code : Authorization Codeグラント種別 -->
<add key="OAuthAuthorizationCodeGrantClient" value="/Account/OAuthAuthorizationCodeGrantClient" />

<!--  - self_token : Implicitグラント種別 -->
<add key="OAuthImplicitGrantClient" value="/Account/OAuthImplicitGrantClient" />

↑

クライアント認証用の識別子登録 †

<!-- クライアント識別子 (client_id, client_secret, redirect_uri) -->
<add key="OAuthClientsInformation" value='
  {
    "client_idとしてサイト毎にGUIDの32文字を生成して設定": {
   "client_secret": "サイト毎にGUIDの32文字を生成して設定",
   "redirect_uri": "self_code"
    },
    "client_idとしてサイト毎にGUIDの32文字を生成して設定": {
   "client_secret": "サイト毎にGUIDの32文字を生成して設定",
   "redirect_uri": "self_token"
    },
    "client_idとしてサイト毎にGUIDの32文字を生成して設定": {
   "client_secret": "サイト毎にGUIDの32文字を生成して設定",
   "redirect_uri": "self_token_web"
    },
    "client_idとしてサイト毎にGUIDの32文字を生成して設定": {
   "client_secret": "サイト毎にGUIDの32文字を生成して設定",
   "redirect_uri": "self_token_mob:アプリ間連携用URI"
    },
    "client_idとしてサイト毎にGUIDの32文字を生成して設定": {
   "client_secret": "サイト毎にGUIDの32文字を生成して設定",
   "redirect_uri": "http://hogehoge/・・・"
    },
   ・・・
  }
  ' />

↑

セルフRedirectエンドポイント †

テスト用のRedirectエンドポイントだが、
スマホネイティブの認証などでサイトを構築せず利用可能。

↑

self_code †

"redirect_uri": "self_code"

Authorization Codeグラント種別を検証するRedirectエンドポイント。
用途はテスト用（本番用には使用しないこと）
- Access TokenやRefresh Tokenを含むHTMLをreturnする。
  （あくまで検証用であり、本番ではTokenをreturnしないこと）
- サーバ側でResourceServer?にアクセスした結果を含むHTMLをreturnする。

↑

self_token, self_token_web †

"redirect_uri": "self_token"
"redirect_uri": "self_token_web"

Implicitグラント種別を検証するRedirectエンドポイント。
用途はテスト用（本番用には使用しないこと）
- Access Tokenを含むHTML＋JavaScript?をreturnする。

↑

self_token_mob †

"redirect_uri": "self_token_mob"

Implicitグラント種別を検証するRedirectエンドポイント。
用途はテスト用だけでなく、本番用も想定している。
- Access Tokenを含むHTML＋JavaScript?をreturnし、
  事前登録したアプリ間連携用URIを使用してアプリ間でAccess Tokenを受け渡す。
- ネイティブ・アプリでは、コレを使用して認証・認可が可能。

Multi-AuthSystem独自仕様 のバックアップ(No.6)

目次 †

概要 †

Idp仕様 †

概要 †

カスタマイズポイント †

ユーザアカウント †

UserStore? †

パラメタ化 †

SecurityStamp? †

ユーザ名と、その検証 †

パスワード検証 †

ユーザ ロックアウト †

二要素認証 †

外部認証仕様（≒ OAuth 2.0 Client仕様） †

概要 †

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

パラメタ化 †

設定値の取得方法など †

XsrfKey? †

OAuth 2.0 Server仕様 †

概要 †

共通 †

Server側 †

Client側 †

Access Tokenへの情報格納方法 †

クライアント認証 †

クライアント識別子 †

ユーザ認証 †

Server側 †

Client側 †

ResourceServer?のWebAPI †

パラメタ化 †

共通設定 †

Server側エンドポイント †

Client側エンドポイント †

クライアント認証用の識別子登録 †

セルフRedirectエンドポイント †

self_code †

self_token, self_token_web †

self_token_mob †

Multi-AuthSystem独自仕様のバックアップ(No.6)

ユーザロックアウト †