Category: PHP

Active DirectoryのLDAPを使ってSAML認証

SAML認証についての解説記事のうち、以下の3つはSimpleSAMLphp v2についての記事で、まだまだ、書いたことはそのまま使える（というか、そうなるように時々アップデートしている）。(1)(2)がIdP、(3)がSPの構築だ。

これらの情報をベースにして、タイトルの通り、Active DirectoryをLDAPサーバとして利用して、SAML認証が行うことに成功したので、やり方を書いておく。以下の手順時は、上記の流れでIdPとSPが稼働できるようにした上での追加の作業について記載する。

まず、SimpleSAMLphpでLDAPの機能を動かすためには、PHPのLDAP機能拡張の追加と、SimpleSAMLphpのLDAPモジュールの追加が必要である。Ubuntu Server 24.0.2 LTSでは、例えば、IdPをセットアップしたディレクトリ（/var/www/simplesaml-idp）で、以下のようにコマンドを入力する。

sudo apt install -y php-ldap
cd /var/www/simplesaml-idp 
composer require simplesamlphp/simplesamlphp-module-ldap

続いて、設定ファイルを変更する。前述の記事の通りにIdPのセットアップがなされているとして、IdP側のconfig.phpに以下の設定を追加する。もちろん、最後のldapのエントリーを追加する。

'module.enable' => [
  'exampleauth' => true,
  'core' => true,
  'admin' => true,
  'saml' => true,
  'ldap' => true,
],

そして、さらに、IdPのauthsource.phpファイルを修正する。ここでは以下のように、LDAPに関する設定を有効にする。すでに、コメントされた箇所があるので、そのコメントをはずして、実際に使用する値にすればよい。以下は、実質的な設定の行だけを残したものであるが、実際には、ファイルに記載されている説明のためのコメントを読みながら設定をすることになるだろう。LDAPについての知識があれば、そんなに大変ではないと思われるが、AD自体の状況も加味しないといけない。設定変更した箇所は、赤字で示したが、「最低限」となるとこれくらいだろう。なお、ドメインは架空であり、実際とはちょっと違う。

    'example-ldap' => [
        'ldap:Ldap',
        'connection_string' => 'ldap://ad.msyk.net/',
        'encryption' => 'none',
        'version' => 3,
        'ldap.debug' => false,
        'options' => [
            'referrals' => 0x00,
            'network_timeout' => 3,
        ],
        'connector' => '\SimpleSAML\Module\ldap\Connector\Ldap',
        'attributes' => null,
        'attributes.binary' => [
            'jpegPhoto',
            'objectGUID',
            'objectSid',
            'mS-DS-ConsistencyGuid'
        ],
        'dnpattern' => 'CN=%username%,CN=Users,DC=msyk,DC=net',
        'search.enable' => false,
        'search.base' => [
            'CN=Users,DC=msyk,dc=net',
        ],
        'search.scope' => 'sub',
        'search.attributes' => ['uid', 'mail'],
        'search.filter' => '(&(objectClass=Person))',
        'search.username' => null,
        'search.password' => null,
    ],

設定の最後の3分の1程は、serch.とプレフィックスがあるようにユーザ検索を行うときの設定のようである。username等をnullにしているので、「検索はしない」という設定にしておいた。認証だけなら、この設定は不要である。なので、search.baseも設定する必要はないとは思われる。

ということで、実際に使用したのは、connection_string、つまり、LDAPサーバへのURLと、dnpatternつまりユーザレコードのDistingished Name(DN)のパターンだけである。AD側は、シンプルに（シンプル過ぎるがww）Users以下にだけユーザを作ってあるので、CN=UsersがDNパスに入るだけである。ユーザ名はCNで得られる。

さらにIdPのmetadataディレクトリに入れるsaml20-idp-hosted.phpファイルも修正をする。URLやキーファイル名はすでに入っているとして、以下のように、authキーの値をauthsource.phpで指定したLDAP設定のキー値に置き換える。もちろん、「example」は実際の運用ではちゃんとした名前に置き換えよう。ちなみに、最初、LDAPの設定をしたのに、example-userpassのテストユーザでないと認証ができないというところでグルグルしてしまったのだが、ちゃんと認証ソースの設定があるということであった。

