authentication, authorization, oauth, openid connect and pyramid
TRANSCRIPT
認証と認可の概念• 認証 (Authentication)• 認可 (Authorization)
認証とは• 認証因子 (authentication factors) からシステムの利用者を識別して、システムにとって利用者が何者であるかを決定すること• 利用者が何者であるかが分かった所で、システムの機能を使えるかどうかは別問題• (→認可 )
認証因子
決定
決定0182
0021
認可とは• システムの利用者の認証情報から、システムの一部または全部の機能を利用可能かどうか決定すること
0001
0123
システム管理者
一般ユーザー
✔ ✔
✔
Webアプリケーションの認証• Webアプリケーションは HTTPを使って
システムの利用者の環境 (ブラウザ ) と通信する• HTTPのペイロードにシステムの利用者を識別するような情報を乗せて通信することで、Webアプリケーションにユーザーを認証させる
Webアプリケーションの認証• 認証に用いられる情報– URL–クエリ文字列–リクエストボディ– Authorizationヘッダ–クッキー– IPアドレス– SSLクライアント証明書など
Webアプリケーションの認証✔ https://
example.com/secretpage 40
3
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/secretpage 40
1
GET /secretpage HTTP/1.1 GET /secretpage HTTP/1.1Authorization: basic …
HTTP/1.1 401 Authorization RequiredWWW-Authenticate: Basic; realm=…
HTTP/1.1 200 OK200
✔
GET /anotherpage HTTP/1.1Authorization: basic …
https://example.com/anotherpage
認証情報の入力 認証情報はブラウザーに記憶される
200 HTTP/1.1 200 OK
Webアプリケーションの認証Loginpage
https://example.com/secretpage 30
2 HTTP/1.1 302 Moved TemporarilyLocation: /login
✔ https://example.com/anotherpage
識別のための情報がクッキーとしてブラウザーに記憶される
200
GET /secretpage HTTP/1.1
https://example.com/login
GET /login HTTP/1.1
認証情報の入力
Loginpage
HTTP/1.1 200 OK
HTTP/1.1 302 Moved TemporarilyLocation: /secretpageSet-Cookie: xxx=yyy; path=/POST /login HTTP/1.1
user=aaa&passwd=bbb
GET /anotherpage HTTP/1.1Cookie: 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'), ]