アクセス制限

Apacheの設定による基本的なアクセス制限

ShibbolethのモジュールはApacheの認証と承認の処理を拡張する形で実装されており、WebコンテンツやアプリケーションをShibbolethを使ってアクセス制限するには、設定ファイル内の<Directory>、<File> や <Location> といったセクション内や、.htaccess（AllowOverride AuthConfigが必要）ファイルにShibboleth認証の設定を記述します。

全ユーザにアクセスを許可する

統一認証システムにアカウントを持つ全てのユーザにアクセスを許可するには、設定ファイルの <Directory>、<File> や <Location> などのセクション内、もしくは、AllowOverride AuthConfig設定で、アクセス制限の上書きが許可されているディレクトリの.htaccessに以下の3行の記述を追加します。

AuthType shibboleth
ShibRequestSetting requireSession 1
Require shib-session

この3行の記述は、それぞれ

という意味になります。すなわち、この設定をした場所では、統一認証システムにアカウントを持つ全ての利用者に対してリソースへのアクセスを許可することになります。

教職員または学生のみにアクセスを許可する

教職員または学生のみにアクセスを許可したい場合、(unscoped-)affiliation属性の値によるアクセス制限を行います。

AuthType shibboleth
ShibRequestSetting requireSession 1
Require shib-attr unscoped-affiliation staff

これで、Shibbolethの属性(‘shib-attr’)の中で、’unscoped-affiliation’が教職員(‘staff’)のユーザにのみアクセスを許可する、という設定になり、’staff’を’student’に変えることで、学生にのみアクセスを許可する設定になります。

所属部署でアクセス制御する

所属部署(‘jaou’)属性によるアクセス制限を設定すれば、特定部署に所属しているユーザのみにアクセスを許可することもできます。

設定ファイルに日本語を記述する場合、漢字コードをOSやApacheが認識するものと合わせる必要があります。

AuthType shibboleth
ShibRequestSetting requireSession 1
Require shib-attr jaou 〇〇系

これで、所属部署が「〇〇系」のユーザのみアクセスできるようになります。

所属部署でのアクセス制限を行うためには、SPの登録申請時に所属部署属性の追加提供申請が必要です。

複数の所属部署のユーザにアクセスを許可したい場合、’Require’行を並べて記述します。

AuthType shibboleth
ShibRequestSetting requireSession 1
Require shib-attr jaou 〇〇系
Require shib-attr jaou □□学群△△学類

これで、所属部署が「〇〇系」または「□□学群△△学類」のユーザのみアクセスできるようになります。

属性名と値の間に’~’記号を記述すると、正規表現を使った指定もできます。

AuthType shibboleth
ShibRequestSetting requireSession 1
Require shib-attr jaou ~ .*支援室.*

と記述すると、所属部署に「支援室」という文字列を含む全てのユーザのみアクセスできるようになります。

アカウント名（UTID-NAME)でアクセス制御する

特定のユーザのみにアクセスを許可したい場合、アカウント名(‘eppn’)属性を使います。

アカウント名でのアクセス制限を行うためには、SPの登録申請時にeppn属性の追加提供申請が必要です。

AuthType shibboleth
ShibRequestSetting requireSession 1
Require shib-attr eppn tsukuba.taro.ut@tsukuba.ac.jp

’@’記号の後ろはメールアドレスのドメインではなく’tsukuba.ac.jp’になりますので注意してください。

アクセス制限を解除する

Shibbolethでのアクセス制限を設定したパス下の一部でアクセス制限を解除したい場合、以下のような設定を記述します。

AuthType Shibboleth
ShibRequestSetting requireSession false
Require shibboleth

Webアプリでログイン状況により表示内容を動的に制御したい場合などでも、この設定を利用します。

WordPressのShibbolethによるアクセス制限

いくつかのWebアプリはプラグインやモジュール等でShibboleth認証に対応しています。ここでは、WordPressでのShibbolethの導入手順について説明します。

SPの動作確認やWordPressのインストールは済んだ状態であるものとします。

追加属性の申請について

WordPressでShibboleth認証を利用する場合、登録申請時に’eppn’属性の追加申請を検討してください。

WordPressのShibbolethプラグインでは、IdPから受け取った属性の一つを指定してWordPressのローカルアカウント名として登録します。その際、WordPressの仕様として、アカウント名に長さ(60文字まで)や利用可能な文字に制限があり、さらに後述するような事前登録方式でアカウントを管理したい場合、標準で提供されるpersistent-idは利用できないためです。

また、表示名(‘jaDisplayName’)やメールアドレス(‘mail’)も統一認証システムに登録されている値を利用する場合、それらの属性についても追加申請してください。

Shibbolethプラグインの導入

WordPress用のShibboleth pluginはhttps://wordpress.org/plugins/shibboleth/から入手できますので、[Download]ボタンを押してダウンロードし、展開した’shibboleth’ディレクトリを/wp-content/pluginsの下にコピーします。コピーしたファイルの場所やパーミッションが適切なら、ダッシュボードのプラグインメニューにShibbolethが表示されるので有効化します。

