マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

  • 説明を始めると、

    「単に「ユーザストアを使ってアプリを認証する。」ということではない。」

というトコロからの説明が必要になります。

導入

要件の確認

SSO(Single Sign-On)をサポートする。

  • 基本的に、

が必要。

  • スマホ認証の場合は、OAuth PKCEが必要。

認証 / 認可フレームワークをサポートする。

  • 認証 / 認可フレームワークとはなにか?
  • このフレームワーク中で各登場人物はどのようなロールを担うか?

(Web)APIエコノミーをサポートする。

システム間を連携させるAPI(Application Programing Interface)を通じて、
既存のサービスやデータをつなぎ、新たなビジネスや価値を生み出す仕組み。

ID連携、IDフェデレーション、Federated identityをサポートする。

  • 認証用のユーザストアと属性格納用のユーザストアを分離できる。
  • これにより、認証基盤の、
  • セキュリティ・レベル
  • ITガバナンス

を維持しつつ、アプリケーション、サービス側で、柔軟な対応をとることができる。

4つの登場人物

OAuth2の4つの登場人物」についての説明が必要。

Resource Owner

認証 / 認可を行うユーザー

Authorization Server

認証 / 認可の根幹となる機能を提供するプログラム。

  • IdPとSTSから構成される。
    • IdP
      • Identity Provider
      • サインアップ、サインイン・サインアウトの機能を提供。
  • STS

Resource Server

Authorization Serverに対応したWebAPIを提供するプログラム。

Client

Authorization Serverを使用してResource ServerのWebAPIにアクセスするプログラム。

  • Clientは、このtokenを使用して、Resource ServerのWebAPIにアクセスする。

適切なフローの選択

ベース クライアント セキュリティ モデル(基本)

サーバ信頼セキュリティ モデル(例外)

スマホの場合

よくある誤解

Cookie認証チケットとAccessToken?の違い

  • Cookie認証チケット
    • ログインは通常、Cookie認証チケットによって形成される「ログイン・セッション」に依存する。
    • 以下の2つの「ログイン・セッション」を別々に認識する必要がある。
      • Authorization Server側のCookie認証チケットによるログイン・セッション
      • Client側のCookie認証チケットによるログイン・セッション
  • AccessToken?
    AccessToken?はあくまで、
    • IdPで認証できたという結果をうけて
    • STSが生成・通知するtokenなので、

上記の2つのCookie認証チケットとは別物になる。

パッケージに、IdP/STSを組み込んだら上手くいく。

  • OSSコンソーシアム

詳細

そもそも認証から(IdP単品)

IdPの機能をフルサポートするのは大変

コチラが参考になる。

STSにより、独自ユーザストアから全社認証基盤へ。

  • システムやパッケージに独自ユーザストアを持つのは、
    非効率、且つ、セキュリティ的にも脆弱になり易いという問題を持つ。
  • IdPに、OAuth / OpenID ConnectなどのSTS機能を搭載すれば、
    SSO(Single Sign-On)によって、この問題を解決できる。

クロスプラットフォーム & コンパチブル

  • オープンなプロトコルを使用しているため、
    クロスプラットフォーム対応可能であること。
  • 故に、4つの登場人物がプラットフォームや言語に依存せず、
    クロスプラットフォーム & コンパチブルであることが求められる。

Authorization Serverからの視点

Authorization Server提供者は、

  • 様々なユーザストアに対応する必要がある。
  • OAuth 2.0のBearer TokenのJWT化が必要。
  • OAuth 2.0拡張 / OpenID Connectのサポートについて検討が必要。

Resource Serverからの視点

Resource Server提供者は、

  • 様々なAuthorization Serverと連携可能な提案を行う必要がある。
  • 上記2つをまとめて解決する、API Gatewayの導入を検討しても良い。

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系)を使うダケで頑張れるか?と言えばそんなこともありません。

カスタマイズ

ASP.NET Identity(2系)を覚えるダケでも、ある程度、大変ですが、
更に、IdP & STSは、カスタマイズが必要となるケースが多い。

Bearer Token

  • また、ASP.NET Identity(2系)のBearer Tokenは、ASP.NET Identityしか理解しないので、
  • 他のプラットフォームや言語で処理可能なようにJWT化が必要になってくる。

プロトコル

  • 生のASP.NET Identity(2系)は、OAuth 2.0拡張 / OpenID Connectをサポートしない。
  • このため、既定の実装では、より安全な認証 / 認可や、スマホ・ネイティブへの露出ができない。

参考

説明に使用した図

説明しながら伝導活動の重要性を感じた次第です。

OAuth / OpenID Connectによる課題解決

OSSコンソーシアム

課題解決

備忘録

  • OAuth2 / OpenID Connect課題解決 備忘録

Tags: :認証基盤, :クレームベース認証, :OAuth


添付ファイル: filetemp.png 49件 [詳細]

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-07-24 (火) 12:01:56 (24d)