$metadata['https://idp.topse.jp/'] = [
    'host' => '__DEFAULT__',
    'privatekey' => 'idp.pem',
    'certificate' => 'idp.crt',
    'auth' => 'example-ldap',
:

これでIdP側の管理ページにログインして、表示内容を確認しよう。まず、「設定」のタブのところでは、Modulesにldapが追加されてチェックが入っている。

Testのところを見ると、authsource.phpに設定した、example-ldapが見えている。これをクリックして、このソースでの認証を確かめてみる。

いつも通りのIdPの認証パネルが見える。ここで、LDAPに存在するユーザを入力して認証を確認する。

認証できた。認証した結果の属性が見えている。この属性は、SimpleSAMLphpのSimpleクラスのインスタンスに対して、getAttributes()メソッドで得られるものだ。実際には、例えば、cnキーに対して配列が得られて、0番目の要素として取り出すなどするが、ともかく、この属性値から、アプリケーションに必要な値を取り出す必要がある。とは言え、ざっと見たところ、ユーザ名はcn、フルネームはsnとgivenName、メールアドレスはmailというあたりが実際に欲しい情報かと思われる。

IdPはセットアップできた。SPは、前述の別記事のままで良い。SP側のTestでは、default-spが見えているはずで、これが上記のIdPと連携が取れていると思われるが、そのままdefault-spで認証テストをすると、上記のように、LDAPのユーザ情報が同じように得られる。

INTER-Mediatorでの設定は、params.phpファイルに仕込む。$isSAMLをtrueにして、SPの名前を入れ、キャッシュした情報での認証時間を1800秒とする。ここまでは普通のSAMLの設定だが、$samlAttrRulesに次のような配列を入れて、SAML属性からの値の取り出しを指定している。この変数は、キーがauthuserテーブルのフィールドを示し、値がSAML属性からの取り出しパスを指定している。例えば、属性のcnキーの値から0番目の要素を取ってきて、それをusernameフィールドに入れるということだ。なお、名前が姓と名で分離されているので、その場合は、値を配列にすれば、それぞれの要素をキーとして取り出した値を結合して、そのフィールドの値とする。ここではrealnameフィールドの値は「新居 雅行」となることを期待している（というか、この仕組み、さっき急いで実装したりした）。

$isSAML = true; # The default value of isSAML is false.
$samlAuthSource = 'default-sp';
$samlExpiringSeconds = 1800;
//$samlWithBuiltInAuth = true;
$samlAttrRules = [
    'username' => 'cn|0',
    'realname' => ['sn|0','givenName|0'],
    'email' => 'mail|0',
];

これで、SAMLベースでのLDAPユーザによる認証ができるようになった。

Ubuntu Server 24.04 LTSでINTER-Mediatorを稼働する

Ubuntu 24が正式にリリースされました。この上で、INTER-Mediatorを動かす方法をまとめておきます。期待通り、以前よりも追加モジュールは少なくて済むようになりました。セットアップ作業後、管理者アカウントで、以下のようにコマンドを入力します。

sudo apt -y -U upgrade
sudo apt install -y apache2 php mysql-server
sudo apt install -y nodejs
sudo apt install -y composer
sudo apt install -y php-xml php-gd
sudo apt install -y mysql-client php-pdo-mysql
sudo apt install -y postgresql php-pgsql
sudo apt install -y sqlite3 php-sqlite3

cd /var/www/html
sudo chown -R www-data:adm /var/www
sudo chmod -R g+rw /var/www
sudo systemctl restart apache2

git clone https://github.com/INTER-Mediator/INTER-Mediator.git
cd INTER-Mediator/
composer update

最初の塊は、必要なソフトウエアのインストールです。Linux自体のアップデートは、1つのコマンドでできるようになったので、早速使います。MySQLだけでなく、PostgreSQLやSQLiteについても記述しました。PHPのモジュールで足りないのは、xmlとgdだけでした。これだけのインストールで、最後のcomposer updateで必要なライブラリのダウンロードが成功します。これらでインストールされたソフトウエアのバージョンをまとめておきます。なお、Nodeについては、INTER-Mediatorのcomposer.jsonでも記述があり、そちらは、Ver.20をダウンロードして利用します。

  • Apache2：2.4.58
  • PHP：8.3.6
  • MySQL：8.0.36
  • Node：18.19.1
  • PostgreSQL：16.2
  • SQLite：3.45.1

2つ目の塊では、Apache2が稼働しているユーザwww-dataが、自分自身のホーム以下に書き込み権限があるようにしています。念の為、Apache2を再起動しています。この設定は、INTER-Mediatorの一部の機能では必要になります。

3つ目は、INTER-Mediatorのインストールです。なお、サンプルのデータベースを入れる必要があるので、続いて以下のようにコマンドを入れれば、3つのデータベースにサンプルデータベースのtest_dbがセットアップされます。最初にカレントディレクトリがINTER-Mediatorであることを前提にしています。特定のデータベースだけでいいのなら、他のデータベースについてのセットアップは無視してOKです。

cd dist-docs/
# MySQLのサンプルデータベース登録
sudo mysql -uroot < sample_schema_mysql.sql 

# PostgreSQLのサンプルデータベース登録
sudo -u postgres psql -c 'create database test_db;'
sudo -u postgres psql -f sample_schema_pgsql.sql test_db

# SQLiteのサンプルデータベース登録
sudo mkdir -p /var/db/im
sudo sqlite3 /var/db/im/sample.sq3 < sample_schema_sqlite.sql
sudo chown -R www-data:adm  /var/db/im

これで、「http://（サーバのIPアドレス）/INTER-Mediator/samples/」に接続すれば、INTER-Mediatorのサンプルの稼働が確認できます。

simplesamlphpのIdPでGoogle OAuth2認証を実行する

PHPでのSAML認証ライブラリであるsimplesamlphpは、PHPでSAML認証を行う場合にはほぼ一択となる選択肢です。これを利用してIdPを構築する方法は、https://blog.msyk.net/?p=1566 で紹介しました。本項目は、別掲の記事で紹介したIdPが存在する状態で、Google OAuth2、すなわちGoogleのアカウントでSAML認証を行えるようになるまでを紹介します。

とりあえずセットアップ方法とテスト方法は残しておかないといけないと思いつつ、まずは記事を書いたのです。INTER-MediatorでのGoogleアカウントでの認証は成功してはいませんでした。そして１日経過し、ふと疑問に思った事があります。simplesamlphpの追加モジュールとしてcirrusidentity/simplesamlphp-module-authoauth2を使うことにしています。このモジュールは、OAuth2の汎用モジュールなので、Google向けということではありません。さて、このモジュールは、IdPに必要なのか、SPに必要なのか、どちらなのでしょうか？　このことは、ライブラリのインストールのページにも書いていません。当たり前のことなのかな？

以下の方法で、IdPにまずはインストールして設定を追加して、リダイレクトURLはIdP側にしたのですが、認証されている状態になりませんでした。そこで、全く同じようにSP側にもモジュールを追加し、リダイレクトURLをSP側にしましたが、なんと、全く同じ結果になりました。どちらでもいいのかもしれません。どちらでやっても同じ結果になったので、どっちが正しいのかという結論はとりあえずは出ていません。しかし、OAuth2の認証サーバがすでにあるという前提を考えれば、SPだけを用意してそれを利用する方が明らかに作業は少なくて済みます。ということは、SP側にモジュールを追加して運用するのが正しいような気がします。IdPに登録したユーザで認証する結果をみていると、一旦IdPに行ってログインパネルを出して、そこから、SP内部へリダイレクトして認証結果が伝わってくるように思えるので、やはりそのこともあって、SPへモジュールを追加するのが正しいように思います。

Googleのプロジェクトから認証情報を得る

SimpleSAMLphpの設定の前に、GoogleからクライアントIDとシークレットを取得します。その方法はあちらこちらのサイトで記載されていますので、例えば、Shinonome Tech BlogのOAuth 2.0 を使用してGoogle API にアクセスする方法 に記載された「1.Google API ConsoleでOAuth2.0の認証情報を取得」の作業を行なってクライアントIDとシークレットを取得します。以下、それぞれ、MYCLIENTID、MYCLIENTSECRETと記述します。つまり、これらのキーワードが登場したら、Google Developer Consoleで取得した実際の値に置き換えて設定等を行なってください。なお、「承認済みのリダイレクトURI」には、以下のURLを指定します。module.php以下のパスは常に同じですが、それ以前は実際にSPのサイトをどのようにセットアップしたかに依存します。

https://demo.inter-mediator.com/simplesaml/module.php/authoauth2/linkback.php

なお、実際のSPは「アプリケーション内のsimplesamlphp」でもあるので、エイリアスを使わないパスだとこのようになります。いずれにしても、Google側への登録と、後で説明する認証画面を出すためのURLの両方に、同一のリダイレクトURLを指定する必要があります。

https://demo.inter-mediator.com/saml-trial/lib/src/INTER-Mediator/vendor/simplesamlphp/simplesamlphp/public/module.php/authoauth2/linkback.php

SPにモジュールを追加する

SPで使用するモジュールは、https://github.com/cirrusidentity/simplesamlphp-module-authoauth2.git です。simplesamlphp自体にはGoogle OAuth2に対応した処理を実行できる素材はないので、外部から追加します。composer.jsonに組み込むか、あるいは次ようなコマンドで追加でインストールを行います。

composer require cirrusidentity/simplesamlphp-module-authoauth2

続いて、SP側のsimplesamlphpのconfig/config.phpファイルを修正します。まず、この先で、SAML認証結果を利用するアプリケーションのドメインを追加します。既定値では[]になっていますが、OAuth2のモジュールはこの設定を見ているようです。

'trusted.url.domains' => ['demo.inter-mediator.com'],

そして、OAuth2モジュールを利用可能にします。IdPとしてセットアップするときに値を変更した配列に、1行加えます。

'module.enable' => [
    'exampleauth' => true,
    'core' => true,
    'admin' => true,
    'saml' => true,
    'authoauth2' => true,
],

次に、config/authsources.phpに次の指定を加えます。’default-sp’などと同じ階層にキーとして’google’を指定し、値として配列を指定します。MYCLIENTID、MYCLIENTSECRETは実際に取得した値にもちろん置き換えて指定します。

'google' => [
   'authoauth2:OAuth2',
   'template' => 'GoogleOIDC',
   'clientId' => 'MYCLIENTID',
   'clientSecret' => 'MYCLIENTSECRET'
],

SP側の設定はとりあえずこれでOKのようです。SPの管理画面に、authoauth2モジュールが稼働していることが見えています。

なお、Testのところに「google」というリンクが出ており、クリックするとGoogleのページを表示しますが、認証処理までには至りません。リダイレクトのURLが設定されていないというようなメッセージが見えます。

認証プロセスを通して見る

ここで実際に使用しているアプリケーションのURLは「https://demo.inter-mediator.com/saml-trial/chat.html」です。このURLと最初の方でGoogle Consoleで指定したリダイレクトURL「https://demo.inter-mediator.com/simplesaml/module.php/authoauth2/linkback.php」がこの後必要になります。これらのURLに加えて、MYCLIENTIDを含め、以下のURLの文字列をエディタ上などで整えます。URLEncodingをしてもいいのですが、問題ある文字列はないので、そのままこの文字列に置き換えて利用してもいいでしょう。そして、このURLをブラウザのアドレス欄に貼り付けて、Enterキーを押し、GoogleのOAuth2の認証プロセスに入ります。なお、URLの細かい点では別の機会に改めてきちんと処理すると言うことにして、まずは動く状態にしたいと思います。

https://accounts.google.com/o/oauth2/v2/auth?response_type=code&client_id=MYCLIENTID&scope=openid%20email&redirect_uri=リダイレクトURL&state=authoauth2|security_token%3D333344445555%26url%3DアプリケーションURL&nonce=0394852-3190485-2490358&hd=gmail.com

stateはちょっと適当にしていますが、「authoauth2|」で始まっていないと行けないのは、このモジュールでの実装です。また、stateの中に「url=アプリケーションURL」と言う記述があって、そこが後から効いてきます。

ちなみに、OAuth2に対応したサイト等では、認証がなされていない場合に、GoogleやFacebookの認証プロセスに入るボタンを提供するかと思います。その場合、「Google」ボタンをクリックすると、上記のURLにリンクするような作りになっているはずです。FacebookならFacebookの認証システムへのURLにパラメータを設定してジャンプするようになっています。

URLをブラウザのアドレス欄に入れると、Googleの認証の画面になります。状況は人によって違うのでしょうけど、いずれにしても、Googleの認証の画面になって、ログインしていない場合はユーザ名とパスワードの入力を行ないます。

Googleの認証ページから、アプリケーションURLに指定したURLにリダイレクトされます。

実のところ「よしOK!」とは行きません。INTER-MediatorのSAML対応では、このままでは認証を継続させる事ができないので、これからチェックしないと行けないのですが、アプリケーションURLに対しては、それよりも先にリダイレクトURLにアクセスし、さらにそこからアプリケーションURLへリダイレクトされているようで、GETメソッドで何のパラメータもありません。SAMLのクッキーがHTTP Onlyで乗ってくるだけのようです。ちなみに、SAML認証が成功すると、SimpleSAMLとSimpleSAMLAuthTokenという2つのクッキーが入るのですが、現状、IdP/SPいずれの側を利用しても、前者のクッキーしか入らず、後者は入ってこないのです。

(続報:2024-3-9)その後、色々やってみたのですが、認証が成功した状態のクッキーになりません。と言うことで、コードを読みました。simplesamlphp-module-authoauth2には認証後に返ってくるURL（linkback.phpで終わるもの）が記載されており、実際にそのリダイレクトURIが呼び出されています。そこをチェックすると、前述の「https://accounts.google.com/o/oauth2/v2/auth」に対するstateパラメータの値は、次のようになるはずです。色々試しているうちに、セッションデータが落ちてきたのでわかったことです。

state=authoauth2|_796bed184adf107c10c0faf60c658c7da54d2b0972:アプリケーションURL

最初は「authoauth2|」である必要があります。リダイレクトされた最初の段階でチェックしています。続いて、|より後の文字列について、:で区切って、最初をid、最初の:以降をマージしてurlとしています。エラーがあると、そのurlにリダイレクトがします。セッションのデータが何かのきっかけで落ちてきた時に、そこからデータが取り出せるとしたら、|と最初の:の間は上記のコードか、もしくは「_eff7a14ba6adc55b6cd2f08b0399b747ed3ac9844e」である必要があります。このコード、ランダムに充てられている可能性もありますが、このデータで数回セッションデータが得られた後、セッションデータはほぼ空っぽのものばかりになってしまっていました。それで、SPの管理ページのログインテストを利用して、一度認証した状態にしておいて、アプリケーションを動かすと、今度は、セッションデータは何か大量に乗っかってきています。SimpleSAMLAuthTokenクッキーも来ました。しかし、その時のstateの|より後にくるべきコードは違うものでした。やはりランダムでした。このstateは最初にaccounts.google.comを呼び出すときに引数に指定しないといけないと言うことは、開発者が指定しないといけないと考えられますが、それを得る方法はわかりません。あるいは指定したコードが乗ってくるということなのかな？もうちょっとコードを追ってみようと思います。と言うことで、ここまでは行けました。ちょっとだけ進歩したかな。そうこうしているうちに、SimpleSAMLphpのVer.2.2.0が出ましたね。セッションのなかに、「アップデートしろー！」って情報がどっさり。

SimpleSAMLphp Ver.2を使ってみる(3)

(1)はIdPの起動、(2)はIdPの管理画面のチェックと進みました。ということで続いてSPです。ここでのSPはINTER-Mediatorで稼働しているという前提で話をします。状況としては次のようなものです。

  • 証明書を発行済みのドメインdemo.inter-mediator.com内で稼働する。DocumentRootは/var/www/demo_im_com
  • DocumentRootにsaml-trialディレクトリを作り、そこに、ページファイルchat.html、定義ファイルchat.phpを定義した
  • INTER-Mediatorは、saml-trial/lib/srcにgit cloneでインストールして、composerで必要なライブラリをインストール
  • 結果的に、SimpleSAMLphpのレポジトリのルートは、DocumenRoot以下、saml-trial/lib/src/INTER-Mediator/vendor/simplesamlphp/simplesamlphp となる
  • 設定ファイルのparams.phpは、saml-trial/lib/src/params.phpとする
  • demo.inter-mediator.comをホストしているApache2のsiteファイルでは、以下のように、/simplesamlへのエイリアスを作成する（Aliasの行は1行で記述）
<VirtualHost *:443>
    ServerAdmin info@inter-mediator.org
    DocumentRoot /var/www/demo_im_com
    ServerName demo.inter-mediator.com
Alias /simplesaml "/var/www/demo_im_com/saml-trial/lib/src/INTER-Mediator/vendor/simplesamlphp/simplesamlphp/public"

いきなり動くかなと確かめてみたら、ダメでした。composerの扱いをちゃんとやらないといけません。ここでは、composer.jsonのsimplesamlphp/simplesamlphpの値を”2.0.4″とバージョンをしっかり入れるようにしてみました。INTER-Mediatorの場合、composer clearnでライブラリを消して、composer update, composer installの順でコマンドを入れれば良いでしょう。

simplesamlphpの管理ページは、前回にも紹介したように、赤いヘッダなどがついたもので、CSSやスタイルシート、画像などが提供されています。ブラウザでパスを見る限りは、/simplesaml/assets/base…となっているので、レポジトリのpulic/assetsを見るのですが、空です。どうやら、assets以下の内容は、simplesamlphp/simplesamlphp-assets-baseという別のパッケージにあるようで、これが読み込まれていません。この別パッケージをassets以下に展開するには、composer installが必要なようで、結果的にupdateとinstallは両方行う必要があるようです。

設定ファイルの記述

これまでのセットアップを行うと、SimpleSAMLphpのSP自体は、パスがちょっと長いですが、/var/www/demo_im_com/saml-trial/lib/src/INTER-Mediator/vendor/simplesamlphp/simplesamlphpに存在することになります。以下のこのパスを「SPのルート」と記載します。このディレクトリの、configに設定ファイル、metadataにメタデータファイル、certに証明書類を入れるのが基本です。以下、参考にコマンドを記述しますが、INTER-Mediatorではもう少し手軽にする方法を用意していて、近々、これをSimpleSAMLphp Ver.2向けに更新する予定です。

まず、通信暗号化のための証明書を作ります。この証明書はサイトのTLSのための証明書を使ってもよく、実際には案件ではそのようにしましたが、SimpleSAMLphpのサイトの説明では、10年期限の自己署名証明書を作っています。サイトの証明書はつまり「自己署名だとダメかも」と思って使っていたわけですが、本家の説明がいきなり自己署名なので、単に暗号化のためだけに使っているということですね。opensslコマンドの後に属性などを入力しますが、(1)のIdPのところと同様適当に入れればいいかと思います。-outと-keyoutの後のファイル名も適当に指定します。

cd cert
openssl req -newkey rsa:3072 -new -x509 -days 3652 -nodes -out sp.crt -keyout sp.pem

SPのルート以下、configディレクトリには、元からあるconfig.php.distからコピーしたconfig.phpを用意します。そして、その内容を変更します。ポイントは以下の点です。baseurlpathは、SPのルートのpublicを参照するようにします。以前はwwwを参照していましたが、Ver.2で変わっています。残り3つの設定は、IdPと同様ですので、(1)の記事を参照してください。

'baseurlpath' => 'saml-trial/lib/src/INTER-Mediator/vendor/simplesamlphp/simplesamlphp/public/',
'technicalcontact_email' => 'your_email',
'secretsalt' => 'your_salt',
'auth.adminpassword' => 'your_admin_pass',

SPのルート以下、configディレクトリには、元からあるauthsources.php.distからコピーしたauthsources.phpを用意します。以下のように、default-spキーの配列の要素に、certificateとprivatekeyのエントリーを用意して、ここで作成したキーファイルと証明書ファイルを指定します。そして、entityIDをサイトのドメインに設定しておきます。

'default-sp' => [
  'saml:SP',
  'certificate' => 'sp.crt',
  'privatekey' => 'sp.pem',

   // The entity ID of this SP.
   'entityID' => 'https://demo.inter-mediator.com/',
   :

SPのルート以下、metadataディレクトリには、元からあるsaml20-idp-remote.php.distからコピーしたsaml20-idp-remote.phpを用意します。このファイルの最後（とはいえ、中身は短いコメントがあるのみ）に、IdPの管理ページからコピーした配列をコピーしておきます。

SPの管理ページからメタデータを取得

ということで、インストールに少しハマってしまいましたが、なんとか動きました。一応のルートは、https://demo.inter-mediator.com/simplesaml ですが、こちらは「ようこそ」と出るだけです。SPの管理ページに行くには、このURLの後にadminをつけた、https://demo.inter-mediator.com/simplesaml/admin にアクセスします。そして、config.phpで指定したパスワードを入力して、管理者として認証します。

設定のページは諸々確認できますが、ModulesのところでIdPとしては稼働していないことなどが分かります。

Testのタブでdefault-spのリンクをクリックすると、次のような画面が見えており、登録したIdPを認識していることが分かります。ただ、ここで「選択」をクリックするとエラーになるので、まだ何か問題なのかもしれません。

連携のところで、「V」の部分をクリックすると、メタデータが表示されます。このメタデータを、IdPに登録します。IdPがSimpleSAMLphpなら、metadata/saml20-sp-remote.phpファイルに追記することになります。

認証できています

それでは実際にIdPで認証したユーザで、INTER-Mediatorのアプリケーションを使ってみます。通常、ログインパネルが出てくるとこが、IdPというか、SPの画面に行きます。ここでは、まず、IdPを選択します。

すると、ログインパネルが出てきます。こちらはドメインを見ればわかるように、IdP側に切り替わっています。ここでは、テストユーザのuser01でログんを試みます。

無事にログインができ、メッセージが見えています。

ちなみに、SAML-tracerを使って追っかけてみました。チャットのアプリケーションのURL（https://demo.inter-mediator.com/saml-trial/chat.html）をブラウザに入れると、何度かリダイレクトされて、IdPの側の認証ダイアログが表示されます。そこまでのトレースは以下の通りです。

続いて、正しいユーザとパスワードを入力して、IdPにポストしますが、その後、アプリケーションのURLにリダイレクトされています。この時は、認証が通っているので、アプリケーション側でも、認証が通った後の処理をして、ページが構築されています。

ということで、SimpleSAMLphp Ver.2.0.4でも動くことを確認しましたが、途中ちょっとハマった理由は、すでにVer.3の作業に入っていることに気づかず、dev-masterで作業したら、色々思った通りに動かなかったのでした。Packagistのサイトを見て、あ、Ver.3.0.0になっていると気づき、Ver.2.0.4で通るようにやり直して稼働を確認できたという次第です。ちゃんとチェックしようねってことですね。

SimpleSAMLphp Ver.2を使ってみる(2)

前の記事では、テスト用のIdPを起動するところまでを説明しました。Ver.2ではIdPの管理画面も新しくなっているので、続いてその管理画面に何が出ているかを確認しましょう。

まず、画面上部のタブ「設定」のページです。最初にSimpleSAMLphpのインストール場所やバージョンが見えています。正しく、Ver.2.0.4がインストールされていると判断できるでしょう。そして、インストールされているモジュールや動作チェックなどがあります。Ver.2になった変更点として、プラグイン的に必要な機能は追加するようになったと記載があり、必要な素材が全部入っている状態ではありません。必要な機能があるのなどはこの画面などでのチェックも必要かもしれません。

前の画面のDetailsにある「Information on your PHP installation」のリンクは、phpinfo()関数を動かした結果を表示します。「ホストネームやポート、プロトコルを診断」は次のような画面を表示します。サーバがきちんと動くようなら、特に確認は不要かもしれません。

「Test」のタブでは、admin、default-sp、example-userpassの3つのリンクがあります。まず、adminは次のように、管理者ログインに関する情報が見えています。

「default-sp」をクリックしても「No identity providers found. Cannot continue.」と出るだけです。これは正しい状態なのか、追々調べます。

example-userpassをクリックすると、次のようにログインパネルが出て、ログインの検証が可能です。ここで、config/authsource.phpで定義したユーザとパスワードを入れてログインをしてみます。

正しいユーザ名とパスワードを入れれば認証が行われて、その時に得られる属性についても表示されます。

ページ上部の「連携」をクリックすると、次のような表示が見えます。SPが2つになってしまっていますが、idpのドメイン名を設定した側を利用するものとして想定します。ここでは、中央付近に見えているボックスの下部にある「V」部分をクリックします。

V部分をクリックすると、表示が開いて、IdPのメタデータが表示されます。上部が一般的なXMLによる記述で、下部がSimpleSAMLphpで利用できるPHPの配列形式のメタデータです。ともかく、SPとの連携の時のデータは取り出しができるようです。

以上のように、IdPの管理画面としては、以前より少しは機能が増えたものの、SPの登録などはないようなので、やはり基本は設定ファイルを修正するということになるでしょう？認証可能かどうかやインストール状態などの動作チェック等にはある程度は利用できそうです。

SimpleSAMLphp Ver.2を使ってみる(1)

PHPでSAML認証を実現するライブラリ、SimpleSAMLphpが、2023年からVer.2となりました。SAML 2.0に対応するのは以前から、つまり、SimpleSAMLphp Ver.1でもSAML 2.0に対応していましたが、どちらのバージョンも「2」になったということです。バージョン記述がややこしいですが、まあ、これを読んでいる方は慣れているかと思いますので、先に進みます。

この記事は2023 7/1に最初に記述しましたが、状況が変わりつつあるのとノウハウが少し溜まったこともあって、2024/3/2までに追記を何度か行なっています。

INTER-MediatorはSimpleSAMLphpベースでSAML対応しています（勉強会での発表ビデオはこちらです）。SAMLというか、Shibboleth認証の案件を実際に行ったこともあります。ということで、SimpleSAMLphp Ver.2は早めにチェックしようと思いつつ、今になってしまいました。

SimpleSAMLphp Ver.2になっての違いはこちらのページに記載されています。かいつまんで説明すると、Shibboleth 1.3、SAML 1.1にはもう対応しないということで、SAML 2.0のみ対応となっています。ということは、Shibboleth案件は、Ver.1.19.xあたりで作業する必要があるということになります。設定ファイル名は変わっていないものの、「作り直したほうがいい」となっていますので、手順を含めて、引き続いてそのあたりは説明したいと思います。それから、いくつかの重要なパスも変わっています。これも説明で紹介します。

INTER-MediatorのSAMLのテストは、SimpleSAMLphpによるIdPと、SimpleSAMLphpによるSPを使って行うようにセットアップをしてあるのですが、改めて、この環境を構築し直しを始めました。その記録をブログにつけていこうと思います。IdPには、テスト用のアカウントをいくつか記録する程度で、そこから別の認証サービスを使うまではとりあえずは考えていません。

テスト環境ですが、Ubuntu Server 22.0.4 LTSです。よって、PHPは8.1です。普通に、Apache2、PHPとモジュールをインストールしました。INTER-Mediatorをインストールする以外には、PHPのSOAPモジュールを追加するだけで大丈夫でした。 テスト用のアプリケーションも当然ながらINTER-Mediatorで作ってあるのですが、SimpleSAMLphpのVer.1とVer.2の相互運用も考えないといけないのかなとも考えられます。

さて、数年前に一生懸命検証をした時の１つの結論は、「ちゃんとドメインを切って、正しい証明書をセットアップしたサイト」にするということです。その時の設定はまだあって、IdP用にidp.inter-mediator.com、アプリケーションとSPはdemo.inter-mediator.com/saml-trialにしました。いずれも、Let’s Encryptではありますが、それぞれ有効な証明書が動き、通信はすべてHTTPSで動くという状態になっています。

IdPサイトの構築

IdPのサイトは、SimpleSAMLphpのコードをそのまま使って構築します。Ubuntuなので、/var/www以下に、例えば、以下ようなコマンドで、コードを取り出します。バージョンごとにタグがあるので、Ver.2系列の最新版である2.1.4をインストールすることにします。そして、composerを動かして、必要なライブラリのインストールを行います。

cd /var/www
git clone https://github.com/simplesamlphp/simplesamlphp simplesaml-idp
cd simplesaml-idp
git checkout v2.1.4
composer update

/var/www以下は、ログインしたユーザであれば書き込みできるという前提で説明をします。また、ログインしたユーザはsudoコマンド可能であって、root権限が必要な処理はsudoを利用するという方針でコマンドを示します。また、ログインユーザはadminsグループにも登録してあるものとします。

前述のコマンドで、/var/www/simplesaml-idpというディレクトリができ、そこにレポジトリの内容が展開されました。このディレクトリを公開するのかというと、そうではなくて、この中のpublicを公開します。以前はwwwというディレクトリでしたが、Ver.2でpublicという名前に変えたそうです。ということで、Apache2のidp.inter-mediator.comのサイト設定ファイルは、大体以下のような記述つまり、DocumentRootがある感じです（実際には証明書の設定などもあってもっとややこしい）。/simplesamlはIdPの設定ファイルに書かれているbaseurlpathの値でもあるので、とりあえずAliasを定義しておきます。

<VirtualHost *:443>
    ServerAdmin info@inter-mediator.org
    DocumentRoot /var/www/simplesaml-idp/public
    ServerName idp.inter-mediator.com
    Alias /simplesaml "/var/www/simplesaml-idp/public"
:

さて、サーバを見てみましょう！という感じで開くと、次の通りです。当然、セットアップを何もしていないので、そのような表示が出るだけです。ちゃんと、設定ファイルがないとメッセージが出ています。

IdPが使う証明書を用意する

SAMLでは通信の暗号化のために証明書を使います。IdPで使用する証明書は、opensslコマンドを使って作成しますが、レポジトリのcertディレクトリに作るのが一番手軽です。このディレクトリに作った証明書関連のファイルは、フルパスを指定する必要がありません。例えば、以下のようなコマンドで作成できます。

cd /var/www/simplesaml-idp/cert
openssl req -newkey rsa:3072 -new -x509 -days 3652 -nodes \
    -out idp.inter-mediator.com.crt -keyout idp.inter-mediator.com.pem

コマンド例ではカレントディレクトリを明示するためにcdコマンドを随所で書くようにしますが、もちろん、コマンドの理解がある方は自分の状況に応じてコマンドを入れてください。そして、opensslコマンドの-outと-keyoutの2つのパラメータは実際に保存されるファイル名になるので、自分のドメイン等に変えるか、server.cert、privatekey.pemみたいな名前にするのが良いでしょう。

乱数生成などの後、入力を促されます。要するに大雑把な住所と組織などを入力します。以下は私が入力した例ですが、もちろん、ご自分の状況に合わせてください。Common Nameについては、FQDNを入れるのが良いと思われます。

Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Saitama
Locality Name (eg, city) []:Midori-ward
Organization Name (eg, company) [Internet Widgits Pty Ltd]:INTER-Mediator
Organizational Unit Name (eg, section) []:Authentication Support
Common Name (e.g. server FQDN or YOUR name) []:idp.inter-mediator.com
Email Address []:nii@msyk.net

なお、生成されたキーファイルは、ownerだけが読み書きできて、gropuやeveryoneに対する読み出し権限すらありません。Apache2のプロセスのユーザ（Ubuntuではwww-data）が読み出し権限があるようにしなければなりません。しかしながら、アクセス権は、レポジトリの内容全体に設定した方が手軽でしょうから、アクセス権の設定は最後にまとめて行います。

configディレクトリの設定を行う

それでは、設定を進めましょう。まず、レポジトリのルートにあるconfigディレクトリの中身です。このファイルには3つの設定ファイルを作りますが、そのうち、config.phpとauthsources.phpの2つのファイルを用意します。このファイルはスクラッチから作るのではなく、ファイル名に.distが付いたテンプレートのファイルがあるので、それをコピーして用意します。まず、ファイルをコピーします。

cd /var/www/simplesaml-idp/config
cp authsources.php.dist authsources.php
cp config.php.dist config.php

config.phpファイルは、以下のポイントを修正します。 そのためにvimやnanoなどのエディタで開くことになりますが、その前に、以下のコマンドを入れて、secretsaltキーの値を生成しておきます。このことはファイルのコメントにも書かれてあり、以下のコマンドで生成して、出力結果をコピーしておきます。

LC_ALL=C tr -c -d '0123456789abcdefghijklmnopqrstuvwxyz' </dev/urandom | dd bs=32 count=1 2>/dev/null;echo

そして、config.phpファイルを編集します。まず、technicalcontact*は、このサーバの管理者です。基本的には自分を指定すれば良いでしょう。secretsaltはファイルを開く前にコピーしたものを指定すればよく、文字列の中身を消してペーストします。auth.adminpasswordは、IdPのログインする管理者のパスワードです。

:
    'technicalcontact_name' => 'Administrator',
    'technicalcontact_email' => 'msyk@msyk.net',
:
    'secretsalt' => 'whr5p645s3ig7nm9wxibfckllmjfvjl6',
:
    'auth.adminpassword' => 'samltest5682',
:
    'enable.saml20-idp' => true,
    'enable.adfs-idp' => false,
:
    'module.enable' => [
        'exampleauth' => true,
        'core' => true,
        'admin' => true,
        'saml' => true
    ],

enable.saml20-idpは、文字通り、IdPの機能をアクティブにします。module.enableは、exampleauthの値をtrueにしますが、これは、設定ファイルで認証ユーザを提供する仕組みをオンにします。もちろん、簡易的にテストができるようにということです。

続いて、config/authsources.phpの修正です。まず、default-sp以下の配列において、entityIDを変更します。そして、この配列内に、privatekeyとcerificateというキーで、それぞれ秘密鍵と証明書のファイル名を指定しておきます。もちろん、ここでは、前の手順でopensslで生成したファイルを指定します。さらに、テスト用のユーザとして、example-userpassの部分のコメントを外して、その中に定義します。以下の例では、user01というユーザとuser02というユーザが定義されており、それぞれ、パスワードはuser01pass、user02passです。キーになっている’user01:user01pass’の部分でユーザ名とパスワードを表現しており、対応する配列は応答する情報を記載します。ちなみに、大学のディレクトリなどでは、eduPersonAffiliationといった属性が入ってきて、それに応じて大学生か、職員かを判断するようなロジックを求められることはよくあるようです。

:
    'default-sp' => [
        'saml:SP',

        // The entity ID of this SP.
        'entityID' => 'https://idp.inter-mediator.com/',
:
        'proxymode.passAuthnContextClassRef' => false,

        'privatekey' => 'idp.inter-mediator.com.pem',
        'certificate' => 'idp.inter-mediator.com.crt',
:
    'example-userpass' => [
        'exampleauth:UserPass',
:
        'user01:user01pass' => [
            'uid' => ['user01'],
            'eduPersonAffiliation' => ['member', 'student'],
        ],
        'user02:user02pass' => [
            'uid' => ['user02'],
            'eduPersonAffiliation' => ['member', 'employee'],
        ],
    ],

metadataディレクトリの設定を行う

続いて、レポジトリルートにあるmetadataディレクトリの設定を行います。このディレクトリも設定ファイルはないものの、拡張子が.distとなっているそれぞれのファイルのテンプレートがあるので、それをコピーして変更して利用します。3つのファイルがありますが、利用するのは2つだけです。コピーしないsaml20-idp-remote.phpファイルは、SPで利用するものです。

cd /var/www/simplesaml-idp/metadata
cp saml20-idp-hosted.php.dist saml20-idp-hosted.php
cp saml20-sp-remote.php.dist saml20-sp-remote.php

ちなみに、ファイル名がややこしいと思われるかもしれませんが、それぞれ、IdPの設定、SPの設定を行います。IdP自分自身についてはhostedの方で設定します。そして、SPの設定は自分ではないので、remoteであるということです。ファイル名にはきちんと意味があると思えば、少しは見通しよく見えるのではないでしょうか。

metadata/saml20-idp-hosted.phpについては、以下を修正します。まず、$metadata配列のキーについてはキーの値を既定値から変更して設定します。ここでは、とりあえず、IdPのドメインにしました。ちなみに、このキーを既定値のままにすると、動作がおかしかったので、これを切り替えるのが必要ではないかと思われます。そして、privatekeyとcertificateキーのファイル名を、生成したファイルのものに切り替えておきます。

$metadata['https://idp.inter-mediator.com/'] = [
    /*
     * The hostname of the server (VHOST) that will use this SAML entity.
     *
     * Can be '__DEFAULT__', to use this entry by default.
     */
    'host' => '__DEFAULT__',

    // X.509 key and certificate. Relative to the cert directory.
    'privatekey' => 'idp.inter-mediator.com.pem',
    'certificate' => 'idp.inter-mediator.com.crt',

実際にはもっといろいろ変更は必要なのでしょうけど、ここまでの設定だと、証明書やキーのファイルの整合、IdPを稼働、テストユーザの登録程度のことです。

全てのファイルの所有者とグループを揃える

必要なファイルをすべて揃えたので、simplesamlphpのファイルの所有者を、Webサーバのwww-dataに変更しておくのがいいように思います。例えば、次のようなコマンドです。

sudo chown -R www-data:admins /var/www/simplesaml-idp
sudo chmod -R g+w /var/www/simplesaml-idp

こうすれば、simplesaml-idp以下のすべてのファイルやフォルダは、所有者がWebサーバのプロセスのユーザであるwww-dataになり、グループはadminsになります。そして、所有者はrwあるいはrwxになりますが、グループも同様なアクセス権になることを期待します。通常ログインするユーザをadminsグループに入れておけば、そのユーザでのファイルの読み書き権限もあり、Webユーザの読み書き権限も確保していると言うことになります。simplesamlphpのIdPでは、ファイルの書き込み権限がWebサーバに対して必要なのかという問題はありますが、とりあえずはメンテナンスしやすい状態にしていると考えてください。

キャッシュのディレクトリを用意する

ここで、https://idp.inter-mediator.com/ つまり、Webのルートにアクセスすると次のような画面が出てきます。Ver.2.0.xではこのような画面は出てこなかったのですが、Ver.2.1.xでは出るようになったようです。

このエラーはよく読むと、意味がわかります。どうやら、既定値では、/var/cache/simplesamlphp以下のキャッシュファイルを作るようで、そのディレクトリが必要ということに加えて、アクセス権も設定が必要なようです。例えば、次のようなコマンドで対処できます。

sudo mkdir -p /var/cache/simplesamlphp
sudo chown -R www-data：admins /var/cache/simplesamlphp

キャッシュとして、かなりたくさんのファイルが作られます。

なお、simplesamlphp自体をgitを使って更新した後などは、場合によってはキャッシュをクリアしておかないと起動時にエラーになる場合もあります。エラーにならない時もあるのですが、いずれにしてもソースコードの変更によってキャッシュの整理は場合によっては自分でやらないといけない模様です。謎のエラーが出た場合には、/var/cache/simplesamlphp以下を消してみてください。

管理ツールを稼働する

ここで、https://idp.inter-mediator.com/ つまり、Webのルートにアクセスすると次のような画面が出てきます。ちゃんと動いている模様ですが、肝心の管理作業ができません。

管理作業をするには、https://idp.inter-mediator.com/admin にアクセスします。いろいろリダイレクトしますが、認証画面が出てきます。ここでは、ユーザ名はadmin、パスワードは、config.phpファイルに指定したパスワードを入力して認証します。

最初は、以下のようにTestというタブのページになります。ここから先は次の記事で説明ます。

Ubuntu 22でINTER-Mediatorを稼働する

Ubuntu Server 22.04.1 LTS上で、INTER-Mediatorのサンプルを、MySQLで動かすところまでのセットアップ方法を紹介します。サーバは普通にDVD等でインストールします。ほぼ、デフォルトでセットアップした状態を想定しているので、Minimalの方ではありません。また、サーバアプリケーションは、SSH Serverだけをセットアップ時に含めているとします。

ということで、早速、インストール後のコマンド入力です。一気にまとめて紹介します。

sudo apt -y update
sudo apt -y upgrade
sudo apt install -y apache2 php mysql-server
sudo apt install -y php-curl php-xml php-gd libicu-dev \
                    mysql-client php-pdo-mysql
sudo apt install -y nodejs
sudo apt install -y composer
sudo chmod -R g+w /var/www
sudo chown -R www-data:<user> /var/www
sudo systemctl restart apache2

cd /var/www/html
git clone https://github.com/INTER-Mediator/INTER-Mediator.git
cd INTER-Mediator/
composer update
cd dist-docs
sudo mysql -uroot < sample_schema_mysql.sql

「php」でインストールすると、Ver.8.1がセットアップされます。モジュール類も以前よりも多く初期設定で入っているので、記載した、php-curlなど3つと、データベースのドライバを追加するだけで大丈夫です。ただ、intlモジュールが利用するlibicu-devを入れておかないといけないのは以前から変わっていないところです。php-pdo-mysqlは実は存在しておらず、php8.1-mysqlが代わりにインストールされます。php-mysqlというモジュールもあってこちらでも良さそうな気がしますが、とりあえず、PDO本体は入るけどもMySQLのPDOサポート部分は追加しないといけないというところがポイントです。よって、PostgreSQL等でも同様にPDOドライバを入れないといけないということです。

Node.jsは「念の為に」入れておきます。composerもaptでインストールできるようになっています。

Apache2は以前の通り、www-dataユーザで稼働するので、このユーザのホームである/var/wwwのアクセス権を設定しておきますが、chownでのグループはログインユーザ名にしておくのがいいかと思います。そして、Apache2を再起動します。以前よりだいぶんとシンプルになった気がします。

後半は、INTER-Mediatorのインストールです。とりあえず、Web公開ディレクトリにレポジトリの中身を展開してそれを動かすことにします。クローン後、composer updateコマンドを動かし、サンプルのデータベースをMySQLに読み込ませて準備するだけです。これで、「http://ホストIP/INTER-Mediator/samples/」で、サンプルの目次ページが出てくるはずです。

現在は既定値でサービスサーバを落としていますが、INTER-Mediator/params.phpの以下の部分を修正すると、サービスサーバが稼働します。コード部分は修正前ですので、コメントに従って変更してみてください。Sample_formフォルダのサンプルがクライアント間同期の仕組みを組み込んであります。サンプルの目次ページだと、「Any Kinds of Samples」の最初にある「Master-Detail Style Page」のリンクを利用してください。

$notUseServiceServer = true; // 値をfalseにする
/*　　// この行を消してコメントでなくする
$activateClientService = false; // 値をtrueにする
$serviceServerProtocol = "ws";
$serviceServerHost = "";
$serviceServerPort = "11478";
$serviceServerKey = "";
$serviceServerCert = "";
$serviceServerCA = "";
$serviceServerConnect = "http://localhost"; // localhostを実際のホストにする
$stopSSEveryQuit = false;
$bootWithInstalledNode = false;
$preventSSAutoBoot = false;
$foreverLog = '/tmp/forever.log';
*/　// この行を消してコメントでなくする

macOSでPHPのバージョン管理

普段、最新のPHPでの検証が多いのですが、久々に、古いアプリケーションのメンテのために、8.2.0がカレントバージョンの今、7.4を使う必要が出ました。そのアプリが8.2で動いてくれればいいのですが、Warningが出るので7.4にしたいですね。当然、phpはhomebrewを使っているのですが、標準ではカレントバージョンしかサポートしていないらしく、あちこちに掲載されている「brew install php@7.4」がエラーになって動かないのです。こんな感じ。

% brew install php@7.4
Error: php@7.4 has been disabled because it is a versioned formula!

こういう場合は、上記2行目のエラーメッセージを、そのままGoogle検索窓にコピペして検索します。やはり、StackoverflowにError: php@7.3 has been disabled because it is a versioned formulaという記事が見つかりました。

ということで、標準以外のバージョンをインストールできるTapがあるということで、以下のようにコマンドを入れれば、無事にphp 7.4がカレントになりました。

brew tap shivammathur/php
brew install shivammathur/php/php@7.4

この後に、brew link …とすればいいかと思うのですが、現行バージョンのver.8.2をunlinkする前だと、–overwriteをつけろとメッセージが出てきます。以下の流れだと、–overwriteは不要かもしれませんが、エラーの時には試してみましょう。

% brew unlink php@8.2
% brew link --overwrite php@7.4
Linking /usr/local/Cellar/php@7.4/7.4.33... 25 symlinks created.

If you need to have this software first in your PATH instead consider running:
  echo 'export PATH="/usr/local/opt/php@7.4/bin:$PATH"' >> ~/.zshrc
  echo 'export PATH="/usr/local/opt/php@7.4/sbin:$PATH"' >> ~/.zshrc
% php -v                       
PHP 7.4.33 (cli) (built: Dec  8 2022 21:39:37) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.33, Copyright (c), by Zend Technologies

そういうわけで、PHPの各バージョンは、こちらのレポジトリのようにしっかり古いものからより新しいものまでキープしてくれていることに感謝です。

FileMaker Server 19.4(Ubuntu)の稼働するLinuxでPHPも稼働させる

FileMaker Server 19.4.2.204が稼働するUbuntu Server 18では、デフォルトではPHPは入っていません。自分で入れれば動くのはわかっているのですが、いわゆる「インストーラ」はないので、色々うまく設定しないといけなくなります。一応、動かす方法はわかったので、忘れないようにここに書いておきます。

まず、PHPのインストールですが、Ubuntuの普通のパッケージだと7.2です。せめて7.4にしたいので、こちらのサイトを参考に以下のようにコマンドを入れました。レポジトリを追加して、PHP 7.4をインストールします。

sudo apt-get update
sudo apt -y install software-properties-common
sudo add-apt-repository ppa:ondrej/php
sudo apt-get update
sudo apt -y install php7.4

これだけだと、UbuntuでのサービスとしてのApache2を稼働させるとおそらくPHPは稼働しますが、FileMaker ServerのApacheは、独自の方法で起動しているので、そちらでPHPを認識させないといけません。

そこで、以下のようにコマンドを入れて、メインの設定ファイルを修正します。最初のcdコマンドで移動するパスが、FileMaker Serverをインストールした場合のApacheのルートディレクトリです。

cd /opt/FileMaker/FileMaker\ Server/HTTPServer/
sudo nano conf/httpd.conf

以下のような場所があるので、まずここを検索します。

#
# Disable PHP document
#
<FilesMatch "\.php$">
    Require all denied
</FilesMatch>

この部分を、以下のように変更します。php.confはこれから作ります。

#
# Disable PHP document
#
#<FilesMatch "\.php$">
#    Require all denied
#</FilesMatch>

Include conf/extra/php.conf

これだけでよさそうに思うのですが、これだけだと次のようなメッセージが出てしまいます。

[Wed Jan 19 11:11:29.516483 2022] [php7:crit] [pid 30487:tid 140490306792384] Apache is running a threaded MPM, but your PHP Module is not compiled to be threadsafe.  You need to recompile PHP.
AH00013: Pre-configuration failed

Apacheはマルチスレッド対応だけど、PHPは違うから、PHPを再コンパイルしろとあります。再コンパイルできるなら、レポジトリから取って来ません。そこで、若干問題が生じる可能性もあるのですが、Apacheをマルチスレッドではない状態で動かします。こちらのサイトを参考にしましたが、手順は異なります。

この点を解決するためにconf/httpd.confの編集を続けます。以下のような部分を検索します。「mpm」で検索すると良いでしょう。

LoadModule mime_module /usr/lib/apache2/modules/mod_mime.so
LoadModule mpm_event_module /usr/lib/apache2/modules/mod_mpm_event.so
LoadModule negotiation_module /usr/lib/apache2/modules/mod_negotiation.so

これを、次のように変更します。mpm_event_moduleをコメントにして読み込みません。新たに、mpm_prefork_moduleを読み込みます。記載されていないモジュールの読み込みが増えていますが、そのモジュールはもともとありました。

LoadModule mime_module /usr/lib/apache2/modules/mod_mime.so
#LoadModule mpm_event_module /usr/lib/apache2/modules/mod_mpm_event.so
LoadModule mpm_prefork_module /usr/lib/apache2/modules/mod_mpm_prefork.so
LoadModule negotiation_module /usr/lib/apache2/modules/mod_negotiation.so

これで、httpd.confを保存しておきます。

続いて、php.confを作ります。php7.4をインストールしたときに作られるファイルから適当に記述を持ってきて作ったものです。エディタを起動するために、次のようにコマンドを入れます。

sudo nano extra/php.conf

もちろん、存在しないファイルなので、エディタの画面は真っ白です。ファイルの中身は次のようにします。

LoadModule php7_module /usr/lib/apache2/modules/libphp7.4.so

<FilesMatch ".+\.ph(ar|p|tml)$">
    SetHandler application/x-httpd-php
</FilesMatch>
<FilesMatch ".+\.phps$">
    SetHandler application/x-httpd-php-source
    # Deny access to raw php sources by default
    # To re-enable it's recommended to enable access to the files
    # only in specific virtual host or directory
    Require all denied
</FilesMatch>
# Deny access to files without filename (e.g. '.php')
<FilesMatch "^\.ph(ar|p|ps|tml)$">
    Require all denied
</FilesMatch>

冒頭のLoadModuleは必須として、最初のSetHandlerだけでも多分動くと思いますが、とりあえず、他のものも入れておきました。なお、元のファイルにあったユーザのホームで公開した場合にスクリプトを動かさないようにする設定は省きました。

ここで、Apacheサーバだけを再起動とかして動くようにするのがお作法なのですが、サーバ自体を再起動します。それが確実なようです。すると、PHPが動きました。ちなみに、php.iniファイルのパスは、/etc/php/7.4/apache2/php.ini です。

こうしてPHPが稼働する状態になっているなら、PHPのモジュールはインストールするだけでOKです。例えば、初期状態ではcurlが稼働しませんが、次のようにコマンドを入れます。

sudo apt-get install -y php7.4-curl

すると、/etc/php/7.4/apache2/conf.dに、curl.iniファイルへのショートカットが作られて、認識します。あとは、サーバー再起動でもいいのですが、httpdctl gracefulでも設定は反映されます。

ちなみに、この方法でPHPを動かすのはまたまたアップデートの時などに手順やファイル名が違ったりしたりと色々面倒な気がするので、実稼働するシステムでは、FileMaker Serverとは別にPHPを稼働させるサーバを立てるのが、トラブルは少ないのではないでしょうか。

INTER-Mediator Ver.6をCentOS 8にインストールする

まだ正式に出していないINTER-Mediator Ver.6ですが、色々なOSにインストールしながら、インストール時のポイントを探っているところです。以前に、Ubuntu Server 18.04、CentOS 7へのインストールを紹介しましたが、今回は、CentOS 8です。

インストールに使ったインストーラは「CentOS-Stream-x86_64-dvd1.iso」というファイル名のISOファイルで、Virtual Box上で展開しました。同時期にはStreamでないものとして「CentOS-8-x86_64-1905-dvd1.iso」が配布されています。Virtual Box側では、ネットワーク1に「NAT」、ネットワーク2に「ホストオンリーネットワーク」を設定しています。ホストオンリー側の設定は、192.168.56.0/24の一般的な設定を適用しています。インストーラの最初の方で、Software SelectionではServer with GUIでなく、Serverを選択してインストールしました。

インストール後、/etc/system-releaseを確認すると、「CentOS Linux release 8.0.1905 (Core) 」でした。ネットワーク設定を行い、ISOファイルを指定して、後は原則そのままインストールを進めました。なお、rootのパスワードは設定せず、管理者権限のユーザーadminを登録して進めました。以下、adminが出てくれば、sudo可能なユーザーとみなしてください。

インストール直後のネットワークの設定

インストール直後はsshでの接続もできないので、VirtualBoxの場合はVMのウインドウでまずはログインをして、ネットワークの設定を行ます。「ip a」や「nmcli connection」で、どんなデバイスがあるかを確認します。通常、NAT側はenp0s3、ホストオンリーネットワーク側はenp0s8になっていると思います。それぞれ、以下のようにコマンドを入れて設定を行ます。ホストオンリー側は、192.168.56.91という固定IPにします。もちろん、設定したセグメント内であれば違ってもOKです。DNSに8.8.8.8を設定するのは嫌われるかもしれませんが、ホストオンリーネットワーク側なので、DNS利用することはほとんどないかもしれません。そして、2つのネットワークデバイスに大して、connection.autoconnectの値をyesにします。こうすればNAT側はDHCPから設定を行い、VMからインターネットにアクセスが可能です。また、ホストオンリーネットワーク側も同様なプロパティをyesにすることで、起動時にデバイスが動作するようになります。最後にホスト名の設定が行われていますが、外部に公開するサーバーならこの方法あるいは別の方法でホスト名は必ず設定すると思われます。この後のApacheの設定でホスト名が決まっていない場合は警告を出して設定ファイルの読み込みがなされず、動作しない場合もあります。なので、実験用にVMを起動する場合も適当なホスト名を必ず設定してください。以下のサンプルをそのまま使ってもらってもいいですが、このcentos.msyk.netはIPの正引き設定はしていません。なお、CentOS 7では「systemctl restart network」と入れて設定を反映させていたのですが、CentOS 8ではnetworkサービスに対するsystemdの設定ファイルが用意されていないので、このコマンドを入れても意味はありません。設定後、検証もかねてすぐにリブート（sudo reboot）するのが良いでしょう。

nmcli connection
ip a
nmcli connection modify enp0s8 ipv4.addresses 192.168.56.92
nmcli connection modify enp0s8 ipv4.gateway 192.168.56.1
nmcli connection modify enp0s8 ipv4.method manual
nmcli connection modify enp0s8 ipv4.dns 8.8.8.8
nmcli connection up enp0s8
nmcli connection modify enp0s3 connection.autoconnect yes
nmcli connection modify enp0s8 connection.autoconnect yes
nmcli general hostname centos.msyk.net

再起動をして、コマンド入力と同様なネットワーク設定になっていることを「ip a」コマンド等で確認します。ちなみにip aは「ip address show」の省略形です。再起動後は正しく設定されていれば、sshで接続できます。CentOS 8は、sshdが最初から起動していますが、ネットワーク設定ができていないので、実質的にはssh接続できないという状態です。上記の作業がsshを可能にする設定とは違います。

再起動後、sshで接続するなどして、dnf updateコマンドを打ち込みます。ネットワークに接続されているので、アップデート等の作業を進めます。

コマンドの収集

ネットワークの設定ができれば、ターミナル等からsshで接続して、以下のコマンドを入れます。まず、最初に、よく利用するコマンドを入れておきます。以下、gitは必須ですが、他に、nmapなど自分の用途に合わせて入れましょう。なお、zip、unzip、lsof、nanoは最初から入っています。

sudo yum install -y git nmap

SELinuxに対応する

ここで1つ重要な設定があるので、最初に行ましょう。CentOS 8は、既定値でSELinuxがアクティブになっていて、高いセキュリティを確保していることになっています。しかしながら、Apacheがデータベースサーバにネットワーク経由で接続することが許可されていないなど、かなり制限は強くなります。また、INTER-Mediator Ver.6より内部で複数のサーバーが動くようなアーキテクチャになっており、SELinuxの初期状態のままでは動作が正しく行われません。

そのため、SELinuxをオフにするか、一部のポリシーを緩めるかのどちらかの設定をしなければなりません。ポリシーを緩める方法は、この手順の後の方で説明しています。

テストや試用の上では、SELinuxをオフにすることで対応するのが手軽な方法です。SELinux自体をオフにしたい場合は、次のように作業します。SELinuxの状態をみるには「getenforce」コマンドを入れますが、「Enforcing」と次の行に出てくれば、設定されていることになります。そして、以下のコマンドを入れることで、SELinuxは基本的にオフになります。

sudo setenforce 0

上記コマンドを入れて、「getenforce」を実行すると「Permissive」と表示されるので、これにより制限が設定されていても実施できるようになったことを示しています。ただし、再起動すると、またオンの状態になります。再起動後にもオフの状態にしたいなら、/etc/selinux/configファイルの「SELINUX=enforcing」を、「SELINUX=disabled」にして再起動してください。このファイルは間違えた状態にすると起動しなくなるので、記述の変更は慎重に行ってください。

Apache2のインストールとFirewallの設定

Apache2のインストールは非常にシンプルです。以下のようにコマンドを入れれば、インストールされてプロセスが稼働します。再起動後にも起動できるように、enableサブコマンドも入れておきます。

sudo dnf -y install httpd
sudo systemctl enable httpd
sudo systemctl start httpd
sudo systemctl status httpd

これで、ブラウザからチェックと思っても、まだページは出ません。CentOS 7は、ファイアウォールの設定が最初からなされているので、要するにポートに穴を開けないといけません。ネットワークアダプタは、publicというゾーンを利用するので、そこで、httpとhttpsについてのサービスを透過することを以下のように設定します。一部、確認のためのコマンドも入っています。設定するとすぐに機能するはずなので、VirtualBoxでこれまで通りの設定を行っていれば、ホストマシン側でWebブラウザからhttp://192.168.56.92に接続すれば、Apacheのページが見えます。なお、DHCPのクライアント処理とsshは最初から通す設定になっています。

sudo firewall-cmd --state
sudo firewall-cmd --get-default-zone
sudo firewall-cmd --list-services --zone=public
sudo firewall-cmd --add-service=http --zone=public --permanent
sudo firewall-cmd --add-service=https --zone=public --permanent
sudo firewall-cmd --reload 
sudo firewall-cmd --list-services --zone=public
# このように表示される　dhcpv6-client http https ssh

PHPのインストールと設定

続いてPHPのインストールです。標準のPHPは7.2です。執筆時点で7.2というのは通常は受け入れられるバージョンだと思われますが、今後、PHPのバージョンが進むとCentOS 7のように別のレポジトリに頼る必要が出るかもしれません。ですが、まずは、標準のPHPを利用することにします。以下のようにコマンドを入れます。すぐに利用したいのなら、Apache2を「sudo systemctl restart httpd」で再起動しておきます。また、この状態でphpコマンドにパスが通ります。なお、INTER-Mediator Ver.6は以下のパッケージの追加で動作可能な模様ですが、チェック漏れがあれば、ここで更新します。チェック漏れがありそうなら教えてください。よろしくお願いします。

sudo dnf install -y php php-cli php-common php-bcmath php-gd php-intl php-json php-ldap php-mbstring php-pdo php-xml php-mysqlnd php-pgsql php-process

composerのインストール

PHPのライブラリ管理ツールにINTER-Mediatorは対応しています。しかしながら、composerを動かさないと、必要なライブラリを取ってきません。なお、npmも利用しますが、npmはcomposerがインストールするのでセットアップは原則的には不要です。セットアップは以下のコマンドを入れます。最初のcd以外は、composerのページに記載された通りですが、composerのページの内容は随時アップデートがあるので、以下のコードのコピペはしないで、composerのページのコードをコピーしてください。

cd
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === 'a5c698ffe4b8e849a443b120cd5ba38043260d5c4023dbf93e1558871f1f07f58274fc6f4c93bcfd858c6bd0775cd8d1') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"

なお、composerもコマンドとしてそのまま打ち込んで利用できるようにしたいので、以下のように作業を行ます。前述の作業では、composer.pharというファイルがホームディレクトリのルートにできて、そのまま動かせるのですが、以下のようにコマンドを入れれば、composerコマンドとして普通にコマンド入力できるようになります。

sudo mv composer.phar /usr/local/bin
cd /usr/local/bin
sudo ln -s composer.phar composer

MySQLのインストール

データベースとしてインストールするのはここではMySQLのみ紹介しましょう。他のデータベースについては、別のサイトをなどをご覧ください。MySQLもPHPと同様に標準のレポジトリにあるパッケージを利用してインストールします。例えば、以下のようにして、インストールを行い、稼働します。

sudo dnf install -y mysql-server
sudo systemctl start mysqld
sudo systemctl enable mysqld

この方法でセットアップすると、MySQLのrootユーザーのパスワードが設定されなお応対になります。そこで、以下のコマンドを入れて、rootのパスワードを設定します。最初に、上記の仮に設定されたパスワードを入れ、その後に新しいパスワードを入れます。パスワードの検証をするかどうか、パスワードのポリシーの強度はどうするかを対話式に答えます。テストするだけの場合は検証しないか、するとしてもLOWを選択しておきます。その後に新しいrootのパスワードを入力します。もちろん、rootのパスワードはメモしておきましょう。

mysql_secure_installation

INTER-Mediatorのインストールとセットアップ

ここで、やっとINTER-Mediatorの登場です。まず、準備として、以下の作業を行ます。ここでは、Apache2はapacheユーザーで稼働しているものとします。

まず、apacheユーザーのホームディレクトリに、apacheユーザーが書き込みできるようにしておきます。インストール当初はrootユーザーにしか書き込み権限がありません。これは、node.jsのプロセス起動のためのユーティリティであるforeverの稼働のための条件です。

cat /etc/passwd|grep apache
# 出力例 apache:x:48:48:Apache:/usr/share/httpd:/sbin/nologin
cd /usr/share
sudo chown -R apache httpd

次に、Apache2のドキュメント領域について、apacheユーザーとadminユーザーに書き込み権限を与えておきます。apacheユーザーについては読み出し権限で十分とも言えるのですが、オーナーをApache2のオーナーにして、グループ側にはログインするユーザーに応じたグループ、つまりコンテンツをいじる側のアカウントを指定するようにしました。通常はグループを新たに作るのが良いと思われますが、以下のコマンドは管理者のグループwheelを指定しています。ドキュメントルートは、/var/www/htmlですが、このwww以下を作業しやすいように、アクセス権を設定しています。なお、以下のコマンドは初期状態でファイルがないことを仮定しています。ファイルがある場合は、3つ目のコマンドについては、775ではなくg+rwでおそらく問題なく行くでしょうけど、既にファイルをコピーしてしまった場合は一概には言えない面もあるので、アクセス権について状況に応じて改めて見直してください。

cd /var
sudo chown -R apache:wheel www
sudo chmod -R 775 www

そして、以下のようにコマンドを入れて、INTER-Mediatorをインストールしてください。その後、composerコマンドを稼働して、しばらく待ちます。これでインストールは終了です。

cd www/html
git clone https://github.com/INTER-Mediator/INTER-Mediator
cd INTER-Mediator/
composer update

SELinuxのポリシーファイルは、dist-docs/selinuxディレクトリに用意しています。INTER-Mediatorをインストール後、次のようにコマンドを入れて、ポリシーをインストールします。INTER-Mediatorディレクトリがカレントであると仮定しています。これにより、即座にポリシーが適用され、再起動後も設定が継続します。なお、ここでのsemoduleコマンドを利用できるようにするために、policycoreutils-pythonパッケージのインストールも必要になります。

sudo yum install -y policycoreutils-python
cd dist-docs/selinux
sudo semodule -i inter-mediator.pp

INTER-Mediatorのファイルのアップロード機能を使うなど、Webアプリケーションからの書き込みがあるような場合もあります。その場合、前述のポリシーファイルだけでは許可は足りませんので、例えば、/var/www/filesにアップロードされたファイルを展開するような場合には、以下のようにコマンドを入力します。最初のコマンドが許可ポリシーを付与するもので、2つ目は設定確認、3つ目はファイルやフォルダを設定をsemanageコマンド通りにするとういうものです。

sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/files(/.)?"
sudo semanage fcontext -l | grep files
sudo restorecon -R /var/www/files

サンプルデータ用のスキーマは以下のようにして読み込みます。なお、MySQLのルートのパスワードを変更する時にお気づきだと思いますが、ポリシーをHIGHTなどにすると複雑なパスワードを設定しないといけなくなります。サンプルについては、ユーザーを作るコマンドも入っています。ROWを選択していれば、サンプルスキーマはそのまま使えます。

cd /var/www/html/INTER-Mediator/dist-docs/
mysql -uroot -p < sample_schema_mysql.txt

これを読み込んだ後に、http://192.168.56.92/INTER-Mediator/samples を参照すると、サンプルの一覧が出てきますので、郵便番号検索などのサンプルをご覧ください。Ver.6の新機能の1つであるサーバーサイドでのNode.jsによるサービスサーバーについても、自動的に稼働するはずです。

一通りの手順は以上です。色々、状況によって違う面もあるかもしれませんが、訂正やバリエーションがあれば、このページに追記します。レポート歓迎します。