SAML連携の設定を入れるとloginページを表示する時に異常終了する。

[nozoe]

テスト環境を構築し、SAML連携の設定を入れてテストをしているのですが、中々うまくいきません。

DB内のsyslog を見るとinternal server error で異常終了している様です。

一応、設定ファイルAuthentication.json は何度も見直しているのですが、何等かの設定が足りないために 落ちているのかイマイチ落ちる原因が分かりません。(必要なところは記述したつもりです) 一応、ソースコードを読もうとはしているのですが、SAML連携に詳しくないので難解です。 よろしくお願いします。

環境としては、 Windows2022 Server MS-SQL2022 Pleasanter-1.3.36.0

Authentication.jsonとsyslog の該当レコードを添付します。 SAML連携エラー.txt Authentication.json.txt

[yohshiro-711]

idpの証明書が証明書ストアから取得できていないようです。 Authentication.jsonを確認したところ、 SamlParameters.IdentityProviders.SigningCertificate.StoreLocationの指定が"CurrentUser"になっていますが 環境がWindows2022 ServerになっているのでIISだと証明書がヒットしないと思われます。

StoreLocationを"LocalMachine"にし、idpの証明書をインストールする際の保存場所をローカルコンピュータにしてみてはいかがでしょうか？

[nozoe]

返信ありがとうございます。

StoreLoacation をLocalMachine に変更してみましたが、状況に変化はない様です。

前回までの環境では、連携証明書のインポートが漏れていることに気付き (確認する証明書を勘違いしていました) 連携証明書をローカルマシンの環境にインポート(ローカルコンピュータ、自動配置)し、 その証明書のハッシュ値に書き直してIIS再起動してみましたが状況に変化は見られ ません。

ハッシュ値で検索すると証明書がヒットする事は確認しました。

[yohshiro-711]

Authentication.jsonのStoreNameにMy(個人ストア)が指定されていますが、 証明書が中間証明機関ストアにインストールされているためヒットしていないと思われます。 証明書を自動配置せず、個人ストアにインストールしてみてはいかがでしょうか。

[nozoe]

ありがとうございます。 個人ストアに再インストールしたら、ログイン画面表示されました。 [SSOログイン]クリックで、ここまできました。 (IDP側の設定見直し等々) この時のWebServerのログがこんな感じです。 `xxx.xxx.xx.xxx - - [10/May/2023:13:55:04 +0900] "GET /pleasanter/ HTTP/2" 302 0

xxx.xxx.xx.xxx - - [10/May/2023:13:55:04 +0900] "GET /pleasanter/users/login?ReturnUrl=%2Fpleasanter%2F HTTP/2" 200 3219

xxx.xxx.xx.xxx - - [10/May/2023:13:55:08 +0900] "GET /pleasanter/users/challenge?ReturnUrl=%2fpleasanter%2f HTTP/2" 200 1314

xxx.xxx.xx.xxx - - [10/May/2023:13:55:08 +0900] "POST /pleasanter/Saml2/Acs HTTP/2" 500 5487 ` この時のsyslog に記録されたエラーの内容です。 Syslog.txt 受け渡しのパラメータかとおもいましたが、それはここを通過した後の様です。

[nozoe]

自己解決しました。 想定、IDP側の担当者から聞いていたEntityIdとは異なるURLがAcsのパラメータに乗って返ってきて来ている事が原因でした。 Syslog に記録されていたURLに書き換えたところ、無事にログイン出来ました。

これで多分大丈夫だと思います。 もうちょっと動作確認してみますが、色々ありがとうございました。

[nozoe]

すみません、関連で一つ確認したいことがありました。 Pleasanter のログイン画面をSSOログインボタンだけにすることは、簡単にできますか？ 基本は、認証ポータルを通ったユーザにしか使えない環境を構築したいのです。

[nozoe]

後、幾つか確認ですが

1. SAML連携するとメールアドレスを書き換えてしまいますが、これを抑止することはできませんか？ ひょっとしてこのパラメータの定義を消せば良いのでしょうか？
2. 抑止出来ない場合、現状のAuthentication.json のSamlParamater 内のMailAddress のところの記述が "MailAddress": "{NameId}" 　となっていたのでここを、IDPから送られてくる属性を確認して (これに結構苦労しました。アプリケーション毎に新しいタブを生成するので、F12を押すタイミングが。。。。) MailAddress": "{Email} にしたら、全く登録処理がなされない状況でした。 　他の変数は、{}で括られてないのに？と思い{} を外して単に"Email"としたら上手くいきました。 "MailAddress": "Email"
   　この辺の違いがいまいちわかりません。

後、補足ですが saml設定のドキュメントに

ユーザー項目の同期について SAML認証でのログインが成功すると、SAMLレスポンスから渡されるユーザーデータを基に、プリザンターのユーザーを作成・更新します。

SAMLレスポンスのNameID要素に設定されているIDをログインIDとして登録します。 未登録のログインIDであった場合、そのログインIDでユーザーが新規に作成されます。 登録済みのログインIDであった場合、そのログインIDのユーザー情報が更新されます。 同期するユーザー情報はAuthentication.jsonのSamlParameters.Attributes で指定したSAMLレスポンスの属性名で検索します。SAMLレスポンス該当する属性名が存在したのみ、その値をユーザー項目に設定します。

と記載したるので、勝手にユーザが作られるのは抑止出来ないのは仕方ないのかなぁと思っていて、改めてAuthentication.json のドキュメントを読むと、RejectUnregisteredUserにtrue を設定すると抑止出来ますね。 後、Provider　にSAMLが指定出来ることも記述してあった方が良いかと思います。

パラメータ設定していてずっと違和感があったのが、APP_DATAのAuthentication.json のStoreNameとStoreLocation が逆になっています。 マニュアル等はあっているのですが、ここだけなぜか逆に "IdentityProviders": [ 　　 { 　　"SigningCertificate": { 　 　 "StoreName": "CurrentUser", 　　 "StoreLocation": "My", 　　 "X509FindType": "FindByThumbprint", 　　 "FindValue": null 　　 } 　　 } ]

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 7 days with no activity.