プラグイン/認証/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メタデータをカスタマイズするには To customise your SAML IdP Metadata
あなたのサイトで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">[Provider name]</OrganizationName> <OrganizationDisplayName xml:lang="en">[Identity provider name]</OrganizationDisplayName> </Organization>
- Change [Provider name] to the name of the organization the IdP belongs to, eg Mahara.org
- Change [Identity Provider name] to the name of the IdP system, eg Mahara Single Sign On
Note Depending on the way your IdP structures it's metadata you may need to prefix the new Extensions and Organization* lines with same prefix as in the </IDPSSODescriptor> line, eg if that line looks like </md:IDPSSODescriptor> then you will need to add 'md:' to the lines that don't start it
Dealing with backups to a staging server
If you have a testing/staging server that is using it's own setup of SAML for testing purposes then you will want to avoid killing it when making a backup of the site from the production instance. For example, you have this scenario:
Production Mahara site with SAML ===========> Identity provider production endpoint
connects to
Staging / Testing Mahara site ===========> Identity provider testing endpoint
or Identity provider production endpoint
Then when you make your backup you want to avoid the SAML not working on the staging / testing site. To do this you will need to do the following:
Before making backup
1) Begin with the staging / testing site working correctly - make sure you can login correctly to the Identity Provider endpoint as expected. Then make a backup of the certificate .crt and .pem files found in your dataroot directory so they won't be overwritten or deleted via an rsync, eg:
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) If your staging / testing site connects to a different Identity Provider than the production site then you should also backup the metadata dataroot directory /path/to/dataroot/metadata/ to put backk after the backup
1b) And we need to find and save the database value for the SP Identity. It can be found via:
SELECT value FROM auth_config WHERE field ='spentityid';
After making backup
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:
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.