プラグイン/認証/Saml
From Mahara Wiki
SAML 2.0ベースのSSO統合用認証プラグインです。このプラグインはサービスプロバイダとして優れたソフトウェアSimpleSAMLPHPを使用します。
このプラグインはMaharaコアの一部として配布されます。
あなたがこのプラグインを使用またはテストするには以下が必要です:
memcachedサーバが稼働していること
そして、あなたが接続に使用できるIPアドレスおよびポート番号を知っていること。
ローカル (Linux) にインストールするには以下のコマンドを実行してください:
sudo apt-get install memcached
これでポート11211で動作するよう設定されるはずです。確認するには以下のコマンドを実行してください:
telnet 127.0.0.1 11211
そして、あなたは接続されているはずです。
php-memcachedモジュールがインストールされていること
php-memcachedをインストールするには以下のコマンドを実行してください:
sudo apt-get install php-memcached sudo phpenmod memcached sudo service apache2 restart
あなたのconfig.phpファイルを更新してSAMLセッションにmemcachedを使用するよう知らせる
config.phpファイルに以下の設定を追加してください:
$cfg->ssphpsessionhandler = 'memcached'; $cfg->memcacheservers = '127.0.0.1:11211'; // あなたのmemcachedが異なるIP/ポートを使用している場合、変更してください。
正しいSSPHPファイルの存在を確認する
あなたがMaharaをgit経由でインストールおよび使用している場合、htdocsディレクトリ (Makefileファイルが存在する場所) の親ディレクトリで以下のコマンドを実行してssphpモジュールをインストールする必要があります。
make cleanssphp && make ssphp
このコマンドにより古いすべてのバージョンが削除されます。そしてあなたが使用しているMaharaのバージョンに合わせてコンポーザ経由で最新バージョンがインストールされます。
Maharaでプラグインが有効であることを確認する
「管理メニュー (レンチのアイコン) -> 拡張機能 -> プラグイン管理」で確認できます。 詳細はマニュアル- SAML設定をご覧ください。
プラグインが正しく設定されていることを確認するにはSAML認証設定アイコン (歯車) をクリックしてください。
あなたが認証したいアイデンティティプロバイダ (IdP) に提供するためのサービスプロバイダ（SP）メタデータを取得するには「メタデータを表示する」リンクをクリックしてください。
次に私たちはインスティテューションレベルの設定が必要です
それぞれのインスティテューション内でSAML 2.0アイデンティティプロバイダを追加してください:
詳細はマニュアル - SAMLインスティテューション設定をご覧ください。
あなたのSAML IdPメタデータをカスタマイズするには
あなたのサイトで2つ以上のアイデンティティプロバイダ (IdP) が使用されている場合、ユーザがSSOボタンでサイトログインを試みた時点で「アイデンティティプロバイダディスカバリ」ページが表示された上でどのIdPでログインするか選択することになります。
IdPから提供されたメタデータに以下の値を含む場合
- OrganizationName
- OrganizationDisplayName
- Logo
これらはディスカバリページで使用されます。
あなたのIdPのメタデータがこれらの値を提供しない場合 - アイデンティティプロバイダ側でデータを更新した上で更新されたmetadata.xmlファイルを提供できるかどうか尋ねてください。特にあなたがメタデータ更新URLを使用している場合、これは最良の選択肢となるでしょう。
アイデンティティプロバイダ側がmetadata.xmlファイルを提供できない場合、あなたは変更内容を手動で追加できます。追加手順は以下のとおりです:
1) サイト管理者としてログインしてSAMLメタデータを使用するインスティテューションを編集してください。
2) SAML認証インスタンスを編集してください。
3) 「インスティテューションアイデンティティプロバイダSAMLメタデータ」フィールドで以下のように変更してください。
a) あなたがロゴイメージを使用したい場合 metadata.xmlファイル内で
</IDPSSODescriptor>行の直前に以下の内容を記述してください:
<Extensions>
<mdui:UIInfo xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui">
<mdui:Logo width="120" height="30" xml:lang="en">[URL to logo]</mdui:Logo>
</mdui:UIInfo>
</Extensions>
[ロゴのURL]を更新してインターネット経由で到達可能なIdPのロゴを指すようにしてください。例) https://mahara.org/theme/mahara-org/images/site-logo.svg 必要に応じて高さおよび幅の値を変更してください。最適なイメージは次のとおりです: 120 x 30px png / svg
b) プロバイダの詳細設定は以下のとおりです:
</IDPSSODescriptor> 行のすぐ下に以下の内容を記述してください。
<Organization> <OrganizationName xml:lang="en">[プロバイダ名]</OrganizationName> <OrganizationDisplayName xml:lang="en">[アイデンティティプロバイダ名]</OrganizationDisplayName> </Organization>
- [プロバイダ名]をIdPが属する組織名に変更してください。例) Mahara.org
- [アイデンティティプロバイダ名]をIdPシステム名に変更してください。例) Maharaシングルサインオン
メモ あなたのIdPメタデータ構造によっては新しい「Extensions」および「Organization*」行に「</IDPSSODescriptor>」行と同じ接頭辞を付加する必要があります。例) 例えばその行が</md:IDPSSODescriptor>のような場合、「md:」で開始していない行に「md:」を付加してください。
ステージングサーバへのバックアップの扱いについて
あなたがテスト/ステージングサーバでテスト用に独自のSAML設定を使用している場合、本番インスタンスからサイトバックアップ作成時にそのサーバを削除しないようにする必要があります。例えば次のシナリオの場合:
SAML使用の実運用Maharaサイト ===========> アイデンティティプロバイダ「実運用」エンドポイント
接続
ステージング/テストMaharaサイト ===========> アイデンティティプロバイダ「テスト」エンドポイント
または アイデンティティプロバイダ「実運用」エンドポイント
次にバックアップを作成する場合、あなたはステージング/テストサイトでSAMLが動作しないことを回避したいと思います。このためには以下を実施する必要があります:
バックアップ作成前 Before making backup
1) ステージング/テストサイトが正しく動作している状態で開始します - あなたが期待どおりにIDプロバイダのエンドポイントに正しくログインできることを確認してください。次にdatarootディレクトリにある証明書.crtおよび.pemファイルのバックアップを作成してrsync等で上書きまたは削除されないようにします。 例)
cp /path/to/dataroot/certificate/server.crt /path/to/dataroot/certificate/server.crt.staging cp /path/to/dataroot/certificate/server.pem /path/to/dataroot/certificate/server.pem.staging
1a) あなたのステージング/テストサイトが本番サイトとは異なるアイデンティティプロバイダに接続する場合、バックアップ後に元に戻すため、メタデータのデータルートディレクトリ「/path/to/dataroot/metadata/」もバックアップする必要があります。
1b) そして、私たちはサービスプロバイダIDのデータベース値を検索して保存する必要があります。データベース値は以下のコマンドで探せます:
SELECT value FROM auth_config WHERE field ='spentityid';
バックアップ作成後
2) When production site gets backed up to staging the best option is to get rsync to ignore the /path/to/dataroot/certificate/ and /path/to/dataroot/metadata/ directories. But if you can't do that then we need to copy the backed up files back into place, eg: 2) 実稼働サイトをステージングにバックアップする場合、最良の方法はrsyncに/path/to/dataroot/certificate/および/path/to/dataroot/metadata/ディレクトリを無視させることです。しかし、それができない場合、バックアップされたファイルを元の場所にコピーする必要があります。
例:
cp /path/to/dataroot/certificate/server.crt.staging /path/to/dataroot/certificate/server.crt cp /path/to/dataroot/certificate/server.pem.staging /path/to/dataroot/certificate/server.pem
2a) Put back the backed up staging / testing metadata if needed
2b) And then we need to update the database so we have the right SP identity again. The my_SP_value will be what you got from (1b), eg:
UPDATE auth_config SET value = 'my_SP_value' WHERE field ='spentityid';
That should get the SAML working again.
If you hadn't made backups of those files / db information then you will need to generate the SAML certificate in the staging / testing site again via the Admin -> Extensions -> SAML configuration (admin/extensions/pluginconfig.php?plugintype=auth&pluginname=saml) and give the information at 'View metadata' to your Identity Provider again.