1. アクセス制御概要¶
1.1. アクセス制御機能¶
アクセス制御は、 認証 （authentication） 、 認可 （authorization） 、 監査 （audit） の機能に大きく分けることができます。これらの機能と共に、web2pyフレームワークの機能を整理したものが次の図になります。
簡単に説明しますと、認証はユーザを識別するための機能、認可はシステムの利用範囲を特定するための機能、そして監査はアクセス制御が正常に動いているかを検証するための機能になります。
認証及び認可では、必要な機能はほぼ一通り揃っています。しかし監査に関しては、ログ記録とアーカイブしか機能はありません。
1.2. 認証方式¶
web2pyの特徴として、多様な認証方式に対応していることが挙げられます。対応する認証方式と認証方式の簡単な説明を書いていきます。
対応している認証方式
- Form
- Basic
- CAS
- LDAP
- SMTP
- OpenID
- OAuth1.0
- OAuth2.0
- PAM
- X509
対応しているサービスプロバイダによる認証
- Googleアカウント
- Janrain Engage
- Dropboxアカウント
- Linkedinアカウント
アクセス制御モジュールに標準で組み込まれている認証方式は Form認証 です。Form認証以外の認証方式は、追加的に組み込まれているに過ぎません。つまりアクセス制御の各機能は、Form認証の使用を想定して開発されています。このため Form認証以外では使用できない機能も存在します。
組織内の情報システム連携を考える場合、 CAS認証 や LDAP認証 は有用です。LDAP認証では、マイクロソフト社の Active Directory を利用することも可能です。
SMTP認証 とはe-mailのSMTPサーバを利用した認証です。SMTPサーバがアカウント毎に認証している場合、少ない手間で認証サービスに利用することが可能です。
Googleアカウント認証 は、Google AppEngine（GAE）上で利用できるサービスです。GAE以外の環境でGoogleアカウント認証を利用したい場合は、 OpenID もしくは OAuth 、 Janrain Engage の各認証サービスを利用するのがよいでしょう。
Janrain Engage （旧RPX）によって提供されているのは、複数の認証サービスプロバイダに Janrain Engage 経由で接続するという特色のあるサービスです。これによって開発工数を抑えたまま、数多くのプロバイダの認証サービスを利用することが可能になります。ただ接続できるサービスプロバイダはアメリカ中心のため、ローカルのプロバイダには対応していないことが多いです。
この他に web2py 認証モジュールの特徴として、複数の認証方式を同時に利用することが可能です。組み合わせには制約もありますので、全ての方式を同時に利用することはできません。検証した認証モジュールの組み合わせを次の表で示します。
1.3. 認可モデル¶
web2py はロールベースアクセス制御（ RBAC , Role-based access control）の認可モデルを持っています。RBACはロール（役割）にリソースのアクセス権を割り当て、認可を行います。
RBACを使った認可モデルのイメージ
RBACを実現するため、web2pyは実装用のメソッドを持っています。認可管理用にグループやメンバー、そしてパーミッションの追加・削除のメソッド。認可制御実装用にアクセス可否を判定するメソッドやデコレータがあります。
また、RBACは、任意アクセス制御( DAC , Discretionary Access Control)及び強制アクセス制御( MAC , Mandatory Access Control) をシュミレートすることが可能です。このため認可は、多様な方法で実装可能です。
1.4. データ構造¶
アクセス制御で利用するデータ構造を簡単に説明します。テーブル関連図は次の図になります。
アクセス制御のテーブル関連図
各テーブルの役割は次の表になります。
テーブル 説明 auth_user ユーザ認証用の情報を管理します auth_membership ユーザとグループの関連情報を管理します auth_group グループの情報を管理します auth_permission リソース割り当てに関する情報を管理します auth_event 認証関係のログを管理します alt_logins （OpenID使用時のみ）OpenIDを管理します。
各テーブル名はデフォルト値で表していますが、このテーブル名は変更可能です。また必要に応じて、各テーブルでのフィールド追加も可能です。
認証機能ではユーザ管理上、ID管理を メールアドレス にするか ユーザ名 にするか選択可能です。デフォルトは メールアドレスです。もしユーザ名によるID管理に設定した場合、auth_user テーブルには username フィールドが追加されます。この機能は、FomやBasic認証以外の認証方式を利用している場合も、同じように影響します。なぜなら、認証でLDAPユーザやOpenIDを使用したとしても、フレームワーク内部でのユーザ管理用IDはあくまでも、 メールアドレス もしくは ユーザ名 となっているからです。