Commits

hideki nara committed faa053c

文書ほぼ完了

Comments (0)

Files changed (7)

source/about.rst

-==============================================
-Django で Social します
-==============================================
-
-.. contents::
-    :local:
-    :depth: 2
-    :class: talks-contents
-
-django-social-auth いれると簡単
-======================================
-
-- https://github.com/omab/django-social-auth
-- http://django-social-auth.readthedocs.org/en/latest/
-
-OpenID Connect対応するには?
-======================================
 
 html_theme = 'talks' # HDKNR
 html_theme_path = ['../themes',] #HDKNR
+html_theme_options = {
+    "linkcolor": "red",
+    "visitedlinkcolor": "green"
+}
 exclude_patterns = ['install/*.rst',]
 
 intersphinx_mapping.update({

source/github.reg.rst

 - OAuthの認証リクエストを行うときに client_idが必要です
 - OAuth Servr(Github) と OAuth Client(Django アプリケーションを関係付けます )
 - 登録するとID(client_id)とパスワード(client_secret)がもらえます(Webアプリのクレデンシャル)。
+- 登録は https://github.com/settings/applications から行います。
 
 .. image:: _static/github.reg/1.png
 
+アプリケーション名とURL
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
 .. image:: _static/github.reg/2.png
 
+Callback URL 重要
+^^^^^^^^^^^^^^^^^^
+
+- OAuth2 の  Authorization Response をアプリケーションに返す先のURLです。
+- :term:`Authorization Request` の :term:`redirect_uri` とのマッチングが行われる文字列になります。
+
 .. image:: _static/github.reg/3.png
 
+登録された
+^^^^^^^^^^^^^^^^^^
+
+- Client ID  /  Client Secret が生成されています.
+
+
 .. image:: _static/github.reg/4.png
 
 クライアント登録するとクレデンシャルをもらえます
 ---------------------------------------------------------------
 
-- ユーザーがGithubに対するOAuth 認証リクエストの結果、Djangoアプリ用の「コード」がもらえます。
-- これをWebアプリに設定し、Webアプリはこれを使って認可リクエストを作成し、認可応答の情報を使ってアクセストークンを取得したりする事が
-  できます。
+- クレデンシャルの Client ID はユーザーがGithubに対するOAuth :term:`認可リクエスト`  の client_id になります。
+
+    - これにより、ユーザーが認可して発行するアクセストークンの相手がclient_idで示されたWebアプリケーションである事がわかります。
+
+- Client Secret は :term:`認可応答` でもらった「コード」を 認可サーバーで「アクセストークン」に引き換えてもらう時に必要になります。 
+
+    - clinet_id + client_secret で WebアプリケーションはHTTP基本認証で認可サーバーに直接HTTP POSTをおこないます。
+      ( :term:`クライアント認証` /  基本認証以外もプロトコルでは定義されています )
 
 OAuth : 「コードフロー」によるアクセストークンの取得
 ---------------------------------------------------------------
 
 - ユーザーがWebアプリに訪れます。
-- GithubのAPIを使ったWebアプリのサービスを受けたいので、「認可リクエスト」を行います。
+- GithubのAPIを使ったWebアプリのサービスを受けたいので、「 :term:`認可リクエスト` 」を行います。
 - ブラウザがGithubに認可リクエストを持って訪れるので、ユーザーはGithubにログインし、「Webアプリ」に代理アクセスすることを許可します。
-- ブラウザが認可応答を持って、Webアプリに戻ってきます。その中にユーザーがGithubのリソースをWebアプリに代理アクセスすることを許可したことをいみする「コード」が含まれています。
-- もらったコードをつかってWebアプリはGithubの「アクセストークン交換場所」に直接アクセスします。
+- ブラウザが :term:`認可応答` を持って、Webアプリに戻ってきます。
+  その中にユーザーがGithubのリソースをWebアプリに代理アクセスすることを許可したこと(grant)を意味する「コード」が含まれています。
+- もらったコードを使ってWebアプリはGithubの「アクセストークン交換場所  (:term:`Token Endpoint`)  」に直接アクセスします。
 - その際、コードを「アクセストークン」に変換する為に、Webアプリはクライアント登録で取得したクレデンシャルで認証を受けます。
+  ( :term:`クライアント認証` )
 - Webアプリが正しく認証されると、コードと引き換えにアクセストークンをもらいます。
-- 以上の流れは「コードフロー」と呼ばれて、もっともポピュラーといえるOAuthのフローです。
+- 以上の流れは「 :term:`コードフロー` 」と呼ばれて、もっともポピュラーといえる :term:`OAuth` のフローです。
 
 WebアプリがGithub APIを使ってサービスを提供する
 -----------------------------------------------------
 
-- Webアプリはアクセストークンを得たので、このアクセストークンを使ってGithub APIで定義されているURLにリクエストを行い、正しいトークンであればサービスを受ける事ができます。
+- Webアプリはアクセストークンを得たので、
+  このアクセストークンを使ってGithub APIで定義されているURLにリクエストを行い、
+  正しいトークンであればサービスを受ける事ができます。
 
-- :doc:`github`
+- :doc:`github` のAPIが使えます。
 

source/github.rst

 
 - http://developer.github.com/v3/search/
 
+
+.. _github.auth:
+
+リクエスト認証
+==================
+
+- http://developer.github.com/v3/#authentication
+
+
+.. _github.auth.basic:
+
+基本認証
+----------
+
+- いわゆるBasic Auth です。
+
+OAuth
+------
+
+- http://developer.github.com/v3/oauth/
+
+OAuth2:トークン(Authorization Header )
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+- 基本的にはこれを使いましょう。
+- :term:`OAuth Bearer` トークンです。
+- "Bearer"の代わりに "token"でもOKです。
+
+- :ref:`github.auth.basic` との違いはリクエストヘッダーの書式と、そこに指定されるクレデンシャルの意味の違いだけです。 
+
+OAuth2:トークン(access_token クエリパラメータ)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+- ご利用は慎重に。
+
+OAuth2:クライアントクレデンシャル
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+- ご利用はさらに慎重に。
    contain the root `toctree` directive.
 
 ===============================================
-django-social-authを使ってGistす
+django-social-authでOAuthに触れてみ
 ===============================================
 
-GithubもOAuth2
+はじめに
 ==============================================
 
+- デジタルアイデンティティの研究開発のお手伝いを数年やっています。
+- 主に、OAuth2( :rfc:`6749` )とその枠組みでデジタルアイデンティティにまつわる標準化、 :term:`OpenID Connect` の研究開発です。
+- OAuth2ドラフトからRFCになり、メジャーなサービスが対応してきています。
+- Djangoで構築するWebサービスにもOAuth2を対応することで提供するインターネット体験を高めるとかどうでしょうか。
+
+GithubもOAuth2
+----------------------
+
+- GithubのAPIを使うだけなら別の :ref:`リクエスト認証手段 <github.auth>` も用意されています。
+- が、自サービスのローカルアカウントに対して、ソーシャルアカウントを選択したり、
+  複数のソーシャルアカウントを紐づけたりすることが普通になっていくと思います。
+- 今後普及の進むと思われるOAuth2を使っておくのがいいのではないでしょうか。
+
+OAuth2とは?
+----------------------
+
+- アクセスするために許可の必要なリソースに対するリクエストを :term:`アクセストークン` で認証するルールを定めています。
+- アクセストークンをユーザーが許可した代理アクセス先( :term:`クライアント` )に対して、
+  認可サーバーで正しく安全に発行する手順(フロー)を定義しています。
+- クライアントがアクセスしたいリソースの組を :term:`スコープ` で指示することができます。
+
 django-social-authだと結構簡単
 ==============================================
 
+- :term:`django-social-auth` は結構簡単にOAuth2を自サービスに導入する事が可能です。
+ 
+    - OAuth2 は簡単なんです
+
+django-social-authの特色
+--------------------------
+
+- Djangoの :term:`認証バックエンド` の仕組みで、 :term:`認可応答` を処理し、ソーシャルアカウントでDjangoの認証が出来るようになっています
+        
+    - 新規登録もほぼ自動でできます
+    - 既にログインされているユーザーにソーシャルアカウントを紐づけられます
+    - ソーシャルアカウントで既存のユーザーとしてログインできます
+
+- つまり、各認可サーバー(Twitter,Facebook,Github,....) に対してプラグインできるようになっています
+
+    - 多くの :term:`バックエンドコントリビューション` があります
+
+- 認可バックエンドで必要とされる処理を :doc:`pipeline` を定義する事でカスタマイズできます  
+
+    - :doc:`partial.pipeline` を使う事で、アプリケーションで必要なUIを間に挟むこともできます
+
 django-social-authの導入
-==============================================
+--------------------------
+
+- インストールは簡単
 
-Gistを操作する
+    ::
+
+        $ pip install django-social-auth
+
+- サイトへの組み込みは以下の手順でおこないます
+
+    - :doc:`github.reg` でサイトを登録する
+    - :doc:`social_auth.conf` して、OAuthを使えるようにする
+    - 必要であれば :doc:`partial.pipeline` を実装して、ユーザーに認証前のUIを提供する
+    - 所得されたアクセストークンでサーバーからデータを所得して、認証ユーザーに対してサービスを提供する
+
+サンプル:Gistを操作する
 ==============================================
 
-OpenID Conect?
+- django-social-authだと Accesds Tokenの取得までが簡単にできます。
+- Access Tokenさえ取得してしまえば、あとはGithubのAPIに乗っ取って操作するだけです。
+- Githubは OAuth2のリソースアクセス手段であるベアラトークン( :rfc:`6750` ) によりリクエスト認証を行う事ができます。
+- つまり、HTTPの **Authorization** ヘッダーに以下のようにAccess Tokenを入れればいいです。
+
+    ::
+
+        Authorization: Bearer 23dbb1c3c4a23646cbcf640ed9224a95cce25fae 
+
+    - GithubではURLのクエリパラメータにアクセストークンを指定するなど、別の手順も用意されてはいます
+    - クエリパラメタにトークンを入れる方法は :rfc:`6749` 自体で考慮されている手順です
+
+- Gistの操作自体、このAuthorization ヘッダーとアクセストークンの扱い以外、OAuthは関係ありません。
+- しょぼいサンプルコードを https://bitbucket.org/hdknr/socialauth に置いています。
+
+    - このドキュメントを含んでいます
+
+OpenID Connect とは?
 ==============================================
 
+- ここからは、 :term:`OpenID Connect` の宣伝です。
+- OpenID Connectは OAuth2 の認可の仕組みを使って、プライバシーを考慮した上でクラウド上のサービス間でアイデンティティや属性の流通を標準的に行えるように考えられている仕組みです。
+
+アイデンティティ
+---------------------
+
+- django-social-authをつかって、Github, Facebook, Twitterなどいろいろアクセスしたり、
+  ソースコード読むとソーシャルユーザーの識別子の扱いがまちまちである事に気がつくでしょう。
+- OAuth2 ではユーザーのアイデンティティを標準的にやり取りすることをスペックでは定めていません。
+- OpenID Connectは(主に)OAuth2の一連のリクエストのやり取りの結果、  :term:`ID Token` という標準化されたデータで
+  ソーシャルユーザーのアイデンティティを安全に識別する仕組みを提供しています。
+
+ユーザー属性
+---------------------
+
+- 同じく OAuth2 ではユーザー属性の共有の方法が標準化されていません。
+- OpenID Connectでは :term:`UserInfo` という仕組みで3者間で共有された認証コンテキストに
+  対応するユーザーの属性を同じ手順で共有することができます。
+
+その他
+--------
+
+- アイデンティティ証書や属性を暗号化して渡したり、その情報に :term:`非否認性` をもたせたりするために :term:`JSON Web Token` というデータのシリアライズを標準的に行う仕組みがあります。これは :term:`JOSE` ワーキンググループでディスカッションされている JWK,JWS,JWEに基づいています。
+- 自サービスに訪れたユーザーが自分のソーシャルアイデンティティの認証元を指定し、そのソーシャルサイトとの間で動的に関係をとれる仕組みが用意されています( :term:`Discovery` + :term:`Dynamic Registration` 。 Dynamic Registrationに関しては OAuth2も別のRFC化に向けてディスカッション中です )。 
+- 共有されたアイデンティティ証書(:term:`ID Token`)を元に3者間でセッション管理出来る仕組みがあります( :term:`Session Management` )
+- リソースがさらに第4者にある場合の考慮もされています
+  ( UserInfo : :term:`Aggregated and Distributed Claims` 。OAuth2を基にした :term:`UMA` と言う手順も議論されています)   
+ 
 
-django-social-authについて
+資料:django-social-authについて
 ===============================================
 
 .. toctree::
     :maxdepth: 2
 
-    about
     github
     github.reg
     social_auth.conf

source/pipeline.rst

 
 .. contents::
     :local:
-    :depth: 3
+    :depth: 2
     :class: talks-contents
 
 パイプライン:Authorization Response後の一連の処理
 settings.LOGIN_REDIRECT_URL : Django標準裏ダリレクト
 --------------------------------------------------------
 
+django-social-auth カスタム
+--------------------------------------------------------
+
 setttings.SOCIAL_AUTH_LOGIN_REDIRECT_URL : django-social-auth専用リダイレクトが必要なら
-----------------------------------------------------------------------------------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
 
 settings.SOCIAL_AUTH_NEW_USER_REDIRECT_URL  : 新規ユーザーの場合特殊処理をしたいなら
-----------------------------------------------------------------------------------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 setttings.SOCIAL_AUTH_NEW_ASSOCIATION_REDIRECT_URL : 新しいアカウントリンクの場合の処理をしたい
-----------------------------------------------------------------------------------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 settings.SOCIAL_AUTH_DISCONNECT_REDIRECT_URL  : ソーシャルディスコネクトをしたら
-----------------------------------------------------------------------------------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 
 
 
 .. glossary::
 
+    django-social-auth
     django-social-auth Github
         http://django-social-auth.readthedocs.org/en/latest/backends/github.html
 
     OAuth HTTP MAC
         http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01
 
+    OAuth
+        - :rfc:`6749`
+
+    OAuth Bearer
+        - :rfc:`6750`
+        - 「運び屋」トークンです。
+        - お家の鍵と同じです。鍵が合えば、部屋に入る事ができます。たとえあなたの部屋であっても、彼女に鍵を渡す(複製する)
+          と部屋には入る事ができます。
+        - つまり、ベアラトークンでは鍵を使う人が「鍵を使うにふさわしい人である」保証を前提としています。
+        - このようなトークンとは別に、Holder-of-Key ( 「保持者専用鍵」) トークン と言うのも考えられて他のプロトコルでは定義されています。( SAMLなど )
+        - 「保持者専用鍵」トークンは、挿入した部屋の鍵が挿入しようとした人専用の鍵でなければ挿入してドアを開ける事はできません。
+        - 「保持者専用鍵」トークンが上手く行く環境を前提とすると閾が高すぎるのでベアラトークンを採用しています。
+
     requests
         http://docs.python-requests.org/en/latest/user/quickstart/  
 
+    クライアント
     Client
         Resource Ownerに代わってResourceをアクセスし、
         何らかのサービスを Resource Ownerに提供する
 
         例えば、Twitterに定期的に投稿したり、メンションを検知したりするBotアプリケーションとか。
 
+    認可リクエスト
+    認可要求
+    Authorization Request
+        認可要求 。 アプリケーションから OAuth のプロセスを開始するHTTP(S)要求です。
+
+    認可応答
+    認可レスポンス
     Authorization Response
         認可応答。 Authorization Serverで、Resource Owner がトークンの発行を許可した場合、
         その旨を :term:`Client` に通知するパラメータ。
 
         redirect_uri に戻されます。
+
+    クライアント登録
+    Client Registration
+        - 認可サーバーに対してアプリケーション登録を行い、クレデンシャルを受け取ります。
+        - http://tools.ietf.org/html/rfc6749.html#section-2
+
+    redirect_uri
+        - :term:`Authorization Request` に指定されるURLで、ここに認可サーバーから :term:`Authorization Response` が戻されます。
+        - 指定されない場合、  :term:`クライアント登録` で登録されたURLに戻されます。
+        - `不正に認可コードを取得させない <http://tools.ietf.org/html/rfc6749.html#section-10.6>`_ ように考慮されています。 
+
+    コードフロー
+        - 認可(Grant)を得る為に Authorization Code を用いる方法
+        - http://tools.ietf.org/html/rfc6749.html#section-4.1
+
+    OpenID Connect
+        - http://openid.net/connect/
+
+    クライアント認証
+        - 認可サーバーを :term:`クライアント登録` で発行したクレデンシャルで、 :term:`クライアント`  を認証します。
+        - http://tools.ietf.org/html/rfc6749.html#section-2.3
+        - `トークンエンドポイント` では認証が必要です ( http://tools.ietf.org/html/rfc6749.html#section-3.2.1 )
+
+    トークンエンドポイント
+    Token Endpoint
+        - トークンを発行するREST呼び出し先URLです
+        - トークンを発行するには :term:`クライアント認証` が必要です。
+        - http://tools.ietf.org/html/rfc6749.html#section-3.2
+
+    アクセストークン
+        - リソースをアクセスする為に必要なクレデンシャルです。
+
+    スコープ
+    Scope
+    Access Token Scope
+        - :term:`アクセストークン` が適用されるリソースの組を表します。 
+        - http://tools.ietf.org/html/rfc6749.html#section-3.3
+
+    ID Token
+        - アイデンティティを一意に示す属性データ(クレームといいます)セット 
+        - JSON形式で構成されて、 :term:`JSON Web Token` にシリアライズされて交換されます
+        - http://openid.net/specs/openid-connect-messages-1_0.html#id_token
+
+    JWT
+    JSON Web Token
+        - JSON形式に格納された属性データを暗号化したりデジタル署名を付与したりして安全に交換されるためのシリアライズする仕組み
+        - http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05
+
+    UserInfo
+        - :term:`ID Token` で示されたアイデンティティの属性データ
+        - http://openid.net/specs/openid-connect-messages-1_0.html#userinfo_ep 
+
+    JOSE
+        - Javascript Object Signing and Encryption (jose) Working Group 
+        - http://datatracker.ietf.org/wg/jose/
+
+    Discovery
+        - OpenIDプロバイダの場所や、様々な属性を取得する仕組み
+        - http://openid.net/specs/openid-connect-discovery-1_0.html
+
+    
+    Dynamic Registration
+        - :term:`クライアント` をOpenIDプロバイダに登録する手順
+        - http://openid.net/specs/openid-connect-registration-1_0.html
+        - OAuthのDynamic Registraton : http://tools.ietf.org/html/draft-oauth-dyn-reg-v1-03 
+
+    Session Management
+        - http://openid.net/specs/openid-connect-session-1_0.html
+
+    Aggregated and Distributed Claims 
+        - http://openid.net/specs/openid-connect-messages-1_0.html#anchor14
+
+    UMA
+        - http://tools.ietf.org/html/draft-hardjono-oauth-umacore-05
+
+    非否認性
+        - http://ja.wikipedia.org/wiki/%E5%90%A6%E8%AA%8D%E4%B8%8D%E5%8F%AF
+
+    認証バックエンド
+        - https://docs.djangoproject.com/en/dev/ref/authbackends/
+
+    バックエンドコントリビューション
+        - http://django-social-auth.readthedocs.org/en/latest/backends/index.html