認証と認可の概念 • 認証 (Authentication) • 認可 (Authorization)
認証とは • 認証因子 (authentication factors) からシス テムの利用者を識別して、システムにと って利用者が何者であるかを決定するこ と • 利用者が何者であるかが分かった所で、 システムの機能を使えるかどうかは別問 題 • (→認可) 認証因子 決定 決定 0182 0021
認可とは • システムの利用者の認証情報から、シス テムの一部または全部の機能を利用可能 かどうか決定すること 0001 0123 システム管理 者 一般ユーザー ✔️ ✔️ ✔️
Webアプリケーションの認証 • WebアプリケーションはHTTPを使ってシ ステムの利用者の環境 (ブラウザ) と通信 する • HTTPのペイロードにシステムの利用者を 識別するような情報を乗せて通信するこ とで、Webアプリケーションにユーザーを 認証させる
Webアプリケーションの認証 • 認証に用いられる情報 – URL – クエリ文字列 – リクエストボディ – Authorizationヘッダ – クッキー – IPアドレス – SSLクライアント証明書 など
Webアプリケーションの認証 ✔️https://example.com/s ecretpage 403 GET /secretpage HTTP/1.1 HTTP/1.1 403 Forbidden HTTP/1.1 200 OK 200 自宅のIPアドレス GET /secretpage HTTP/1.1 職場のIPアドレス
Webアプリケーションの認証 • チャレンジ-レスポンス認証 – 閲覧できないリソースへのアクセスを行おう としたときに、エラーを返すのと同時に利用 者に認証因子の送信を求める (チャレンジ) – 利用者はレスポンスとして認証因子 (ユーザ 名、パスワード等) をサーバーに送信する – 非セッション型の通信では、サーバは以後の アクセスで利用者識別情報として利用可能な トークンをユーザに返す
Webアプリケーションの認証 ✔️https://example.com/s ecretpage 401 GET /secretpage HTTP/1.1 GET /secretpage HTTP/1.1 Authorization: basic … HTTP/1.1 401 Authorization Required WWW-Authenticate: Basic; realm=… HTTP/1.1 200 OK 200 ✔️ GET /anotherpage HTTP/1.1 Authorization: basic … https://example.com/a notherpage 認証情報の入力 認証情報はブラウザーに 記憶される 200 HTTP/1.1 200 OK
Webアプリケーションの認証 Login page https://example.com/s ecretpage 302 HTTP/1.1 302 Moved Temporarily Location: /login ✔️https://example.com/a notherpage 識別のための情報が クッキーとして ブラウザーに記憶される 200 GET /secretpage HTTP/1.1 https://example.com/ login GET /login HTTP/1.1 認証情報の入力 Login page HTTP/1.1 200 OK HTTP/1.1 302 Moved Temporarily Location: /secretpage Set-Cookie: xxx=yyy; path=/POST /login HTTP/1.1 user=aaa&passwd=bbb GET /anotherpage HTTP/1.1 Cookie: xxx=yyy HTTP/1.1 200 OK
OAuth • OAuthはWebアプリケーションやWebAPI の、サービス間の認可のためのフレーム ワーク • サービスAがサービスBに認可をするため にサービスAが利用者に認証を求めるよう な作りになっていることを利用して、認 証の外部化機構としても利用できる
ここ (2-3の間) で provider側の認証が利 用者に対して行われた りする。 OAuthのフロー 1. ブラウザをproviderの認可エンドポイントにリダイレクト 2. 認可エンドポイントにブラウザがGETリクエスト 3. ブラウザをconsumerのコールバックURLにリダイレクト 4. コールバックURLにブラウザがGETリクエスト code code code 5. Consumerがproviderのアクセストークン取得APIにPOSTリクエスト client_id redirect_uri client_id client_secret 6. Providerがconsumerにアクセストークンや補助的な情報を返 却 access_token 7. Consumerは与えられたアクセストークンを伴ってProviderの各種APIにアクセス Consumer (認可を受ける側) Provider (認可を与える側) User agent (ブラウザ)
OpenID Connect • OpenID 2.0の後継として生まれた規格 • OAuth 2.0ベース • アクセストークンと一緒にOpenID認証情 報をJWT (JSON Web Token) として consumerに渡す
ここ (2-3の間) で provider側の認証が利 用者に対して行われた りする。 OpenID Connectのフロー 1. ブラウザをproviderの認可エンドポイントにリダイレクト 2. 認可エンドポイントにブラウザがGETリクエスト 3. ブラウザをconsumerのコールバックURLにリダイレクト 4. コールバックURLにブラウザがGETリクエスト code code code 5. Consumerがproviderのアクセストークン取得APIにPOSTリクエスト client_id redirect_uri client_id client_secret 6. ProviderがconsumerにアクセストークンやIDトークンを返却 access_token 7. Consumerは与えられたアクセストークンを伴ってProviderの各種APIにアクセス Consumer (認可を受ける側) Provider (認可を与える側) User agent (ブラウザ) id_token nonce max_age
Pyramidの認証と認可 Authentication and Authorization in Pyramid
Pyramidの認証と認可 • 認証ポリシー (IAuthenticationPolicy) • 認可ポリシー (IAuthorizationPolicy) • セキュリティプリンシパル (principals) • ACL (access control list)
Pyramidの認可 • view_configに指定されたpermissionを引数 に、登録された IAuthorizationPolicy の permits() メソッドが呼ばれる • permits()メソッドがFalseを返した場合、 HTTPForbiddenがraiseされる • チャレンジがある場合は、例外ビューの1 つであるforbidden viewでこれを拾って、 ログイン用のページにリダイレクトする
Pyramidの認証 • IAuthenticationPolicyの effective_principals()が現在認証されてい るユーザに対応するprincipalsを返す。
ACLAuthorizationPolicy • Contextオブジェクトの持つ__acl__プロパ ティの内容の各要素 (ACE=Access Control Entry) と、 IAuthenticationPolicy.effective_principals() の返したprincipalsを順に照合して、最初 に合致したものをpermissionとする __acl__ = [ (Allow, Authenticated, 'authenticated'), (Deny, 'group:XXX:YYY', 'excluded'), (Allow, 'membership:XXX', 'member_only'), ]

Authentication, Authorization, OAuth, OpenID Connect and Pyramid

Editor's Notes