Shibbolethプラグインが有効化されると、WordPressを設置したディレクトリの .htaccess ファイルに以下のような記述が追加されるので、確認してください。

# BEGIN Shibboleth
AuthType shibboleth
Require shibboleth
# END Shibboleth

この設定により、Shibboleth認証は有効としつつアクセス制限が解除されている状態となります。 もし .htaccess ファイルに該当する記述が見当たらない場合は手動で追記してください。

プラグインの設定

Shibbolethプラグインが有効化されると、設定メニューに’Shibboleth’が表示されるようになるので、こちらをクリックして設定画面へと進みます。

まず General Configuration 画面で、基本的な設定を行います。

次に User Configuration 画面でアカウント関連の設定を行います。

‘ユーザー名’, ‘First name’, ‘Last name’, ‘ニックネーム’ ‘Display name‘および’Email Address‘の入力欄では、WordPress内での各々の項目とShibbolethの属性情報の紐付けを行います。各項目の右にある[Managed]にチェックを入れると、プロフィール画面でのユーザによる変更ができなくなり、Shibbolethの属性値で固定されます。

‘Automatically Create Accounts‘にチェックを入れると、WordPressにアカウントのないユーザがログインしてきた時に自動的にアカウントが作成されます。

‘Combine Local and Shibboleth Accounts‘では、既存のローカルアカウントとShibbolethのアカウントの紐付けの動作を指定します。デフォルトの状態では同名のローカルアカウントとShibbolethアカウントの紐付けは行われず、すでにローカルアカウントが存在する場合、エラーとなります。

2019/07/10時点のWordPress 5.2.2とShibbolethプラグイン2.1.1の組み合わせでは、この機能の動作は記述されている説明とは違っているように見受けられます。この設定を行う場合、期待通りの動作になるか、事前に十分に確認してください。

Authorization 画面では、’Automatically Create Accounts‘設定が有効になっている時に作成されたアカウントに付与する役割(Role)を指定します。

‘Role Mappings‘の各行にある’Header Name‘に属性名、’Header Value‘にその値を入力すると、条件に合致するアカウントはその役割(Role)が付与されます。いずれの条件にも当てはまらないアカウントは’Default Role‘で指定した役割が付与されます。

運用例

これまでの説明とサンプル画面の内容に従って設定を行った場合、Shibbolethでの認証には進めますが、認証に成功してもログインできない状態となります。

これを回避して運用するためのいくつかの典型的な設定例について説明します。

ここで説明する方法はあくまでサンプルで、本ドキュメント作成時点での情報ですので、意図した通りの動作になるかどうかは必ず確認してから運用を開始してください。

WordPressのアカウントを自動発行する

Shibbolethで認証に成功したユーザには自動的にWordPressのアカウントを発行します。

• User Configurationで’Automatically Create Accounts‘にチェックを入れます
• Authorizationで’Role Mapping‘および’Default Role‘の役割を適宜設定します

事前登録したアカウントのみログインを許可する

ダッシュボードのユーザー管理メニューから作成したアカウントのみログインできるようにします。

• User Configurationで’Automatically Create Accounts‘のチェックを外します
• 同画面の’Combine Local and Shibboleth Accounts‘で’Allow Automatic Account Merging‘を選択します
• ユーザー管理メニューから、Shibbolethのアカウント(例: ‘tsukuba.taro.ut@tsukuba.ac.jp’)を登録します（その際アカウントに関するメールは送らない）。

サイトの閲覧も制限する

WordPressで構築したサイト全体の閲覧にもShibboleth認証を必要とする設定は .htaccess ファイルで行います。

Shibboleth プラグインにより自動生成された’# BEGIN Shibboleth’から’# END Shibboleth’までの行を全て削除し、代わりに以下の設定を追加します。

AuthType shibboleth
ShibRequestSetting requireSession 1
Require shib-session

この設定では統一認証アカウントを持っている全てのユーザが閲覧できるようになりますが、Apacheの設定で説明したアクセス制限が設定可能ですので、閲覧を許すアカウントを制限したい場合は、適宜設定を記述します。

これで、

• WordPressサイトの閲覧時にShibboleth認証ページにリダイレクトされる
• ログインはできない（WordPressのローカルアカウントであらためてログインする）

状態となりますので、Shibbolethアカウントでログインしたい場合は上に書いた2つのいずれかの設定と併用します。

合わせて、 General Configurationで’Automatic Login‘にチェックを入れておくと、ページにアクセスした瞬間にShibboleth認証へとリダイレクトされ、認証に成功するとWordPressにもログインした状態になります。

その他アプリのShibbolethに関する情報

その他、いくつかのWebアプリではShibbolethに対応しており、以下のページにまとめられています。

個々のソフトウェア／サービスのシボレス対応状況(GakuNinShare)